SSH: Too many authentication failures — the agent is the culprit

Received disconnect … Too many authentication failures usually is not about a wrong password. It means your SSH client offered the server more keys than it allows per connection, and the server cut you off before you reached the one that works.

Why a client with one password fails this way

The SSH agent offers every key it has loaded, one at a time, before falling back to a password. sshd defaults to MaxAuthTries 6. Load seven keys in your agent and the server hangs up on the seventh attempt — the password prompt you were expecting never arrives.

ssh-add -l   # lists every key the agent will try

The fix: offer only the right key

IdentitiesOnly=yes tells the client to use only the key you name and stop spraying the agent’s whole collection:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@host

Make it the default for that host in ~/.ssh/config:

Host myserver
    HostName 203.0.113.10
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Or prune the agent

If you just want a clean slate, drop all loaded keys and add back only the one you need:

ssh-add -D              # remove all identities
ssh-add ~/.ssh/id_ed25519

Server side: raise the limit (carefully)

You can lift MaxAuthTries, but treat it as a last resort — a higher limit also gives brute-force attempts more room. Prefer fixing the client.

MaxAuthTries 10
# then
sudo sshd -t && sudo systemctl restart ssh

Confirm which key actually worked

ssh -v user@host 2>&1 | grep -Ei 'offering|accepted|authenticated'

Once you know the working key, pin it in ~/.ssh/config and the error will not come back. A fresh VPS with console access means that even a locked-out agent is never a dead end.

Frequently asked