🚨 Linux Error Guide: 'Too many authentication failures' — Fix SSH Key Overload

Overview

SSH drops the connection before you can authenticate and prints this when too many auth attempts pile up in a single session:

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

With verbose output you can see the client burning through attempts, one per key the agent offers:

debug1: Offering public key: /home/user/.ssh/id_rsa
debug1: Offering public key: /home/user/.ssh/id_ed25519
...
Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

The server closes the connection once the number of failed attempts crosses MaxAuthTries (default 6). The most common cause is not a wrong password — it is an SSH agent loaded with many keys, offering each one until the limit is hit before it ever reaches the correct key.

Symptoms

• Connections to a specific host fail with “Too many authentication failures” while other hosts work.
• The failure is instant and repeatable; you never get a password prompt.
• ssh-add -l lists several identities.
• It started after adding more keys to your agent, or on a laptop that accumulated many keys over time.
• Removing keys from the agent or using -o IdentitiesOnly=yes makes it work.

Common Root Causes

• Agent offers every loaded key. Each offered public key counts as an authentication attempt; with 6+ keys loaded, the limit is reached before the right key is tried.
• IdentitiesOnly not set. Without it, SSH tries agent keys AND configured IdentityFiles, multiplying attempts.
• Server MaxAuthTries is low. A hardened server set MaxAuthTries 2-3, so even a couple of stray keys trip it.
• Wrong or extra keys in ~/.ssh auto-tried. Default identity files are attempted in addition to agent keys.
• PubkeyAuthentication plus password fallback all count toward the same per-session attempt budget.

Diagnostic Workflow

See exactly what the client offers and in what order. -v shows each “Offering public key” attempt:

ssh -v user@host 2>&1 | grep -iE 'offering|authentications that can continue|too many'

Count how many identities the agent will present:

ssh-add -l
ssh-add -l | wc -l

Prove it is the key overload by forcing SSH to use only the one correct key:

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

On the server side, check the configured attempt limit:

sudo sshd -T | grep -i maxauthtries
sudo grep -i maxauthtries /etc/ssh/sshd_config

Example Root Cause Analysis

An engineer could reach staging but every connection to a new production bastion failed instantly with “Too many authentication failures.” Local password auth was irrelevant — they had key-only access.

ssh -v bastion showed the client offering five different public keys in a row, and the server disconnecting after the fourth. ssh-add -l confirmed five identities were loaded in the agent. The bastion, being hardened, ran MaxAuthTries 3 (verified with sshd -T), so the correct id_ed25519 key — offered fifth — was never reached.

The fix was a per-host ~/.ssh/config block pinning the exact key with IdentitiesOnly yes, so SSH offered only one identity and authenticated on the first try. Raising MaxAuthTries on the server was explicitly rejected as the wrong fix — it would have weakened brute-force protection to paper over a client misconfiguration.

Prevention Best Practices

• Add IdentitiesOnly yes plus an explicit IdentityFile in a per-host ~/.ssh/config block so each host is offered exactly one key.
• Keep the agent lean — load only keys you actively use, or use ssh-add -t with expiry so stale keys don’t accumulate.
• Don’t raise MaxAuthTries as a first resort; it reduces brute-force resistance. Fix the client offering instead.
• Use distinct keys per environment and map them explicitly in ~/.ssh/config rather than relying on agent order.
• On jump-host chains, set IdentitiesOnly at each hop so the overload doesn’t compound.

Quick Command Reference

# Force a single key for one connection (diagnostic)
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@host

# Persist the fix per host in ~/.ssh/config
cat >> ~/.ssh/config <<'EOF'
Host bastion
    HostName 203.0.113.10
    User ops
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
EOF

# Inspect and trim the agent
ssh-add -l
ssh-add -D            # clear all, then re-add only what you need
ssh-add ~/.ssh/id_ed25519

# Server side: confirm the limit
sudo sshd -T | grep -i maxauthtries

Conclusion

“Too many authentication failures” almost always means your SSH agent is offering more keys than the server’s MaxAuthTries allows, so the correct key is never reached. The clean fix is on the client: pin the right IdentityFile and set IdentitiesOnly yes per host so exactly one key is offered. Reserve raising MaxAuthTries for genuine multi-factor needs — trimming the offered keys keeps both your logins reliable and the server’s brute-force protection intact.