Too many authentication failures for *username*

Question

I have a hostgator account with ssh access enabled and when trying to upload the generated .pub key file with this command:

rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub username@111.222.33.44:.ssh/authorized_keys

I keep getting:

Received disconnect from 111.222.33.44: 2: Too many authentication failures for username
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]

I've been toying around previously with ssh until i got the auth failure. But now seems that the auth failure counter does not reset (been waiting more than 12 hours now, tech support "suppose" it resets after 30 min to 1 hour, and another guy told me "it resets every time you try to login with the username", jeesh).

This is driving me nuts. I even had setup this in a Slicehost custom server and had less issues than with these guys. Any tip? Perhaps it's something client side and not server side.

Answer 1

This is usually caused by using multiple different ssh keys for a server without turning on IdentitiesOnly.

To get access to your account, get your host to run ssh-add -D to clear the identities. Once you are logged back in, add this to your ~/.ssh/config file:

IdentitiesOnly yes

Answer 2

I was getting this error too and found that it was happening b/c the server was configured to accept up to 6 tries:

/etc/ssh/sshd_config
...
...
#MaxAuthTries 6

In addition to setting the IdentitiesOnly yes in your ~/.ssh/config file you have a couple of other options.

1. Increase the MaxAuthTries (on the ssh server)
2. delete some of the key pairs you have present in your ~/.ssh/ directory & run ssh-add -D
3. explicitly link a key to a given host in your ~/.ssh/config file

Like so:

host foo
hostname foo.example.com
identifyfile /home/YOU/.ssh/foo

#1 is probably not a good way to go about it, given it weakens your ssh server a bit since it'll now accept more keys in a given connection attempt. Think brute force attack vectors here.

#2 is a good way to go assuming you have keys that are not needed and can be permanently deleted.

#3 and the approach of setting IdentitiesOnly are probably the preferred ways of dealing with this issue!

Answer 3

I found an easier what to do this:

ssh -o PubkeyAuthentication=no username@hostname.com

This forces non-key authentication. I was able to logon immediately.

Reference