“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 '126.96.36.199' 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.