Fix SSH "Too many authentication failures" when connecting

You try to connect to your Linux VPS and the server closes the connection with Too many authentication failures. Nothing is broken on the server — your SSH client simply offered more keys than the server allows before it gave up. This guide shows why that happens and how to fix it in a few minutes.

Before you start

You need:

• A Linux VPS you can reach over the network, with its IP address and a username (for example deploy).
• A terminal on your own machine — Linux, macOS or Windows with OpenSSH installed.
• Your private keys in ~/.ssh/ or loaded into ssh-agent.
• Access to the browser console in your VPS provider's control panel as a fallback, in case you lock yourself out while testing.

Understand why it happens

OpenSSH tries authentication methods in order. For public keys, it walks through every key it knows about — files in ~/.ssh/ and everything loaded in ssh-agent — and offers each one to the server. The server has a limit on how many failed attempts it accepts before it drops the connection (commonly six). If you have a dozen keys loaded, the server never reaches the right one.

You can see this in action with verbose output:

ssh -v deploy@203.0.113.10

Look for lines like Offering public key: /home/deploy/.ssh/id_ed25519 repeated several times, followed by Authentications that can continue: publickey,password and finally Too many authentication failures.

The fix is to tell the client which key to use, so it offers only that one.

Step 1: List the keys your client is offering

First, see what is loaded in the agent:

ssh-add -l

You will get a list of fingerprints. If that list is long, that is your problem. To see the key files on disk:

ls -l ~/.ssh/

Typical files are id_rsa, id_ed25519, id_ecdsa and any custom names you created. Every one of them is a candidate the client may offer.

Step 2: Connect with one key using -i

The quickest test is to name the key explicitly:

ssh -i ~/.ssh/id_ed25519 deploy@203.0.113.10

If that works, you have confirmed the diagnosis. But -i alone is not always enough: the client may still offer agent keys first. Add -o IdentitiesOnly=yes to force it to use only the key you named:

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

That combination is the reliable fix for a one-off connection.

Step 3: Make it permanent in the SSH config file

Typing options every time gets old. Put them in ~/.ssh/config instead. Create the file if it does not exist:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/config
chmod 600 ~/.ssh/config

Then add an entry:

Host myvps
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Now you connect with a short name:

ssh myvps

The client offers exactly one key. If you manage several servers with different keys, add one block per host. See Use the SSH config file to save hosts and shortcuts and Manage several SSH keys for different servers for more patterns.

Step 4: Clean up ssh-agent

If you prefer to keep using the agent, trim what is loaded. Remove everything and add only the key you need:

ssh-add -D
ssh-add ~/.ssh/id_ed25519

Check the result:

ssh-add -l

One key in the list means one offer to the server. On macOS the agent may reload keys from the keychain automatically; on Linux desktops, GNOME Keyring can do the same. If keys keep reappearing, IdentitiesOnly yes in the config is the durable answer.

Step 5: Check the server side if it still fails

If you have narrowed it to one key and still get rejected, the problem is no longer the count. Confirm the server accepts public key authentication:

sudo sshd -T | grep -E 'pubkeyauthentication|passwordauthentication|maxauthtries'

MaxAuthTries is the limit that produces this error. Raising it is possible in /etc/ssh/sshd_config, but it is the wrong fix — it weakens the server and hides a client problem.

If the key is simply not authorised, check that the matching public key is in ~/.ssh/authorized_keys for the right user, with correct permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Check it works

Connect with verbose output and confirm only one key is offered:

ssh -v myvps

You should see a single Offering public key line, followed by Authentication succeeded (publickey). If you see several offers, your config entry is not being picked up — check the Host name matches what you typed and that the file permissions are 600.

Troubleshooting

• Error returns only on one machine. That machine has extra keys in its agent. Run ssh-add -D and add only the needed key, or set IdentitiesOnly yes.
• Permission denied (publickey) after the fix. The count problem is solved, but the key is not authorised on the server. Verify the public key is in authorized_keys for the correct user.
• Config seems ignored. ~/.ssh/config must be owned by you and mode 600. A world-writable config is silently skipped.
• Works with -i but not with the host alias. The IdentityFile path in the config is wrong, or Host does not match the name you typed. Paths are relative to ~/.ssh/ unless they start with /.
• Server rejects before any key is offered. This is a different problem — a firewall, a wrong port or a banned IP. See Fix SSH "connection refused", "timed out" and "permission denied".

Next steps

Now that key authentication is predictable, tighten the server:

• Set up SSH keys if you are still using passwords.
• Disable root login and password authentication over SSH to reduce what an attacker can try.
• Protect SSH from brute-force attacks with Fail2ban and get alerts with Fail2ban ban notifications.
• Connect to your Linux VPS with SSH from Windows, Mac or Linux for a full walkthrough.