Fix SSH Too Many Authentication Failures Error

Learn why SSH rejects you with too many authentication failures and how to fix it on the client with IdentitiesOnly and IdentityFile, manage ssh-agent keys correctly, and safely raise MaxAuthTries on servers you control.

Prerequisites

SSH client installed locally
Sudo or root access on the target server for server-side changes
At least one valid SSH key pair already generated

What this solves

SSH refuses your connection with "Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures" even though you have a valid key. This happens when your SSH client or agent offers more keys than the server's MaxAuthTries limit allows before it even tries the correct one. This tutorial shows how to diagnose it with verbose output and fix it on both the client and server side.

Why this error happens

SSH servers limit how many authentication attempts a client can make per connection, controlled by the MaxAuthTries setting in /etc/ssh/sshd_config, which defaults to 6. Each key your SSH client offers counts as one attempt, even if the server eventually rejects all of them because none match.

If you have several private keys loaded into ssh-agent, or multiple identity files configured, SSH will try them one by one in order. On a machine with 5 or 6 SSH keys loaded for different servers, GitHub, GitLab, personal VPS, work servers, SSH can burn through the MaxAuthTries limit before it ever offers the one key that would have worked. The server then disconnects you, and you never even get a password prompt.

This is a client-side offering problem, not a credentials problem. The fix is almost always to make the client stop guessing and offer only the correct key for that host.

Step-by-step diagnosis and fix

Reproduce the error with verbose output

Run the SSH connection with verbose logging to see exactly which keys are being offered and in what order. This is the single most useful diagnostic step.

ssh -v root@203.0.113.10

Look for lines starting with "Offering public key" and "Authentications that can continue". If you see several keys offered before the disconnect, you have confirmed the cause.

Count how many keys are loaded in your agent

Check what ssh-agent currently holds. Every key listed here gets offered to every server you connect to unless you restrict it.

ssh-add -l

If this lists 5 or more keys, that is very likely why you are hitting the limit, especially against servers with a low MaxAuthTries value.

Remove unused keys from the agent

Clear all identities currently loaded in ssh-agent so you start clean, then add back only the keys you actually need for active sessions.

ssh-add -D

Confirm the agent is now empty.

ssh-add -l

Then add back only the specific key for the server you are connecting to right now.

ssh-add ~/.ssh/id_ed25519_prod

Create a per-host SSH config entry

The most reliable permanent fix is telling SSH exactly which key to use for each host, and telling it to stop offering every other key in the agent. Open or create your SSH client config.

nano ~/.ssh/config

Add a dedicated block per host specifying IdentityFile and IdentitiesOnly.

Host prod-server
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github
    IdentitiesOnly yes

Host gitlab-work
    HostName gitlab.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

IdentitiesOnly yes is the key directive here. Without it, SSH still appends every agent key after trying your IdentityFile, which defeats the purpose. With it set, SSH only offers the key you explicitly listed for that host.

Set correct permissions on your SSH config and keys

SSH refuses to use files with permissions that are too open. The ~/.ssh directory and its contents need strict permissions, owned by your user only.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/config
chmod 600 ~/.ssh/id_ed25519_prod
chmod 644 ~/.ssh/id_ed25519_prod.pub

Never use chmod 777. It gives every user on the system full read, write and execute access to your private keys and config. SSH private keys must be 600 (owner read/write only), the .ssh directory must be 700, and public keys can be 644. Use chown to ensure the files belong to your own user, not root or another account.

Connect using the short host alias

Once the config is in place, connect using the Host alias you defined, not the raw hostname or IP. This triggers the IdentityFile and IdentitiesOnly rules.

ssh prod-server

Verify with -v again to confirm only one key is offered this time.

ssh -v prod-server

Increase MaxAuthTries on the server (only if you control it)

If you manage the server and still hit the limit with a reasonable number of keys, for example a shared jump host where IdentitiesOnly is not practical for every user, you can raise MaxAuthTries. Do this carefully, it is a mitigation, not a fix for sloppy client config.

sudo nano /etc/ssh/sshd_config

MaxAuthTries 10

Test the config syntax before restarting the service, a broken sshd_config can lock you out entirely.

sudo sshd -t

sudo systemctl restart sshd

Keep a second session open when restarting sshd. If the new config has an error, you want an existing connection alive so you can fix it without needing console access.

Restart the SSH service correctly per distro

The service name differs slightly across distributions. Use the matching command for your system.

sudo systemctl restart ssh
sudo systemctl status ssh

sudo systemctl restart sshd
sudo systemctl status sshd

Verify your setup

Confirm the agent only holds the keys you expect and that SSH offers just one identity per host.

ssh-add -l
ssh -v prod-server 2>&1 | grep "Offering public key"

You should see exactly one "Offering public key" line before authentication succeeds. If the server login works without the "Too many authentication failures" disconnect, the fix is confirmed.

ssh -o BatchMode=yes prod-server echo connection ok

Common issues

Symptom	Cause	Fix
Too many authentication failures for root	Agent offers multiple keys before the one root actually trusts	Add IdentitiesOnly yes and IdentityFile to the Host block, verify with ssh -v
Still fails after adding IdentityFile	IdentitiesOnly missing, agent keys still appended after the IdentityFile	Add IdentitiesOnly yes explicitly under the same Host entry
Permission denied (publickey) after fixing offering order	Wrong key for that host, or public key not in server's authorized_keys	Confirm with ssh-keygen -y -f privatekey and compare against ~/.ssh/authorized_keys on the server
sshd fails to restart after MaxAuthTries change	Syntax error in sshd_config	Run sudo sshd -t before restarting, fix the reported line
ssh-add -l reports "no identities"	Agent not running or keys never loaded this session	Run eval $(ssh-agent -s) then ssh-add ~/.ssh/id_ed25519_prod
SSH ignores ~/.ssh/config entirely	Wrong file permissions or wrong path	chmod 600 ~/.ssh/config and confirm the file is in your actual home directory

Best practices for multi-key environments

Give every key a distinct, descriptive filename, for example id_ed25519_prod, id_ed25519_github, id_ed25519_personal, instead of overwriting the default id_rsa repeatedly. This makes IdentityFile entries self-documenting.

Always pair IdentityFile with IdentitiesOnly yes in ~/.ssh/config. Without it, SSH treats IdentityFile as an addition to the agent's offered keys, not a replacement, which brings the original problem right back.

Avoid loading every key you own into ssh-agent by default. Load keys per session as needed, or use ssh-agent with a short timeout via ssh-add -t 3600 so stale keys expire automatically. For teams managing access across many servers, consider SSH certificate authentication with CA signing instead of distributing individual keys, since certificates avoid the multiple-key-offering problem entirely.

If you are also troubleshooting agent forwarding issues alongside this error, see fixing SSH sign_and_send_pubkey signing failed, a related agent-side failure mode. For general hardening once authentication works reliably, review SSH key authentication and security hardening.

Next steps

Running this in production?

Want this handled for you? This works for a single server. When you manage SSH access across dozens of servers, rotate keys, and need consistent config for every team member, keeping it organized and secure 24/7 is a different job. See how we run infrastructure like this for European teams.

#ssh #authentication #troubleshooting #openssh #linux-security

Fix SSH Too many authentication failures error on Linux