SSH Too Many Authentication Failures Error Causes and Fixes

You have the right key, the server has your public key, and still the login ends with Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures. The reason is mechanical: before your correct key was tried, the client offered several wrong ones, and the server counts each. This is the key-management cousin of permission denied (publickey). The commands assume OpenSSH 9.x.

See what is being offered

ssh-add -l
ssh -v [email protected] 2>&1 | grep -E 'Offering|Will attempt|Too many'

256 SHA256:aaa... work-key (ED25519)
256 SHA256:bbb... github-key (ED25519)
3072 SHA256:ccc... old-laptop (RSA)
256 SHA256:ddd... staging (ED25519)
256 SHA256:eee... personal (ED25519)
256 SHA256:fff... backup (ED25519)
256 SHA256:ggg... deploy-key (ED25519)
debug1: Offering public key: ... work-key
debug1: Offering public key: ... github-key
Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

Seven keys are loaded in the agent, and the server stops listening after six attempts, counting identity files from your config and the default names too. The right key (deploy-key) is seventh and never gets its turn. The key names and fingerprints are placeholders.

The fix: tell ssh which key to use

Host server.example.test
    User deploy
    IdentityFile ~/.ssh/deploy_ed25519
    IdentitiesOnly yes

IdentitiesOnly yes restricts ssh to the keys explicitly configured with IdentityFile (plus any on the command line) and ignores the rest of the agent. Without it, the agent's keys are offered first, whatever the config says. For a one-off, use the command line: ssh -o IdentitiesOnly=yes -i ~/.ssh/deploy_ed25519 [email protected]. The ordering rules are in the SSH config guide, which also shows how to group hosts with patterns.

Reduce the agent's load

ssh-add -D
ssh-add ~/.ssh/work_ed25519
ssh-add -t 4h ~/.ssh/deploy_ed25519

ssh-add -D removes all identities, then you add back only what you need, optionally with a lifetime (-t). Keeping fewer keys loaded is good hygiene anyway, since forwarded agents expose every key they hold, as discussed in agent forwarding. A password manager's SSH agent may hold dozens of keys; configure it to expose only the ones you need or use IdentityAgent per host.

Server-side limit

MaxAuthTries 6

That is the default in /etc/ssh/sshd_config. Raising it lets more keys through but also gives a brute-force attacker more tries per connection, so prefer fixing the client. If you must raise it for a shared bastion, pair it with fail2ban or similar. Check the effective value with sudo sshd -T | grep maxauthtries, as in hardening sshd.

Other triggers

Password authentication attempts count too: a misconfigured client that tries a wrong password a few times after the keys exhaust the limit sooner. A script that loops over many hosts with the default agent will hit this on a server that has a stricter limit. Disable agent use for a single command with SSH_AUTH_SOCK= ssh -i key host.

How the client chooses which keys to offer

The SSH client offers keys in a sequence: first any keys loaded in the agent, then the identity files from the configuration and the default file names, one after the other. Each offer counts as an authentication attempt on the server. By default the server allows only a limited number of attempts per connection, six in common configurations through MaxAuthTries, and ends the connection when the limit is reached, with the message about too many authentication failures. A person with several keys in the agent, say one per project or one per service, can use up the budget on keys that the server does not know before the right one is tried. The error then appears even though the right key is loaded, and it often starts after adding a new key to the agent.

The verbose output shows the order of offers. Counting the lines marked as offered before the failure confirms the diagnosis.

Naming the identity for each host

The fix is to tell the client which key a host uses, and to stop it from trying others. In the client configuration, give each host or pattern an IdentityFile and set IdentitiesOnly yes. The second option makes the client use only the listed files, ignoring the agent's other keys. The agent can still supply the key if the file names a public key, which lets a hardware token or a passphrase-protected key stay in the agent while the offers remain controlled. The result is one attempt, the right one, and a faster login, since each wrong offer costs a round trip. Organise the configuration with Host blocks that match naturally, such as a service domain, and put a catch-all block last.

Order matters in the configuration file: for each option, the first value found wins, so put specific blocks before general ones.

Trimming the agent

If you hold many keys, load fewer. Add keys on demand with a lifetime, ssh-add -t 3600 key, or use the AddKeysToAgent option to add a key when first used. List the agent's contents with ssh-add -l and remove keys you no longer need with ssh-add -d. Some desktop environments start their own agents and load every key in the .ssh directory automatically, which creates the problem without you doing anything; check which agent is active with the SSH_AUTH_SOCK variable. Hardware tokens and password manager agents hold keys too, and each counts toward the limit. Having separate keys per service is good practice, and the matching configuration is what makes it work.

Avoid the temptation to reuse a single key everywhere to dodge the issue. Separate keys limit the damage of a leak and make revocation precise.

The server side and other triggers

An administrator can raise MaxAuthTries in sshd_config, but doing so only treats the symptom and weakens protection against password guessing, so prefer fixing the client. The same message can come from fail2ban or similar tools if they ban your address after repeated failures, from a server that rejects a key type and counts it as a failed attempt, or from a wrong user name that makes every key fail. Check the user in the verbose output. When automation is involved, a CI job with a leftover agent from a previous step can accumulate keys, so start jobs with a clean agent or pass the key by file. After applying the configuration fix, test with ssh -v and confirm that exactly one key is offered and accepted, then keep the configuration under version control with your other dotfiles, so a new machine behaves the same.

Where this does not apply

If only one key is loaded and the error remains, the server may have a very low MaxAuthTries or another method (password, keyboard-interactive) is failing; read the verbose log. If you are using SSH certificates, the certificate counts as an identity too. See the ssh_config IdentitiesOnly description and the sshd_config MaxAuthTries description.