Fixing "Too many authentication failures"

2026-06-06 Reading time: About 11 min Difficulty: Intermediate

What Is Happening with "Too many authentication failures"?

Conclusion: The server hit its allowed number of auth attempts (MaxAuthTries, default 6) before reaching your correct key. The key is not wrong — you are simply offering too many.

The SSH connection itself succeeded and your client is talking to the server's sshd. This is neither a network problem nor an invalid key.

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures
Disconnected from 203.0.113.10 port 22

sshd caps the number of authentication attempts per connection (MaxAuthTries, default 6). With public key authentication, every key the client offers counts as one attempt. If your ssh-agent holds many keys, ssh offers them in order regardless of whether the server will accept them, and it hits the limit before reaching the right one.

What Should You Check First?

Conclusion: Run ssh -v and count the Offering public key: lines. How many keys you offer before the disconnect is the direct evidence of the cause.

The first move is to make visible how many keys you are sending.

$ ssh -v user@server.example.com

Lines to watch:

debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:...
debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:...
debug1: Offering public key: ssh-ed25519 SHA256:... agent
debug1: Offering public key: ssh-rsa SHA256:... agent
...
Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

If about six Offering public key lines line up and the connection drops right after, the cause is confirmed: you offer too many keys and exhaust MaxAuthTries before sending the right one.

Why Does Offering Too Many Keys Get Rejected?

Conclusion: sshd limits attempts per connection to MaxAuthTries. Each public key consumes one attempt just by being offered, so with many keys the budget runs out before the right key is tried.

The mechanism, step by step:

1. The client offers its available keys to the server in order.
2. The server checks whether the offered key is in authorized_keys; if not, it says "next."
3. Each such round trip counts as one attempt.
4. Once attempts reach MaxAuthTries, the server disconnects without waiting for a success.

So if you have ten keys and the right one is ninth, you are cut off at the sixth and never reach it. That is what "too many" means.

What Is the Quick Fix to Connect Now?

Conclusion: Combine -o IdentitiesOnly=yes with -i key to offer exactly one key. That keeps attempts to one and gets you in immediately.

$ ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@server.example.com

IdentitiesOnly=yes is the crucial part. Without it, even when you specify a key with -i, ssh also offers the keys in ssh-agent, so the number of attempts does not drop. This is the biggest trap here.

If you are not sure which key is correct, add -v and try them one at a time.

$ ssh -v -o IdentitiesOnly=yes -i ~/.ssh/id_rsa user@server.example.com

If you see Authentication succeeded (publickey), that key is the right one. Make it permanent with the next step.

How Do You Fix It Permanently in ~/.ssh/config?

Conclusion: Set IdentityFile and IdentitiesOnly yes per host in ~/.ssh/config. From then on the key is narrowed to one automatically, with no command-line options needed.

Host myserver
    HostName server.example.com
    User user
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Now ssh myserver alone connects while offering only the specified key.

If you juggle several servers, give each host its own block.

Host prod
    HostName prod.example.com
    User deploy
    IdentityFile ~/.ssh/id_prod
    IdentitiesOnly yes

Host gitlab
    HostName gitlab.example.com
    User git
    IdentityFile ~/.ssh/id_gitlab
    IdentitiesOnly yes

How Do You Clean Up ssh-agent Keys?

Conclusion: Check the count with ssh-add -l; if there are too many, clear them with ssh-add -D and re-add only what you need. A bloated agent is the common root cause of "offering too many."

First, check the current state.

$ ssh-add -l

256 SHA256:... user@host (ED25519)
3072 SHA256:... old-key (RSA)
256 SHA256:... another (ED25519)
...

If six or more are listed, they eat the attempt budget on every server unless you use IdentitiesOnly. Remove the ones you do not need.

# Clear all and re-add
$ ssh-add -D
$ ssh-add ~/.ssh/id_ed25519

To drop a specific key only:

$ ssh-add -d ~/.ssh/id_rsa

Should You Adjust MaxAuthTries on the Server?

Conclusion: If you administer the server, raising MaxAuthTries works around it, but it is a band-aid that weakens brute-force resistance. The proper fix is to narrow keys on the client.

Check the effective value with sshd -T.

$ sudo sshd -T | grep -i maxauthtries

maxauthtries 6

Only when an operation truly cannot avoid offering many keys, raise the value in /etc/ssh/sshd_config.

MaxAuthTries 10

$ sudo systemctl reload ssh

Checklist to Prevent Recurrence

Conclusion: "Offer exactly one key" is the essence of the fix. Clear IdentitiesOnly in your config, tidy the agent, and confirm the server setting one by one, and it will not recur.

• [ ] Does ssh -v show more Offering public key lines than MaxAuthTries (default 6)?
• [ ] Does the quick fix -o IdentitiesOnly=yes -i key let you connect?
• [ ] Did you add IdentityFile and IdentitiesOnly yes to the target Host in ~/.ssh/config?
• [ ] Are there too many keys in ssh-add -l (clear with ssh-add -D if so)?
• [ ] If keys reappear automatically, did you check AddKeysToAgent and startup scripts?
• [ ] As a server admin, did you confirm the effective maxauthtries with sshd -T?