“Too many authentication failures” with SSH -

Whenever you try SSH to your server using pageant (with Putty) or ssh-agent, have you ever got similar error message as follows:

"Received disconnect from 10.0.0.1: 2: Too many authentication failures for user-name"

if YES is the answer, please continue reading this article. This article will discuss about how to troubleshoot this error.

This issue is caused by accidently offering multiple ssh keys to the server. The server will reject any key after the MaxAuthTries count mentioned in the server’s /etc/ssh/sshd_config file.

Inorder to confirm that the server is rejecting your keys, try to SSH in verbose mode.

shiroy@desktop:~$ ssh -vl user-name server
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/shiroy/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server [10.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/shiroy/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/shiroy/.ssh/id_rsa-cert type -1
debug1: identity file /home/shiroy/.ssh/id_dsa type -1
debug1: identity file /home/shiroy/.ssh/id_dsa-cert type -1
debug1: identity file /home/shiroy/.ssh/id_ecdsa type -1
debug1: identity file /home/shiroy/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 2c:ef:f1:45:03:de:ab:1c:8a:c5:bc:b8:16:aa:32:9f
debug1: Host '54.77.138.163' is known and matches the ECDSA host key.
debug1: Found key in /home/shiroy/.ssh/known_hosts:10
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/shiroy/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: Violet.pem
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: Indigo.pem
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: Blue.pem
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: Green.pem
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: Yellow.pem
Received disconnect from server: 2: Too many authentication failures for user-name

shiroy@desktop:~$ ssh-add -l
2048 89:b6:2e:f7:95:5f:4c:6e:b8:24:d8:9c:cd:f8:4f:5c Violet.pem (RSA)
2048 ae:79:67:7b:9c:81:2b:6f:ed:4e:de:d7:76:e4:d6:aa Indigo.pem (RSA)
2048 57:3c:84:ad:c7:b4:99:ee:aa:17:e9:86:60:fe:4e:13 Blue.pem (RSA)
2048 46:79:8f:7b:12:77:84:4d:39:71:2c:86:4e:8e:95:98 Green.pem (RSA)
2048 d5:dc:80:67:c4:6b:c5:19:4c:4b:1b:1d:df:86:ac:b4 Yellow.pem (RSA)
2048 2a:2f:30:c1:bd:a4:a4:23:93:37:4d:72:d5:0e:1e:77 Orange.pem (RSA)
2048 6c:be:95:3f:37:23:2a:1e:45:59:0f:cf:67:9a:4a:6a shiroy@desktop (RSA)

In the above example, the actual Private Key which would let me access the server is Orange.pem. But this key was never presented. Also you could notice that SSH tried with 6 Keys and returned the error ” Too many authentication failures for user-name”. This indicates that the value for the directive MaxAuthTries is set to 6 in the server’s /etc/ssh/sshd_config file.

Inorder to get access to the server and fix this issue, you will have to remove all the keys from the pageant (if using with Putty) or ssh-agent and add just the appropriate private key which can be used to access the server and SSH to the server.

In ssh-agent, to remove the added private keys, use the following command

shiroy@desktop:~$ ssh-add -D
All identities removed.

Now add the relevant Private Key which can be used to connect to the server

shiroy@desktop:~/Access_Keys$ ssh-add Orange.pem
Identity added: Ireland-Key.pem (Ireland-Key.pem)

shiroy@desktop:~/Access_Keys$ ssh-add -l
2048 2a:2f:30:c1:bd:a4:a4:23:93:37:46:72:d5:0e:1e:77 Orange.pem (RSA)

Once the key is added, SSH to the server. This time, you should be able to SSH successfully to the server as there is only a single private key.

shiroy@desktop:~/Access_Keys$ ssh -l user-name server
Last login: Tue Aug 12 16:21:46 2014 from desktop
[user-name@server ~]$

Once you logged in to the server, modify the directive MaxAuthTries in /etc/ssh/sshd_config file to a value higher or equal to the total no: of private keys you are adding to your ssh-agent or pageant utility. In this case I use 7 keys and hence I set the MaxAuthTries value to 10 in the file /etc/ssh/sshd_config file.

[user-name@server ~]$ grep MaxAuthTries /etc/ssh/sshd_config
MaxAuthTries 10
[user-name@server ~]$

Restart the SSH service in your server to make the changes in effect.

[user-name@server ~]$ sudo service sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]
[user-name@desktop ~]$ exit
logout
Connection to server closed.

Now you can add back the private keys to your ssh-agent/pageant and try connecting back to the server.