Too many authentication failures: SSH ran out of tries

Received disconnect from 10.0.0.5 port 22:2: Too many authentication failures followed by Permission denied (publickey) is not a broken server, and it is not necessarily a wrong password. The client spent the attempt budget while walking agent keys and never reached the method you meant to use.

The budget is MaxAuthTries on the server (6 by default). Each public key offered is one try. Five keys in ssh-agent plus one more wrong key — the connection dies before the right key or a password prompt.

Why this happens

SSH asks the server which methods it accepts, then the client walks its own order. publickey is first by default. While the agent keeps offering keys, the server is already counting failures.

A file sitting in ~/.ssh is not enough: OpenSSH offers agent identities, not “the file you had in mind”. What will actually be sent:

ssh-add -l

Empty agent or the wrong key — read -vvv instead of guessing.

Client log first

Debug level 3 shows the method order and every key offered:

ssh -vvv deploy@10.0.0.5

Look for:

• Authentications that can continue — what the server allowed;
• Offering public key / get_agent_identities — which keys go out;
• Too many authentication failures — attempt budget, not “wrong password”.

Typical picture: the agent hands over id_rsa, id_ed25519, a GitLab key, a bastion key — four rejects, the fifth is still wrong, the sixth is no longer accepted.

Stop offering every key

IdentitiesOnly yes stops the client from mixing in every agent identity. After that, only IdentityFile or -i is used.

Per host, not in the global /etc/ssh/ssh_config:

Host prod
    HostName 10.0.0.5
    User deploy
    IdentitiesOnly yes
    IdentityFile ~/.ssh/id_ed25519_prod

One-shot:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod deploy@10.0.0.5

-vvv should then show a single Offering public key. If too many turns into Permission denied (publickey), the walk is over and the key was simply rejected: it is not in authorized_keys, or it is the wrong file.

Password when the agent is full

The client will not ask for a password until publickey is exhausted. Turn keys off and put password first:

ssh -o PubkeyAuthentication=no \
    -o PreferredAuthentications=password \
    -o PasswordAuthentication=yes \
    deploy@10.0.0.5

In ~/.ssh/config:

Host prod-password
    HostName 10.0.0.5
    User deploy
    PubkeyAuthentication no
    PasswordAuthentication yes
    PreferredAuthentications password

On Ubuntu and anywhere the password goes through PAM, the server often advertises keyboard-interactive, not password. The command above then fails silently. Switch the method:

ssh -o PubkeyAuthentication=no \
    -o PreferredAuthentications=keyboard-interactive \
    deploy@10.0.0.5

Host prod-password
    HostName 10.0.0.5
    User deploy
    PubkeyAuthentication no
    PreferredAuthentications keyboard-interactive

Which method the server actually offers is the Authentications that can continue line in -vvv.

What to check on the server

You need another channel: hypervisor console, VNC, serial. Otherwise you are stuck in the same error you are fixing.

Logs. On Ubuntu 24.04 the unit is ssh (sshd is an alias). For rejected-key detail, raise verbosity:

# /etc/ssh/sshd_config or a drop-in under /etc/ssh/sshd_config.d/
LogLevel VERBOSE

sudo systemctl restart ssh
sudo journalctl -u ssh -e
# if rsyslog is installed:
sudo tail -f /var/log/auth.log

The log shows which key was rejected and whether MaxAuthTries was reached.

Permissions. With StrictModes yes (the default) sshd silently ignores files that are too open:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
# the home directory must not be group/other-writable

The public key is one line in authorized_keys; the matching private key is the one in IdentityFile.

Attempt limit. A fat agent and many keys per host can justify raising the cap (this weakens brute-force protection):

MaxAuthTries 10

Better not to raise it: shrink the client with IdentitiesOnly and one IdentityFile per Host.

Short checklist

1. ssh -vvv — how many keys went out and which method remained.
2. ssh-add -l — what sits in the agent; do not offer the rest.
3. In ~/.ssh/config for the host: IdentitiesOnly yes and an explicit IdentityFile.
4. Need a password — PubkeyAuthentication no and the method the server printed in debug (password or keyboard-interactive).
5. From the server console: journalctl -u ssh, ~/.ssh / authorized_keys modes, LogLevel VERBOSE if needed.

A “too many” error is almost always on the client: too many keys for one login. The server only counts to six and closes the session.