Fix SSH "Too Many Authentication Failures" Error

You try to connect to a server and get Received disconnect from <host> port 22:2: Too many authentication failures before SSH even asks for a password. A common cause is that your SSH agent has several keys loaded, and the client offers keys the server does not accept before reaching the one you need.

This guide explains why the error happens, how to select the right key or reach the password prompt, and how to check the server’s authentication limit.

Why the Error Happens #

By default, the OpenSSH client can try keys loaded into ssh-agent as well as configured identity files. When you have not selected an identity file, it checks default paths such as ~/.ssh/id_rsa, ~/.ssh/id_ed25519, and ~/.ssh/id_ecdsa. It does not scan every key file in ~/.ssh.

On the server side, sshd enforces a per-connection limit through the MaxAuthTries directive, which defaults to 6. Rejected keys can exhaust that limit before the client reaches the right key or asks for a password. Failed password attempts count toward the limit too, so the message alone does not prove that excess keys caused it. It also does not mean that your account is permanently locked.

Confirm the Cause #

Before changing anything, run SSH with the verbose flag to see exactly which keys the client offers:

ssh -v user@example.com

Replace user@example.com with your remote username and server. If the client tries several rejected keys before disconnecting, you will see output similar to this shortened example:

debug1: Will attempt key: sara@laptop ED25519 SHA256:qT7rXpBYTt7Ohz2PBwMazPwlmH1D4kYp7ovJYM1ACs8 agent
debug1: Will attempt key: sara@laptop RSA SHA256:JK4pX3cpmmNrq49XR5gMFTE6kO4K5iDiLpvAzfDJVuA agent
debug1: Will attempt key: sara@laptop ECDSA SHA256:2GQKKcqxgoqB8hfnFhzRcM+FJrrc/S/Es++2lnhXZyE agent
...
debug1: Offering public key: sara@laptop ED25519 SHA256:qT7rXpBYTt7Ohz2PBwMazPwlmH1D4kYp7ovJYM1ACs8 agent
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: sara@laptop RSA SHA256:JK4pX3cpmmNrq49XR5gMFTE6kO4K5iDiLpvAzfDJVuA agent
debug1: Authentications that can continue: publickey,password
...
Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures
Disconnected from 203.0.113.10 port 22

The Will attempt key lines list every key the client plans to try, in order. Keys marked agent come from ssh-agent. The name shown for them is the key comment (usually the user@host string set when the key was created), not the file name.

The Offering public key lines show the keys the client actually sends. When an offer is followed by Authentications that can continue, the server has not accepted that key. If the key you need is far down the list or never offered, start by limiting the keys on the client.

Limit the Keys with IdentitiesOnly #

For key-based login, pass the private key on the command line together with IdentitiesOnly=yes:

ssh -i ~/.ssh/id_ed25519_work -o IdentitiesOnly=yes user@example.com

Replace ~/.ssh/id_ed25519_work with the path to your private key. The -i option selects the identity file, while IdentitiesOnly=yes prevents the client from offering unrelated keys from the agent or external key providers. If the selected key is loaded in the agent, SSH can still use the agent to sign with it.

This does not always mean exactly one key will be offered. Additional IdentityFile entries in matching configuration blocks also apply, and SSH may try a corresponding certificate. If the key is rejected, password login is available only when both the client and server allow it.

To check which keys are offered, add -v to the same command. The selected key appears with explicit at the end of its Offering public key line.

Connect with a Password Instead #

If you normally log in with a password, skip public-key authentication for this connection:

ssh -o PubkeyAuthentication=no user@example.com

The client no longer offers keys before trying the remaining authentication methods. This does not enable password login on the server. If the server requires a public key, you will need to select an accepted key instead.

Make the Fix Permanent in ~/.ssh/config #

Typing the flags every time is fine for a quick test, but you can save the settings per host in ~/.ssh/config . Open the file, creating it if it does not exist:

nano ~/.ssh/config

Add a host block that pins the key for one server:

Host work-server
    HostName example.com
    User sara
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

Replace example.com, sara, and the key path with your server details. Connect using the alias so SSH applies this block:

ssh work-server

This selects id_ed25519_work and excludes unrelated agent keys. Repeat the pattern for each host that has its own key. If you want to exclude unrelated agent keys by default for every host, add a wildcard block at the bottom of the file:

Host *
    IdentitiesOnly yes

Default identity files remain eligible when no explicit IdentityFile is set. Hosts that rely on an agent key with a non-default filename will need an IdentityFile entry or -i. Also check for IdentityFile entries in other matching blocks, including Host *: these entries accumulate rather than replacing one another.

After editing, make sure the file is only readable by you:

chmod 600 ~/.ssh/config

Clear Extra Keys from ssh-agent #

If your agent has accumulated keys you no longer use, you can remove them from the current agent. List the loaded identities first:

ssh-add -l

The output lists each key’s size, fingerprint, comment, and type, for example:

256 SHA256:qT7rXpBYTt7Ohz2PBwMazPwlmH1D4kYp7ovJYM1ACs8 sara@laptop (ED25519)
3072 SHA256:JK4pX3cpmmNrq49XR5gMFTE6kO4K5iDiLpvAzfDJVuA sara@laptop (RSA)
256 SHA256:2GQKKcqxgoqB8hfnFhzRcM+FJrrc/S/Es++2lnhXZyE sara@laptop (ECDSA)

All three keys have the same comment. The fingerprint is what tells them apart. To find which line belongs to a key file, print the fingerprint of its public key:

ssh-keygen -lf ~/.ssh/id_rsa_old.pub

3072 SHA256:JK4pX3cpmmNrq49XR5gMFTE6kO4K5iDiLpvAzfDJVuA sara@laptop (RSA)

The fingerprint matches the second line of the agent list. To remove that key from the agent, specify its public key file:

ssh-add -d ~/.ssh/id_rsa_old.pub

You can also clear the agent completely and add back the key you need. This unloads every identity from that agent, which can affect other terminals and applications using it. It does not delete your key files:

ssh-add -D
ssh-add ~/.ssh/id_ed25519_work

A desktop key manager or AddKeysToAgent setting may load keys again later. Per-host IdentitiesOnly settings are a better lasting fix when you need several keys for different servers.

Check MaxAuthTries on the Server #

You usually do not need to change the server. If you administer it and suspect the limit is unusually low, check the effective configuration from an existing session or the server console:

sudo sshd -T | grep '^maxauthtries '

With the default setting, the output is:

maxauthtries 6

This is the global limit. If your configuration uses Match blocks, supply the affected username, client IP address, and client hostname to check the settings for that login:

sudo sshd -T -C user=sara,addr=203.0.113.20,host=client.example.com | grep '^maxauthtries '

Replace the example values with the connection details you are troubleshooting. If your rules match the server’s local address or port, include laddr or lport as well.

If a legitimate workflow needs a higher limit, open the daemon configuration:

sudo nano /etc/ssh/sshd_config

Find the existing directive, or add it in the global section before any Match block. For example, a limit of ten attempts is:

MaxAuthTries 10

Check files loaded through Include as well. On Ubuntu, /etc/ssh/sshd_config.d/*.conf is normally included near the top of the main file, so an earlier value there can take precedence over your edit. Change the setting that actually applies, then run sudo sshd -T again to confirm it.

Before reloading, check the configuration syntax and host keys:

sudo sshd -t

No output means the check passed. If you get an error, correct it before continuing. On Ubuntu, Debian, and derivatives using systemd, reload the service with:

sudo systemctl reload ssh

On Fedora, RHEL, and derivatives using systemd, the service is named sshd:

sudo systemctl reload sshd

Test the affected login from another terminal before closing your existing session.

Troubleshooting #

Still getting the error after adding IdentitiesOnly
Check the effective client configuration for the exact alias you use to connect:

ssh -G work-server | grep -E '^(identitiesonly|identityfile|certificatefile) '

Look for identitiesonly yes and check every identityfile and certificatefile line. For most options, SSH uses the first value it obtains, but IdentityFile entries accumulate across matching blocks and included files. Remove or narrow any unwanted entries, then run ssh -v work-server again to see which keys are actually offered.

The right key works manually but not from a script
A script may run as a different local user, use a different host alias, or lack access to your agent. Check that it uses the expected configuration and that SSH_AUTH_SOCK points to the running agent’s socket. SSH_AGENT_PID is not required to use the agent. You can select the key with -i /path/to/key -o IdentitiesOnly=yes, but an encrypted private key still needs its passphrase or an agent that has already unlocked it.

Permission denied (publickey) after the fix
The connection reached authentication, but the client could not complete it with an accepted key. Check the remote username, the selected key, and the server’s ~/.ssh/authorized_keys, including ownership and permissions. Our guide to SSH Permission Denied (publickey) covers these checks and the server logs.

Conclusion #

Save the correct IdentityFile with IdentitiesOnly yes for hosts you access with a key. For password-only connections, skip public-key authentication so unrelated keys do not use up the server’s authentication attempts.

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 1000+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page