Too many authentication failures for username

Question

I have a hostgator account with ssh access enabled. 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 it seems that the auth failure counter does not reset (been waiting more than 12 hours now, tech support "supposes" 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 this set up in a Slicehost custom server and had fewer issues than with these guys.

Any tips? Perhaps it's something client side and not server side.

In my case there wa an mistake in generating the key. I generated a key and I missed to mention the source adress and used username at the end of the key. — Reporter, Aug 29 '19 at 12:49

score 464 · Accepted Answer · edited Dec 13 '17 at 12:40

464

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 (on the client machine) 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/

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

or

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

edited Dec 13 '17 at 12:40

Daniele Licitra

103
5

answered Sep 12 '10 at 17:53

John T

163,373
27
341
348

5

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 LeBauer Jun 07 '12 at 17:39
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 09:22
1

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 '14 at 11:42
it can be used without quotes, like this: `-o IdentitiesOnly=yes` – Valentin Kantor Jul 04 '14 at 13:28
Why can't we just can we just tell the SSH daemon via sshd_config to accept more keys? – Kaz Dec 07 '15 at 20:36
In my case it was sending public key I use for my different git repositories, while ssh doesn't use public key authentication. I had to add `PubkeyAuthentication no` in the config entry for the host. When not using .ssh/config, the following command line option will do it http://superuser.com/a/404460/15894 – chmike Aug 29 '16 at 11:08
This explains why my older server that didn't support `ssh-ed25519` was rejecting my login that provided two public keys (a legacy `rsa` and an `ed25519`), but the fix was different: my ssh_config had `MaxAuthTries` set to 1, but **each key** counts against that during a login, so it was failing after receiving the unsupported `ed25519` and logging the too-many-failures message. Raising `MaxAuthTries` to 2 fixed it. – Marco Jan 07 '17 at 20:37
6

The question remains: why does `ssh` "offer multiple keys" (anything under `~/.ssh`) even when the rule for host has an explicit `IdentityFile /path/to/private_key_file` setting. Shouldn't this explicitly specified key be (at the very least) offered first? Isn't this a bug/misfeature in the openssh client? – arielf Jan 26 '17 at 00:33
Whew, I thought my ssh was being brute forced :| – Captain Hypertext May 25 '17 at 15:53
3

But shouldn't it use the key specified with the `IdentityFile` option? For example, without the `IdentitiesOnly` option, it tries to use my `github` key when I try to `ssh gitlab.com`. It makes no sense. – Iulian Onofrei Oct 08 '18 at 14:57
Indeed, in some configurations `ssh-add -D` does not work - the agent updates only if the key is missing. Also, documentation should be clearer for `ssh-copy-id` because in most configurations, this does not work when PasswordAuthentication is disabled. Solution: *delete or rename your other keys*. – Ate Somebits Jan 02 '22 at 20:01
This solution doesn't work for `ssh root@` on a network of many hosts where my agent has the key for `root` _and_ a a bunch of other identities. – e40 May 11 '22 at 20:36

score 222 · Answer 2 · edited Jan 05 '13 at 14:24

222

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

edited Jan 05 '13 at 14:24

ctrl-alt-delor

2,326
19
29

answered Mar 25 '12 at 00:14

Ben West

2,536
1
13
7

3

+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 07:05
1

And to use that with `rsync`: `rsync -av -e 'ssh -o PubkeyAuthentication=no' 'user@host.com:~/remote_file' 'local_file'` – Ciro Santilli OurBigBook.com Mar 09 '16 at 17:03
2

You can also create an Alias to make it even quicker for password auth. alias sshp='ssh -o PubkeyAuthentication=no ' – dhempler Apr 27 '17 at 14:59

score 32 · Answer 3 · edited Dec 08 '16 at 03:10

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.

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

Like so:

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

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.
Is a good way to go assuming you have keys that are not needed and can be permanently deleted.
And the approach of setting IdentitiesOnly are probably the preferred ways of dealing with this issue!

In your last line you have identifyfile /home/YOU/.ssh/foo but it should be identityfile (a t not an f) — Nin, Sep 26 '14 at 10:05
In my case, just running `ssh-add -D` on my machine worked. Thanks! — Pranit More, Aug 20 '20 at 16:57

score 9 · Answer 4 · answered Jul 23 '14 at 17:29

9

I added to ~/.ssh/config this:

Host *
IdentitiesOnly yes

It enables option IdentitiesOnly=yes by default. If you'll need to connect with private key, you should specify it with option -i

answered Jul 23 '14 at 17:29

Евгений Шаповалов

91
1
1

score 7 · Answer 5 · edited Sep 20 '13 at 23:29

7

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

edited Sep 20 '13 at 23:29

David

9,144
3
24
41

answered Sep 20 '13 at 21:44

Will Verna

71
1
1

This was exactly what was happening to me! Thanks a lot for the explanation ;) – El Ninja Trepador Oct 04 '16 at 13:59
1

That's a fine workaround. But, you are really best setting up public/private key authentication, and disabling the root password. Allowing ssh via password generally opens the system up to brute-force attacks, which is especially bad for root. And, if you have root, you have the privileges to make those changes. Just food for thought. – Randall Aug 25 '22 at 13:50
I concur with Randall here. By turning off pubkey auth you are decreasing your security. Do not do this! The workaround is bad, given that the IdentitiesOnly Fix exists and is trivial to use. – GeckoGeorge Jan 02 '23 at 16:27

score 6 · Answer 6 · answered Jun 19 '15 at 14:22

If you have a password, and want to simply use the password to login, here is how you do it.

To use ONLY password authentication and NOT use Public-key, and NOT use the somewhat misleading "keyboard-interactive" (which is a superset including password), you can do this from the command line:

ssh -o PreferredAuthentications=password user@example.com

score 3 · Answer 7 · answered Jan 25 '14 at 05:48

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

score 2 · Answer 8 · answered Jun 13 '14 at 17:37

2

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

answered Jun 13 '14 at 17:37

Adam

21
1

I would be careful with using this without a caveat. SSH key permissions are usually restricted to 400 for some keys, particular AWS. Attempting to set them above that will result in the key not being accepted, and that can lock you out of your AWS account. – Michael Ryan Soileau Mar 09 '17 at 18:35

score 1 · Answer 9 · answered Feb 20 '16 at 22:57

1

In my case, the problem was directory permissions. This fixed it for me:

$ chmod 750 ~;chmod 700 ~/.ssh

answered Feb 20 '16 at 22:57

tbc0

309
3
13

score 1 · Answer 10 · answered Apr 12 '18 at 13:28

Too many authentication failures

This message is caused by having too many failed authentication attempts given the permitted limits enforced on the remote SSH server. This potentially means that you've too many identities added in the SSH agent.

Here are few suggestions:

Add -v to see if that's the case (you've using too many identities).
List added identities by ssh-add -l.
Remove failing identity from the agent by: ssh-add -d.
You may also deletes all identities by ssh-add -D and re-add only relevant one.
If you've access to SSH server, check the MaxAuthTries option (see: man sshd_config).

^{Related post: What is a connection for sshd_config's 'MaxAuthTries' limit?}
If none of this help, make sure whether you're using the right credentials or file.

score 1 · Answer 11 · answered Nov 24 '19 at 01:41

This was a fun one for me. Turns out I changed my password locally while in a localization mode different from a keyboard I was using to login remotely. This effectively made my password different from what I thought it was probably because one of my special characters was different from what the keyboard said it was.

score 0 · Answer 12 · answered May 05 '17 at 07:57

I had my public key in .ssh/authorized_keys2, but the server was configured to read only .ssh/authorized_keys:

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

After moving my file to .ssh/authorized_keys, I can log in successfully with my key.

score 0 · Answer 13 · answered Aug 25 '22 at 15:16

Smart cards (aka PIV, CAC, PKCS #11, HSM, or Cryptoki) add an additional level of complexity to this.

As John T suggests, I added the -v verbose logging to my ssh command to find why my ssh was failing. Whether I put in -i ~/.ssh/myrsa.pem or -o 'IdentitiesOnly yes' or even -o 'CertificateFile ~/.ssh/myrsa.pem', I still got the "Too many authentication failures" error from the system because it was still insisting on using opensc-pkcs11.so to present the certificate from the smartcard, which is not recognized by my personal EC2 instance.

Removing the smartcard let it drop back to RSA authentication. But, as a better workaround, to keep the smartcard in the system and still have ssh work with my RSA key, I can pass
-o PKCS11Provider = PKCS_disabled
on the command lineto my ssh command, and it will override the global ssh default.

It's still a workaround, since it will try to open a .so file for PKCS, and give you the error
dlopen PKCS_disabled failed: PKCS_disabled: cannot open shared object file: No such file or directory
but that creates an understandable error that forces it to fall back to RSA without having to pull my smartcard in and out.

score 0 · Answer 14 · edited May 23 '17 at 11:33

0

In my case, it was happening because I was using the username "ubuntu", but the username in this instance was "ec2-user"

After I did what "John T" suggested, I got this error:

Permission denied (publickey).

Then I found the solution (i.e. changing the username to "ec2-user") in this answer: https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue

edited May 23 '17 at 11:33

Community

1

answered Nov 19 '14 at 08:10

Deepak Joy Cheenath

101
4

score -1 · Answer 15 · edited Dec 06 '16 at 17:19

-1

This message can appear when the correct username and password is not entered.

First check that the user is listed:

vim /etc/passwd

edited Dec 06 '16 at 17:19

Gaff

18,569
15
57
68

answered Sep 26 '16 at 15:23

Matoeil

119
4

Too many authentication failures for username

15 Answers15

Linked

Too many authentication failures for *username*

15 Answers15

Linked

Too many authentication failures for username