🚨 Security Error Guide: SSH 'Too many authentication failures'

Overview

An SSH server limits how many authentication attempts a single connection may make (MaxAuthTries, default 6). Each public key your client offers counts as an attempt — so a client whose agent holds many keys can burn through the limit before it ever tries the right one, and the server drops the connection. This is a defensive control against brute forcing, working as designed. But it most often bites legitimate users whose SSH agent blindly offers every loaded key to every host, rather than an actual attack.

The literal client-side error:

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

With -v, you can watch the agent offer key after key until the server cuts it off:

debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:aaaa...
debug1: Offering public key: /home/user/.ssh/id_work_ed25519 ED25519 SHA256:bbbb...
debug1: Offering public key: agent key 3 ED25519 SHA256:cccc...
debug1: Offering public key: agent key 4 ...
Received disconnect from ... : Too many authentication failures

On the server, the same event appears in the auth log:

sshd[2244]: Disconnecting authenticating user root 203.0.113.55 port 51544: Too many authentication failures [preauth]

Symptoms

• Connecting to a host fails with Too many authentication failures before you’re even prompted for the right key or password.
• The problem appears only for users/hosts with many keys loaded in ssh-agent (ssh-add -l lists several).
• Specifying the exact key on the command line succeeds where a plain ssh host fails.
• Server logs show [preauth] disconnects for the client, not a wrong-password event.

ssh-add -l

2048 SHA256:aaaa... id_rsa (RSA)
256 SHA256:bbbb... id_work_ed25519 (ED25519)
256 SHA256:cccc... id_personal (ED25519)
... (7 keys total)

ssh -v server 2>&1 | grep -c 'Offering public key'

6

Common Root Causes

1. The agent offers every loaded key (most common)

With many identities in the agent, SSH tries each in turn. Six offered keys hit the default MaxAuthTries=6 before reaching the correct one.

ssh -v server 2>&1 | grep 'Offering public key'

Offering public key: id_rsa ...
Offering public key: id_work_ed25519 ...
... (limit reached before the right key)

2. No IdentitiesOnly, so config keys AND agent keys are all tried

Even with IdentityFile set, without IdentitiesOnly yes SSH still offers all agent keys on top of the configured one, inflating the count.

grep -A3 "Host server" ~/.ssh/config

Host server
  HostName 203.0.113.10
  IdentityFile ~/.ssh/id_server
  # missing: IdentitiesOnly yes

3. Server MaxAuthTries set very low

A hardened server sets MaxAuthTries 2 or 3; combined with a multi-key agent, legitimate clients get cut off quickly.

sudo sshd -T | grep -i maxauthtries

maxauthtries 3

4. The correct key isn’t loaded/valid, so every attempt is a real failure

The intended key is missing from the agent or has wrong permissions, so all offered keys genuinely fail and the limit is reached.

5. Wrong username causing all key attempts to fail

Connecting as the wrong user means no offered key matches an authorized_keys, exhausting the tries.

Diagnostic Workflow

Step 1: Confirm it’s key-count exhaustion, not a bad credential

ssh -v server 2>&1 | grep -E 'Offering public key|Too many'
ssh-add -l | wc -l

Many “Offering public key” lines ending in Too many authentication failures means the agent is spraying keys.

Step 2: Prove it by forcing a single, explicit key

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_server user@server

If this succeeds, the fix is to stop offering unrelated keys — not to change the server.

Step 3: Pin the identity per-host in ssh config

cat >> ~/.ssh/config <<'EOF'
Host server
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_server
  IdentitiesOnly yes
EOF
ssh server

IdentitiesOnly yes tells SSH to offer only the listed IdentityFile(s), so exactly one attempt is made.

Step 4: Check the server limit (only if a legitimate client still can’t fit)

sudo sshd -T | grep -Ei 'maxauthtries|maxsessions'

If MaxAuthTries is extremely low, raise it modestly (e.g., to 4–6) — but prefer fixing the client, since lowering the server limit is a valid hardening choice.

Step 5: Confirm the right key is actually usable

ssh-add -l | grep -q id_server || ssh-add ~/.ssh/id_server
ls -l ~/.ssh/id_server        # must be 600 and owned by you

Example Root Cause Analysis

An engineer who manages many servers suddenly can’t reach a newly hardened bastion: Too many authentication failures, before any prompt. Their agent holds seven keys from years of onboarding:

ssh-add -l | wc -l

7

Verbose output shows the agent offering keys until the server disconnects:

ssh -v bastion 2>&1 | grep -E 'Offering public key|Too many' | tail

Offering public key: id_rsa ...
Offering public key: id_old_ed25519 ...
Offering public key: agent key 3 ...
Received disconnect from ... :2: Too many authentication failures

The bastion was hardened with MaxAuthTries 3. The engineer’s correct key (id_bastion) is fourth in the agent’s offer order, so the server cuts the connection before it’s tried. Nothing is wrong with the key or the server policy — the client is offering unrelated keys first.

Fix: pin the exact identity for that host and restrict SSH to only that key, so a single attempt is made:

cat >> ~/.ssh/config <<'EOF'
Host bastion
  HostName bastion.example.com
  User jdoe
  IdentityFile ~/.ssh/id_bastion
  IdentitiesOnly yes
EOF
ssh bastion

Authenticated to bastion.example.com using "publickey".
jdoe@bastion:~$

One key offered, one success — the server’s tightened MaxAuthTries stays in place as intended.

Prevention Best Practices

• Set IdentitiesOnly yes with a specific IdentityFile per Host block so SSH offers exactly the right key and never sprays the whole agent.
• Keep the agent lean: load only keys you’re actively using (ssh-add -D to clear, add back as needed), and prefer per-host keys over one key everywhere.
• Treat a low server MaxAuthTries as a legitimate hardening setting; fix the client’s key offering rather than raising the server limit to accommodate a bloated agent.
• Use SSH certificates or a per-host key layout so the correct identity is unambiguous and agent bloat never causes lockouts.
• Combine with fail2ban/rate limiting on the server; MaxAuthTries plus per-host client config gives brute-force resistance without breaking real users.
• Document each host’s key in ~/.ssh/config so onboarding doesn’t rely on the agent guessing.

Quick Command Reference

# How many keys is the agent holding / offering?
ssh-add -l
ssh -v host 2>&1 | grep -c 'Offering public key'

# Force a single explicit key (proves the cause)
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_host user@host

# Per-host pinning in ~/.ssh/config
#   Host host
#     IdentityFile ~/.ssh/id_host
#     IdentitiesOnly yes

# Check the server's attempt limit
sudo sshd -T | grep -i maxauthtries

# Trim the agent
ssh-add -D            # remove all
ssh-add ~/.ssh/id_host

Conclusion

Too many authentication failures means the connection ran out of allowed attempts — usually because the SSH agent offered several keys before the right one, tripping the server’s MaxAuthTries brute-force guard. Fix the client, keep the guard:

1. A multi-key agent offering every identity — the most common cause.
2. Missing IdentitiesOnly yes, so agent keys pile on top of the configured one.
3. A deliberately low server MaxAuthTries (a valid hardening choice).
4. The correct key not loaded/usable, so all attempts genuinely fail.
5. Connecting as the wrong user so no key matches.

Confirm with ssh -v, prove it with -o IdentitiesOnly=yes -i <key>, then pin the identity per host in ~/.ssh/config — resolving the lockout while leaving the server’s brute-force protection intact.