Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
add comment

6 Answers 6

up vote 90 down vote accepted

This is usually caused by inadvertently offering multiple ssh keys to the server. The server will reject any key after too many keys have been offered.

You can see this for yourself by adding the -v flag to your ssh command to get verbose output. You will see that a bunch of keys are offered, until the server rejects the connection saying: "Too many authentication failures for [user]". Without verbose mode, you will only see the ambiguous message "Connection reset by peer".

To prevent irrelevant keys from being offered, you have to explicitly specify this in every host entry in the ~/.ssh/config file by adding IdentitiesOnly like so:

Host www.somehost.com
  IdentityFile ~/.ssh/key_for_somehost_rsa
  IdentitiesOnly yes
  Port 22

If you use the ssh-agent, it helps to run ssh-add -D to clear the identities.

If you are not using any ssh hosts configuration, you have to explicitly specify the correct key in the ssh command like so:

ssh -i some_id_rsa -o 'IdentitiesOnly yes' them@there:/path/

Quick update: the 'IdentitiesOnly yes' parameter needed to be between quotes.

share|improve this answer
3  
it is not clear to me where to put this line. On the server that I am trying to log in to, .ssh/config only has information for other servers. Do you mean that this should go in the .ssh/config file on the computer I am trying to ssh from? If so, this is unclear because your answer says "once you are logged back in ..." –  David Jun 7 '12 at 17:39
    
@David Add it on the client side before you re-attempt the SSH connection. Worked for me, at least. –  Matthew Read Jun 12 '12 at 19:34
2  
I have to put the option in double quotes, like this: ssh -i some_id_rsa -o "IdentitiesOnly yes" them@there:/path/ –  knb Apr 23 '13 at 9:22
    
Windows users running PAGENT (Putty Agent), check to ensure you only have the keys you need loaded. I ran into this issue after accidentally loading ALL my private keys. –  Chris Rasco Nov 19 '13 at 22:41
    
However, for sshfs (fuse) I have to write the option with an obligatory equals sign, like this: sshfs -o "IdentitiesOnly=yes" -o IdentityFile=~/.ssh/id_dsa them@there/var/tmp /mnt/tmp (Ubuntu 13.10) –  knb Jan 17 at 11:42
show 1 more comment

I found an easier way to do this (if using password authentication):

ssh -o PubkeyAuthentication=no username@hostname.com

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

Reference

share|improve this answer
1  
+1, wish i could give you more. Raspberry Pi is the only device I ssh into without public key. Was getting: "Too many authentication failures for pi" –  blak3r Dec 22 '13 at 7:05
    
Great answer - thanks for sharing :) –  Damian Walczak Jul 17 at 9:38
add comment

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!

share|improve this answer
add comment

If you get the following SSH Error:

$ Received disconnect from host: 2: Too many authentication failures for root

This can happen if you have (default on my system) five or more DSA/RSA identity files stored in your .ssh directory and if the '-i' option isn't specified at the command line.

The ssh client will first attempt to login using each identity (private key) and next prompt for password authentication. However, sshd drops the connection after five bad login attempts (again default may vary).

If you have a number of private keys in your .ssh directory you can disable "Public Key Authentication" at the command line using the '-o' optional argument.

For example:

$ ssh -o PubkeyAuthentication=no root@host
share|improve this answer
add comment

Going off @David saying, just add this IdentitiesOnly yes to your .ssh/config, it does the same thing as ssh -o PubkeyAuthentication=no.

After you logged in, remove .ssh/authorized_keys. Now, go back to the local machine and type the following

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no user@IP_ADDR 'cat >> .ssh/authorized_keys'. This should re-enable your ssh with public key

share|improve this answer
add comment

I know this is an old thread, but I just wanted to add in here that I ran into the same error message, but it was caused by the owner of the .ssh folder being root rather than the user that was using the key. I corrected the issue by running the following commands:

sudo chown -R user:user /home/user/.ssh

I also made sure the permissions were correct on the .ssh folder:

sudo chmod 700 /home/user/.ssh

The files within the .ssh directory should have the permission of 600:

sudo chmod 600 /home/user/.ssh/authorized_keys
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.