SSH: “Too Many Authentication Failures” — what is it and how to fix it

When connecting to the server via SSH, sometimes a message like: Received disconnect from x.x.x.x port 22:2: too many authentication failures or ssh: Permission denied (publickey) appears.

Essentially, this means that the client was unable to pass verification on the remote side, having exhausted the limit of attempts. Below — why this happens, how it works and what to do to make the connection work and not disrupt the work of this particular connection in the future. 

The examples are given for Ubuntu 24.04, but the logic is the same for other distributions.

Why does the error occur?

SSH supports multiple login methods. Most often this is key entry and password entry. Key authentication is considered a basic and secure option, so servers usually offer it first. The client receives a list of valid methods from the server and iterates through them in a given order. The number of attempts is limited: if the “correct” method does not work in time, the connection is terminated with an error.

If you planned to log in using a key, the failure is usually due to one of the following:

— The public key has not been added to the server. There should be a private key on your machine, and the corresponding public key should be located on the remote side in ~/.ssh/authorized_keys.
— The key is not picked up by ssh-agent. Moving files to ~/.ssh is not enough: the keys must be added with the ssh-add command.
— There are too many keys in the system. The client tries the first few, hits the limit of attempts and is rejected, even if the “right” key is there.

If you wanted to log in using a password, the nuances are different:

— The server announces key support. With a large number of local keys, the client will try them and will not get to the point of entering a password.
— The wrong password authentication mechanism was selected. There are at least two options in SSH — password and keyboard-interactive. If the client tries password and the server expects keyboard-interactive, you will receive a failure.

How to figure out what exactly is wrong

The first step is to analyze the client’s detailed output. Add the -vvv option to the command:

ssh -vvv serhii@192.168.56.124

In the connection log, pay attention to the line with preferred — it lists the order of methods that the client will try. It is also useful to see which keys the agent actually offers (get_agent_identities), and at what stage the refusal occurs.

How to fix: working scripts

Next, we have collected the minimum client-side settings that most often solve the problem. Let’s assume that the server is configured correctly and is ready to allow access using both a key and a password.

1) Disable searching for “all” keys

By default, the SSH client tries all found keys, easily hitting the limit. Make it use only the keys you specify:

In /etc/ssh/ssh_config add:

IdentitiesOnly yes

After this, the client will use strictly those keys that are listed in the configuration via IdentityFile. Already at this stage, the “too many authentication failures” error often disappears. If Permission denied (publickey) appears instead, proceed to the next step.

2) Specify the required key

Pass the path to the private key on the command line:

ssh -o IdentityFile=~/.ssh/id_ed25519_7 serhii@192.168.124.58

To avoid writing the option every time, add a rule to ~/.ssh/config:

Host 192.168.124.58

    IdentityFile ~/.ssh/id_ed255

This key will now be used for all connections to the specified host.

3) Force login using password

If you just need a password, but the keys are located locally, set the order of the methods and disable authorization by key:

ssh

  -o PubkeyAuthentication=no 

  -o PasswordAuthentication=yes 

  -o PreferredAuthentications=password 

  serhii@192.168.124.58

The same can be recorded in ~/.ssh/config:

Host 192.168.124.58

    PubkeyAuthentication no

    PasswordAuthentication yes

    PreferredAuthentications password

4) Change the mechanism to keyboard-interactive

Sometimes the server expects keyboard-interactive (for example, with external authentication systems). In this case use:

ssh

  -o PubkeyAuthentication=no 

  -o PreferredAuthentications=keyboard-interactive 

  name@192.168.124

And the corresponding rule in the config:

Host 192.168.124.58

    PubkeyAuthentication no

    PreferredAuthentications keyboard-interactive

What to check on the server

If you have access to the server console or its system logs, do two things.

Logs.

Enable the advanced level for the SSH daemon by adding the line to /etc/sshd_config:

LogLevel VERBOSE

Then restart the service:

sudo systemctl restart ssh

By default, authorization messages are written to /var/log/auth.log.

Access rights.

The file ~/.ssh/authorized_keys must have permissions 600:

ls -l ~/.ssh/authorized_keys

Total

The error too many authentication failures (and sometimes Permission denied (publickey)) almost always comes down to two things: the client tries the wrong keys or the parties have agreed on different login methods. Enable verbose output (-vvv), limit the keys used (IdentitiesOnly + IdentityFile), or explicitly set the desired authorization method. If necessary, look at the server logs and check the rights to authorized_keys.

CONTENT:

Similar

All news