How to Fix SSH "Too many authentication failures" (IdentitiesOnly)

Fix SSH "Too many authentication failures" in 5 Minutes — Done with IdentitiesOnly

A server that connected fine yesterday suddenly drops you today with this:

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

It never even asks for a password — it just hangs up. That's jarring. Here's the punchline: this is not a wrong key. You actually have the right key. The client just offers a pile of other keys first, blows past the server's attempt limit, and gets disconnected before the correct key ever gets a turn. One line in ~/.ssh/config permanently fixes it in about 5 minutes.

This is a completely different error from Permission denied

Let's nail this down first. A lot of people see this error, search for Permission denied (publickey) fixes, regenerate keys, and re-register them on the server. That's the opposite of what you need.

If you add more keys after seeing this error, the situation gets worse. What you actually need is the opposite: offer fewer keys.

Why it disconnects — ssh-agent colliding with MaxAuthTries

Once you understand the mechanism, the fix is obvious.

① The client offers every key loaded in ssh-agent, in order. Personal GitHub key, work key, server A key, server B key, cloud instance keys… If ssh-agent is stuffed with keys, SSH presents them to the server one by one on connect. If the server says "not that one," it moves to the next.

② Server sshd has an attempt limit called MaxAuthTries (default 6). Each authentication attempt inside a single TCP connection increments the counter by 1. The moment that counter exceeds MaxAuthTries, the server drops the connection.

③ So if the agent has more than 6 keys, you get disconnected before the right key's turn. Say the correct key is 8th in line and the server default is 6. The first 6 offers already hit the limit and disconnect. The right key never even gets offered.

These days keys pile up fast: 1Password SSH-agent integration, multiple GitHub accounts (personal + work), lots of cloud instances. That's why this error shows up more often.

Diagnose: watch the offer order with ssh -v

Don't guess — look. -v (verbose) shows which keys are offered and in what order.

ssh -v user@203.0.113.10

The important lines look like this:

debug1: Offering public key: /Users/me/.ssh/id_rsa_github    # ← (1) wrong key offered (count 1)
debug1: Authentications that can continue: publickey         #     server: "not that one, keep going"
debug1: Offering public key: /Users/me/.ssh/id_rsa_work      # ← (2) another wrong key (count 2)
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/me/.ssh/id_ed25519_aws   # ← (3) another wrong key (count 3)
...
debug1: Offering public key: /Users/me/.ssh/id_ecdsa_old     # ← (6) 6th, limit reached
Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

Each Offering public key: line is "one key offered = count +1". The output above is the classic case: six attempts burned before the right key, then disconnect.

Now check how many keys are loaded in the agent:

ssh-add -l          # list keys loaded in the agent (check the count)

If that count is higher than the server's MaxAuthTries (usually 6), you've confirmed the cause. In a pinch you can clear the agent and re-add only the key you need:

ssh-add -D                          # remove all keys from the agent
ssh-add ~/.ssh/id_ed25519           # re-add only the key you need

If you have access to the server, you can also check the server-side limit:

grep MaxAuthTries /etc/ssh/sshd_config

Fix: pin a per-host key with IdentitiesOnly=yes

The real fix is to say "for this host, offer only this key." The key option is IdentitiesOnly yes. Without it, even if you set IdentityFile, SSH still offers the other keys sitting in the agent. Turning on IdentitiesOnly yes forces it to try only the specified key.

(a) Pin a key for a single host — copy-paste ready

# ~/.ssh/config
Host myserver
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519_myserver
    IdentitiesOnly yes

Now just ssh myserver. Only one key is offered, so you will never hit the limit.

(b) Multi-account pattern — GitHub personal/work + internal servers

This is the pattern to use in multi-account setups.

# ~/.ssh/config

# GitHub personal account
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_personal
    IdentitiesOnly yes

# GitHub work account (clone as git@github-work:org/repo.git)
Host github-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

# Internal server
Host company-server
    HostName 10.0.1.20
    User devops
    IdentityFile ~/.ssh/id_ed25519_company
    IdentitiesOnly yes

For work repos, clone with the github-work host alias — git clone git@github-work:org/repo.git — so only the work key is used.

Temporary fix (when you need it before touching config)

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_myserver deploy@203.0.113.10

This ignores other agent keys and offers only the key given with -i. Typing it every time is annoying, so move it into config when you can.

Client cause vs server cause

Note for server operators: bumping MaxAuthTries blindly is risky. The larger it is, the more auth attempts an attacker gets in one connection — brute-force surface grows. The real problem is almost always too many keys on the client, so clean up config before you raise the server limit.

A practical note — the agent is not a wallet

When you run a bunch of cloud instances, it's easy to ssh-add every new key without thinking. I hit this error myself once I passed ~10 instances. The lesson is simple: the agent is a workspace for keys you're using right now, not a wallet that holds every key. Manage keys in ~/.ssh/config, not in the agent. Then you can see at a glance which host uses which key, and this error goes away for good. Prefer ed25519 for new keys (ssh-keygen -t ed25519).

Anti-pattern warnings

• ❌ Dump every key into the agent → more than 6 keys is a direct ticket to this error
• ❌ Skip config and always use -i → a stopgap; it won't reproduce in collab or CI
• ❌ Crank server MaxAuthTries way up → larger brute-force attack surface
• ✅ ~/.ssh/config + IdentitiesOnly yes with a 1:1 host-to-key mapping

Reference: official docs

The primary source for the behavior, settings, and error covered here is the official documentation. Check it for version-specific options and exact behavior.

• OpenSSH sshd_config manual (man7.org)

FAQ

Q. If I turn on IdentitiesOnly yes, will other servers stop connecting? A. No. Each Host block in config applies per host, so only the IdentityFile set for that host is used. Specify the right key per host and every connection works.

Q. If I wipe keys with ssh-add -D, will that break other work? A. They're removed from the agent's memory only. Key files on disk (~/.ssh/*) stay. Re-add with ssh-add when needed, or set IdentityFile in config and you can connect without the agent.

Q. I run the server and users keep hitting this. Should I raise MaxAuthTries? A. Not recommended. The root cause is too many keys on the client. Point users at IdentitiesOnly yes + IdentityFile in config — that's much safer.

3-line checklist you can apply today

ssh-add -l                                   # 1. how many keys in the agent? (more than 6 → suspect)
ssh -v user@host 2>&1 | grep "Offering"      # 2. which keys are offered, in what order
# 3. add that Host block + IdentityFile + IdentitiesOnly yes to ~/.ssh/config → done