When connecting to a server via SSH, you may receive an error "Received disconnect from x.x.x.x port 22:2: too many authentication failures" or "ssh permission denied (publickey)". In short, this means that your SSH client failed to authenticate on the remote server because the authentication attempts limit has been reached.
In this article, we will explore why such a problem might occur, how it all works, and how to fix it and configure the system to prevent this from happening in the future for this SSH connection. Ubuntu 24.04 was used while writing this article, but the information should be relevant for other distributions as well.
Table of Contents
Why Does This Error Occur?
SSH supports several authentication methods, with the main ones being passwordless authentication using a public-private key pair and regular password authentication. Of course, the first option is more reliable, convenient, and secure since you don't need to remember a password, and malicious actors who want to infiltrate your server won't even be able to attempt to brute-force it.
Therefore, key authorization is used by default. In most cases, this is not a problem because the server informs the client which authentication methods can be used, and the client chooses the order in which to try them. However, the total number of authentication attempts is limited. And if something doesn't match, and the client fails to authenticate within these attempts, then such an error occurs.
If you intended to authenticate using a key, there are three possible causes of the problem:
- Your key is not added to the server. For this to work, you must have a private key on your computer, and the corresponding public key must be added to the ~/.ssh/authorized_keys file on the remote server.
- Your key is not added to the ssh agent. If you transferred keys from another computer, it's not enough to just place them in the ~/.ssh directory. They also need to be added using the ssh-add command.
- You have too many keys in your system. Even if the key is added, but you have many of them, the SSH client tries the first few, and since there is a limit on the number of authentication attempts, you get an error.
If you want to authenticate using a password, it's a bit different:
- The server supports key-based authentication. If the SSH server indicates that it supports key-based authentication and you have many keys in your system, SSH won't even prompt you for a password, and you'll face the same issues as mentioned above. To fix this, you can specify the order of authentication methods using ssh command options.
- You're using the wrong authentication mechanism. There are several SSH authentication mechanisms that involve password input, at least these are password and keyboard-interactive. If you've configured to use password before publickey, but the server requires keyboard-interactive, you'll encounter the same error.
In any case, there's no point in trying to guess what the problem is. You need to check the logs. To do this, add the -vvv option to your SSH server connection command. For example:
ssh -vvv serhii@192.168.56.124
This command will show not only the error itself but also the connection process. First, the command will output a lot of information about reading the configuration. Pay attention to the line preferred, which lists the order of authorization mechanisms that the client will use:
And also on the authorization process, which keys (get_agent_identities) are being used, and where the error occurs:
How to Fix the Error?
In this article, I won't cover how to add a key to the server, set up permissions for the ~/.ssh/authorized_keys file, and similar tasks. Let's assume that the server is configured correctly and is ready to authorize you either by key or password. Now we need to understand how to configure the SSH client to make everything work.
1. Do Not Try All Keys
As I mentioned above, by default, the SSH client attempts to authenticate using all keys available in the system, like this:
And accordingly, receives an error from the server if the first four keys don't match. However, there is another way. Using the IdentitiesOnly option, you can tell the SSH client that you want to use only the keys listed with the IdentifyFile option in the configuration. To do this, add the IdentitiesOnly option with the value yes to the /etc/ssh/ssh_config file:
/etc/ssh/ssh_configIdentitiesOnly=yes
After that, the authorization process will look like this:
All these keys are listed in the same /etc/ssh/ssh_config file, and in the next section, we'll look at how to configure your key. This step alone might solve the "too many authentication failures" issue. However, if you encounter the "ssh permission denied (publickey)" error instead, let's proceed further.
2. Selecting a Key for Authorization
You can explicitly specify which key you want to use with the IdentityFile option. You need to pass the path to the private key file for authorization in the connection command, in my case ~/.ssh/id_ed25519_7:
ssh -o IdentityFile=~/.ssh/id_ed25519_7 serhii@192.168.124.58
To avoid adding this option every time you run the command, you can add it for this host in the ~/.ssh/config file:
~/.ssh/configHost 192.168.124.58
IdentityFile ~/.ssh/id_ed25519_7
After that, this key will be used for all SSH connections to this host.
3. Authenticating with Password
If you need to authenticate using a password, but there are keys in the system, the client will try them first and won't prompt for a password. To resolve this, you can change the order of authentication methods for the connection using the PreferredAuthentications option, and while at it, disable key authentication and enable password authentication:
ssh -o PubkeyAuthentication=no -o PasswordAuthentication=yes -o PreferredAuthentications=password serhii@192.168.124.58
The same can be configured for this host in the ~/.ssh/config file:
~/.ssh/configHost 192.168.124.58
PubkeyAuthentication no
PasswordAuthentication yes
PreferredAuthentications password
4. Specifying Authentication Method
Sometimes, instead of the password authorization mechanism, the server may use keyboard-interactive. This typically happens when authentication uses a password from an external authorization service rather than a Unix user password. In such cases, the command described in the previous section won't work, and you need to use this one instead:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=keyboard-interactive serhii@192.168.124.58
And accordingly, the settings for ~/.ssh/config will be slightly different:
~/.ssh/configHost 192.168.124.58
PubkeyAuthentication no
PreferredAuthentications keyboard-interactive
What to Check on the Server?
1. Logs
If you have access to the server, either physical or through VPS console, first you need to check the authorization logs there. To enable debug mode for the ssh service, you need to add the following line to /etc/sshd_config:
LogLevel VERBOSE
After that, you need to restart the service:
sudo systemctl restart ssh
By default, logs are written to the /var/log/auth.log file:
2. Permissions
The permissions for the ~/.ssh/authorized_keys file must be 600:
ls -l ~/.ssh/authorized_keys
Conclusions
In this article, we explored how to fix the 'too many authentication failures' and 'permission denied (publickey)' errors when connecting via SSH. I shared how I solved similar issues when they occurred in my work. There might be other cases not described in the article that lead to such errors. If you know other solutions, please share them in the comments!
