Weblog

Thoughts which doesn't affect the world's peace

If you have read my previous posts about using ssh config file and passwordless ssh login probably you already got your config file filled with host declarations and you got your keys (one for each server) in place. Here is the solution for a very common problem, yet a problem which is widely spread nonsense on the net. This problem occurs when you use ssh key authentication. A lot of websites states that you have to add your key files with a “identifyfile” directive in the ssh config file, which is yet another nonsense. The correct directive is “IdentityFile”. A lot of websites (blogs and forums) suggests that you increase the connection attempt limit of your servers to avoid this. But that is WRONG! Just think about it….

Why you get “too many authentication failures” error message? You can see by issuing the ssh command with -v option or with -vv or -vvv for higher verbosity. Here is example output of ssh -vvv <server> (just the last few lines):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: user@hostname
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering RSA public key: user@hostname
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering RSA public key: user@hostname
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering RSA public key: user@hostname
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering RSA public key: user@hostname
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering RSA public key: user@hostname
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering RSA public key: user@hostname
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
Received disconnect from server: 2: Too many authentication failures for username

As you can see, it tries several times to connect and gets error, so you get disconnected when you reach the maximum allowed connection attempts of the server. So the statement that increasing the maximum connection attempts on your server helps is true, but it’s still not the right thing to do. It will work, but you don’t want it to work that way.

The reason for this is that the ssh client cannot locate your key files, so it tries any and all key files it finds in your $HOME/.ssh folder.

Here is a typical ssh config host declaration block:

1
2
3
4

Host serveralias
Hostname ip_or_FQDN
User username
IdentityFile idfile

When the ssh client cannot find the identity file “idfile” it starts looking for alternatives. You’ll say “okay, but my files ARE there” and you will be right, however the problem with IdentityFile is that it is relative of the current working directory. For this to work correctly, change the IdentityFile directive to “.ssh/idfile”. This way, when you open up a terminal, you will be able to connect with ssh serveralias and you wont get errors, however if you change your working directory to say Desktop, it wont work, because as I said already – it’s relative to the working directory. Change back to your homedir and it all will be fine again.

Tags: authentication failure, itentity file, remote connection, ssh, ssh keys

This entry was posted on Thursday, April 26th, 2012 at 9:26 am and is filed under "How to...", Administration (Linux), Linux. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.