Fix SSH "Too Many Authentication Failures"

  • Too many authentication failures
  • Received disconnect
  • Permission denied (publickey)
  • 6 min read
  • Updated 7 October 2026
  • ESAGAMES Team

This error usually isn't a wrong password — it's your SSH client offering too many keys before the right one. The server cuts you off after a few tries. Here's the fix, and what to do if you actually are locked out.

Quick answer

"Too many authentication failures" usually means your SSH client offered several keys before the right one and the server cut you off. Offer only the correct key: ssh -o IdentitiesOnly=yes -i ~/.ssh/yourkey user@server, or set IdentitiesOnly yes and the key for that host in ~/.ssh/config.

Why it happens

If your SSH agent holds several keys, the client tries each one in turn. The server limits authentication attempts (often 5-6), so it disconnects before reaching the correct key — even though you have it.

Fix: offer only the right key

Tell SSH to use one specific key and not try the others:

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

Make it permanent

Add a host entry in ~/.ssh/config so it always uses the correct key:

Host myserver
  HostName server-ip
  User myuser
  IdentityFile ~/.ssh/the_right_key
  IdentitiesOnly yes
Locked out anyway?

If you genuinely have the wrong/no key, use your provider's VNC/serial console to add your public key to ~/.ssh/authorized_keys — see our guide on SSH connection issues.

Too many keys offered, not a wrong password. Use IdentitiesOnly=yes with the right key, and set it in ~/.ssh/config.

Other situations that trigger this

  • SSH agent forwarding through a jump host offers every key loaded on your local agent to the destination server, multiplying the attempt count fast.
  • Working across several projects/servers, each with its own key, without ever clearing old ones from the agent (ssh-add -l shows what's loaded).
  • A low MaxAuthTries on the server (if you control it) makes this trigger sooner than the SSH default — raising it slightly can help, but fixing the client side is the real solution.

How to prevent it going forward

  • Clear unused keys from the agent with ssh-add -D and load only what you need for the session.
  • Use a distinct Host block per server in ~/.ssh/config with IdentitiesOnly yes set for all of them, not just the problem one.
  • For hardened servers you administer, pair key-based login with fail2ban so repeated failures (legitimate or not) get rate-limited automatically.

If SSH refuses the connection outright rather than failing auth, see fixing SSH connection refused. For a plain publickey rejection with just one key, see fixing "Permission denied (publickey)". To lock things down properly, see how to harden SSH.

Frequently asked questions

What causes "Too many authentication failures" in SSH?

Your SSH client is offering multiple keys from your agent, and the server hits its attempt limit before reaching the correct one. It disconnects even though you have a valid key.

How do I fix it?

Force SSH to use only the right key with -o IdentitiesOnly=yes -i ~/.ssh/yourkey, and add a Host entry in ~/.ssh/config with IdentityFile and IdentitiesOnly yes so it's permanent.

Is this the same as a wrong password?

No. It's usually about too many keys being tried, not a bad password. The fix is to limit which key SSH offers, not to change your password.

How do I see which keys my SSH agent is currently offering?

Run ssh-add -l to list every key loaded in the agent. If it's more than you expect, that's likely why the server is rejecting the connection before your correct key is tried.

Does agent forwarding through a jump host make this worse?

Yes — forwarding offers every key on your local agent to each hop, which can burn through the attempt limit even faster than a direct connection. Consider connecting with IdentitiesOnly at each hop.

Can I just raise MaxAuthTries on the server instead of fixing the client?

You can if you administer the server, but it only delays the same problem — fixing the client to offer just the right key (IdentitiesOnly yes) is the more reliable, permanent fix.

Go deeper on this

Guides and explainers that pair with this fix — from our guides and blog.

Related articles

Skip the troubleshooting

Managed, protected hosting in Frankfurt — we handle the Linux, the network and the DDoS so you don't have to.

Game hosting All articles