[BUG] Desktop SSH ignores IdentitiesOnly yes / configured Identity File and offers every ssh-agent key, triggering "Too many authentication failures"

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When connecting to a remote host over SSH, Claude Code Desktop's SSH client (Node.js ssh2) does not honor IdentitiesOnly yes from ~/.ssh/config and does not restrict authentication to the configured IdentityFile. Instead it enumerates and offers every identity loaded in the running ssh-agent, one after another.

On any server whose MaxAuthTries is at or below the number of keys in the agent, the correct key is offered after the limit is reached, so the server disconnects the client before the right key is ever tried. The user sees:
Too many authentication failures

The exact same host connects instantly and reliably from:

the system OpenSSH client in cmd / PowerShell (ssh <alias> and ssh -i <key> user@host), and
VS Code Remote-SSH (which uses the system OpenSSH client),

because both respect IdentitiesOnly yes and offer only the one configured key.

This is the classic client-side "offers its whole key pile, wrong ones first" failure — but it only occurs in Claude Code Desktop, because the desktop app does not apply the IdentitiesOnly directive that the system SSH client applies.

What Should Happen?

Claude Code Desktop should match system OpenSSH semantics:

1. When IdentitiesOnly yes and an IdentityFile are set in ~/.ssh/config for the target host, offer only that key.
2. When an Identity File is set explicitly in the connection dialog, offer only that key and do not additionally enumerate every ssh-agent identity.
3. Passphrase-protected keys configured explicitly should authenticate successfully after the passphrase is supplied.

Any of these alone would prevent the MaxAuthTries exhaustion.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

1. Have an ssh-agent running with several keys loaded (e.g. ssh-add -l shows 4).
2. On the target server, set MaxAuthTries at or below the number of agent keys (e.g. MaxAuthTries 3), so the correct key sits beyond the limit in the offer order.
3. In ~/.ssh/config, configure the host with an explicit IdentityFile and IdentitiesOnly yes.
4. Confirm the connection works from a terminal: ssh MyServer → connects on the first try.
5. In Claude Code Desktop, add an SSH host — try all of:

• SSH Host = the config alias (MyServer)
• SSH Host = explicit root@203.0.113.10
• Identity File field = the full absolute path to the correct key

1. Connect / Try again.

Result: every variant fails with Too many authentication failures.

Server-side evidence (/var/log/auth.log)

With the agent running (4 keys) and MaxAuthTries 3 — Claude Code fails:

sshd[857749]: error: maximum authentication attempts exceeded for root from <CLIENT_IP> port 17433 ssh2 [preauth]
sshd[857749]: Disconnecting authenticating user root <CLIENT_IP> port 17433: Too many authentication failures [preauth]

The client offers multiple wrong keys first; the correct key is never reached.

After raising MaxAuthTries to 6 (enough budget for the correct key at offer position ~4) — Claude Code succeeds:

sshd[862055]: Postponed publickey for root from <CLIENT_IP> port 10491 ssh2 [preauth]
sshd[862055]: Accepted publickey for root from <CLIENT_IP> port 10491 ssh2: ED25519 SHA256:<correct-key-fingerprint>
sshd[862055]: pam_unix(sshd:session): session opened for user root(uid=0) by root(uid=0)

This confirms the root cause: the correct key is authorized and works — it was simply being offered after 3+ wrong agent keys, past the MaxAuthTries limit. Raising the server limit is only a workaround for a client that should never have offered the other keys in the first place.

Secondary observation: agent-less + passphrase-protected key also fails

To isolate the agent, I stopped ssh-agent entirely and set the Identity File explicitly in the UI. Claude Code then prompted for the key passphrase (correctly entered) but still failed:

All configured authentication methods failed

Server log showed only Received disconnect ... [preauth] with no Accepted publickey. So with the agent absent, the desktop app could not authenticate with the explicitly-configured, passphrase-protected key at all. This suggests a second problem: the ssh2 client's handling of passphrase-protected private keys (or the passphrase entry path) does not complete authentication even when only the correct key is available. (This may overlap with #39752.)

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.199 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Suggested Fix

• Honor the IdentitiesOnly directive when parsing ~/.ssh/config, and gate the agent-key enumeration on it.
• When the user provides an explicit Identity File (config or UI), treat it as authoritative and skip agent enumeration (or offer the explicit key first / exclusively).
• Alternatively, shell out to the system ssh binary so all existing ~/.ssh/config semantics (IdentitiesOnly, IdentityFile, passphrase/agent handling) "just work" — several other SSH bugs in this tracker would also be resolved by this.

Impact

Any user with more than a couple of keys in their agent (common for anyone managing multiple servers) hits this on servers with a normal or hardened MaxAuthTries, even though their SSH config is correct and every other SSH client works. The only workarounds today are:

• raising server-side MaxAuthTries (weakens the server, only papers over the symptom),
• emptying the agent down to just the one key before each connect, or
• using a dedicated passphrase-less key exclusively for Claude Code.

None of these should be necessary when IdentitiesOnly yes is already set.

Relationship to existing issues

• #39752 — "All configured authentication methods failed"; reporter notes the Identity File field appears entirely ignored and the agent isn't used either. Overlaps with the secondary observation above, but does not frame the primary failure as the IdentitiesOnly / MaxAuthTries interaction.
• #29717 — ssh2 mishandling of Identity File / SSH_AUTH_SOCK (1Password agent). Related area, different trigger.
• #46273 — feature request to support agent auth in the dialog. Related area.

This report specifically covers: IdentitiesOnly yes is not honored, so all agent keys are paraded and MaxAuthTries is exhausted before the correct, explicitly-configured key is tried.