DISCLOSURE: This post may contain affiliate links, meaning when you click the links and make a purchase, we receive a commission.
Cloud computing is the de facto standard in the IT industry. Everything from server deployments and company databases is handled by cloud computing providers. Additionally, if you want to access a remote machine in the cloud, chances are you will have to use the SSH protocol to do so.
However, it becomes a problem when your SSH client returns you the ‘Too Many Authentication Failures’ error. If you are facing such an issue, then fret not, as we have you covered. Keep reading this article to find out how to mitigate this error and learn something about how and why this error occurred in the first place.
What Is SSH
Before we head on, we need to understand how the SSH protocol works so that you can better understand the issue at hand. The SSH protocol provides a secure network connection through encryption that allows two devices to communicate over said network.
The SSH protocol has a public key that resides on the server and a private key that remains with the client device. When the user logs in, the remote server authenticates the user by checking the public key against the private key.
Reason For “SSH Too Many Authentication Failures” Error
It is the locally stored private key that we just discussed that is the cause of the error. Not that the required key is missing or corrupted, but it’s due to the procedure the SSH client uses to find the right key. If you have a lot of keys in your .ssh directory, then what the client does is that it goes through each key, trying it out to see if it verifies.
The problem arises as, by default, the SSH server usually has a small limit (usually five) on how many attempts a connection can make before it refuses to verify it. In our case, it presents us with the ‘Too Many Authentication Failures’ error.
You can circumnavigate this easily if you have a lot of unused SSH key/ identity files by simply deleting all the unused ones, and if the final number is small enough, you are good to go. However, if you must have a lot of keys in your machine, then follow the below-mentioned steps to solve the problem.
Fix “SSH Too Many Authentication Failures” Error
So, with the causation in mind, we can take two different routes to solve this problem, either allow the server to check more keys vis-a-vis increasing its check limit (known as MaxAuthTries) or include the reference to the key itself so that the server doesn’t need to go through all the keys.
The server SSH service has a property that limits the max number of attempts a client can try before it invalidates its connection. By default, it is a small number, but we can easily change it. To be specific, this property is called ‘MaxAuthTries’, and changing it is as easy as following a few steps.
- Log into your server machine
- Navigate to /etc/sshd_config
- You will see the MaxAuthTries attribute; simply change it to a larger value, such as 20.
- Viola! That’s all there was to it
Enable Identities Only Check
If the remote server is inaccessible or you want a quick local fix, then there’s another solution as well. With this one, you can do it right on your local machine, but the caveat is that if you have multiple devices with this error popping up, you have to do this step on each one.
- Log into the client machine
- Navigate to ~/.ssh/config
- Add a new line at the end: ‘Identity File: *add the path to the ssh_key*’
- Finally, add another line after this: ‘IdentitiesOnly=yes’
- Thats it!
Disable Public Key Authentication
Finally, if you do not want to get into the nitty-gritty and mess with config files, then you could simply disable public key authentication in the command line when you run the ssh command. This can be achieved using the optional -o argument. For example: $ ssh -o PubkeyAuthentication=no root@host
While all of the solutions we have provided in this troubleshooting guide are valid ones, if you have a lot of machines in your network that need ssh validation to a remote server, then we recommend changing the inherent setting in the server itself.
This will make it so that that’s the only thing you need to fix, and all the local machines and any other future additions are error-free when they use the SSH protocol.