Fix "Too many authentication failures" SSH error

I finally took the time to troubleshoot an issue that had been bothering me for some time. I have been experiencing more and more a Too many authentication failures error while connecting to remote systems using SSH.

Received disconnect from a.b.c.d port 22:2: Too many authentication failures

I noticed this was especially happening on Photon OS appliances (almost all VMware appliances now).

Troubleshoot the Too many authentication failures error

TL;DR: this error is often caused by inadvertently offering too many SSH keys to the server (compared to the MaxAuthTries parameter). The server will reject any key after too many keys have been offered.

How to troubleshoot the SSH client? Easy, just RTFM! 😅

-v      Verbose mode. Causes ssh to print debugging messages about its progress.
        This is helpful in debugging connection, authentication, and configuration problems.
        Multiple -v options increase the verbosity.  The maximum is 3.

So, running the SSH client -v switch allows you to run the SSH connection in verbose mode, which prints useful debugging information. There are different verbosity levels; using multiple -v flags increases the verbosity (maximum verbosity level is 3).

SSH uses public-key cryptography to authenticate the remote computer and allow it to authenticate the user, if necessary. There are several ways to use SSH; one is to use automatically generated public-private key pairs to simply encrypt a network connection, and then use password authentication to log on. Another is to use a manually generated public-private key pair to perform the authentication, allowing users or programs to log in without having to specify a password.

Let’s analyze the portion of the output that interests us.

debug1: Offering public key: /Users/rdecker/.ssh/id_rsa RSA SHA256:<redacted>
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /Users/rdecker/.ssh/id_dsa
debug3: no such identity: /Users/rdecker/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /Users/rdecker/.ssh/id_ecdsa
debug3: no such identity: /Users/rdecker/.ssh/id_ecdsa: No such file or directory
debug1: Offering public key: /Users/rdecker/.ssh/id_ed25519 ED25519 SHA256:<redacted>
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 1
Received disconnect from 10.67.29.112 port 22:2: Too many authentication failures

You can notice that 2 keys are offered for the authentication (id_rsa and the id_ed25519) before the password. I indeed recently decided to switch to an Ed25519 key (based on Elliptic Curve Digital Signature Algorithm - ECDSA) instead of a typical RSA key. However, I did not delete my RSA key from my ~/.ssh/ folder. 😬

Note: If you’re interested in knowing more about Ed25519, the Ed25519 for SSH article is very complete.

Why does this happen more often on Photon OS and not on my regular Ubuntu or CentOS templates? The answer is quite simple: the SSH daemon is enforced to only accept 2 authentication tries in Photon OS.

MaxAuthTries specifies the maximum number of authentication attempts permitted per connection. Each key tried by the SSH client counts as one authentication attempt. Once the number of failures reaches half this value, additional failures are logged. Setting the MaxAuthTries parameter to a low number will minimize the risk of successful brute force attacks. While the default is 6, Photon OS is configured to accept only 2.

Fix the Too many authentication failures error

In my situation, the fix was easy: I’m not using my RSA key anymore, so I deleted it. 😎

Alternate solutions:

• Increase the MaxAuthTries on the server (definitively an option, but I don’t recommend it)
• Edit the ~/.ssh/config (on the client) and add IdentitiesOnly blocks so that a connection to a specific host only tries the associated key
• Force non-key authentication, e.g.: ssh -o PubkeyAuthentication=no romain@hostname.com

Moral of the story

I was happy to finally identify and fix this recurring issue. It wasn’t very complex to troubleshoot and fix it; don’t wait too long before solving your issues, it’s sometimes only a matter of minutes!