SSH "Too many authentication failures": your agent offers too many keys
Fix SSH "Received disconnect … Too many authentication failures": the agent offers every key before the right one. Use IdentitiesOnly and IdentityFile.
by OhSudo ··
Not sure this is your cause?Find it step by step: Can't connect over SSH →
The connection is cut before you even get a password prompt or a “Permission denied”:
Received disconnect from 203.0.113.10 port 22:2: Too many authentication failuresDisconnected from 203.0.113.10 port 22Your key is probably fine — it just never got its turn. The SSH server allows only a few login attempts per connection (MaxAuthTries, 6 by default), and every key your client offers counts as one. If your ssh-agent holds six keys and the right one is the seventh, the server hangs up after the sixth. It’s common on laptops that collect keys over the years: GitHub, GitLab, work, a couple of clients, a cloud provider…
- ssh-agentholds six keysoffers them one by one
- ServerMaxAuthTries 6: each offered key countslimit reached(fails)
- Disconnectedbefore the right key(breaks here)
TL;DR
ssh-add -l # how many keys does the agent offer?ssh -o IdentitiesOnly=yes -i ~/.ssh/deploy_ed25519 user@server # offer only this keyand to fix it for good, in ~/.ssh/config:
Host web01 HostName 203.0.113.10 User guest IdentityFile ~/.ssh/deploy_ed25519 IdentitiesOnly yes1. Count the keys your client offers
256 SHA256:3xk… guest@laptop (ED25519)256 SHA256:Lq9… guest@github (ED25519)256 SHA256:pW2… guest@gitlab (ED25519)3072 SHA256:7Rd… guest@work (RSA)256 SHA256:aZ0… guest@acme (ED25519)256 SHA256:Yt5… guest@globex (ED25519)Six keys. Run the connection with -v and look at what ssh offers, and when the server gives up:
debug1: Offering public key: guest@laptop ED25519 SHA256:3xk… agentdebug1: Offering public key: guest@github ED25519 SHA256:Lq9… agentdebug1: Offering public key: guest@gitlab ED25519 SHA256:pW2… agentdebug1: Offering public key: guest@work RSA SHA256:7Rd… agentdebug1: Offering public key: guest@acme ED25519 SHA256:aZ0… agentdebug1: Offering public key: guest@globex ED25519 SHA256:Yt5… agentReceived disconnect from 203.0.113.10 port 22:2: Too many authentication failuresThe deploy key — the one the server knows — never appears.
2. Why -i alone doesn’t help
The natural reaction is ssh -i ~/.ssh/deploy_ed25519 web01. Often it fails exactly the same way:
That’s because of the order in which OpenSSH offers keys:
- keys you named (
-iorIdentityFile) that are also loaded in the agent, - all the other keys in the agent,
- the named keys that are not in the agent.
Your deploy key isn’t in the agent, so it comes last — after the six that use up the attempts. -i adds a key; it doesn’t remove the others.
3. Offer only the right key: IdentitiesOnly
IdentitiesOnly yes tells ssh to offer only the keys you named, and skip the rest of the agent:
To make it permanent, add it to the host’s block in ~/.ssh/config. In this scenario the web01 block is the last one in the file, so appending a line adds it to that block:
cat ~/.ssh/configecho " IdentitiesOnly yes" >> ~/.ssh/configssh -G web01 | grep -E "^(hostname|user|identit)"ssh web01 hostnamessh -G prints the settings ssh will really use for a host, without connecting — the quickest way to check a config. If you’d rather not edit the file by hand, the SSH Config Generator writes a ~/.ssh/config with IdentitiesOnly yes for every host.
Warning
IdentitiesOnly yes under Host * (for all hosts) is a good default, but then every host needs its own IdentityFile. A host without one gets only the default keys (~/.ssh/id_ed25519, ~/.ssh/id_rsa…), not the rest of your agent — so a login that worked “by accident” through the agent stops working.
4. Or: put the right key in the agent
Keys you name in the config and have in the agent are offered first (step 1 of the order above). So this also works:
ssh-add ~/.ssh/deploy_ed25519ssh web01It’s fine as a quick fix, but the next machine with a fuller agent hits the same wall. IdentitiesOnly fixes the cause. You can also clean up the agent: ssh-add -D removes every key, ssh-add -d ~/.ssh/old_key one of them.
5. Git, GitHub and password-only servers
The same error shows up with Git over SSH, for example git push to GitHub with many keys loaded. Fix it the same way, in ~/.ssh/config:
Host github.com User git IdentityFile ~/.ssh/github_ed25519 IdentitiesOnly yesIf the server only accepts passwords, your keys still use up the attempts before the password prompt. Skip them for that host:
ssh -o PubkeyAuthentication=no user@serverNote
Raising MaxAuthTries on the server (in /etc/ssh/sshd_config) also makes the error go away, but it gives every attacker more guesses per connection. Fix the client instead.
Shell, we have a problem!
Similar, but different: Permission denied (publickey) means ssh tried all its keys and none was accepted — the right key isn’t on the server, or the server can’t read it. See SSH “Permission denied (publickey)”. And Host key verification failed is about the server’s identity, not your keys: REMOTE HOST IDENTIFICATION HAS CHANGED.
$ ./practice.sh
Practice this in the terminal
Open the Terminal Playground with this article’s scenario loaded. It is safe and runs in your browser.
Found this useful? Share it.
Found a mistake? Let us know at contact@ohsudo.com.