How to recover from "Too many Authentication Failures for user root"

Question

I've done several attempts to establish SSH-connecton for user root@host using putty terminal. While doing so I specified wrong credentials several times and after that I've specified them correctly, and then after the credentials were accepted the ssh session breaks with

"Server unexpectedly closed network connection".

This error is reported by putty terminal. When trying to ssh root@localhost from the local console - it works fine. It also works fine when I ssh otheruser@host from other host. So network connectivity issues are not guilty. The only error I am thinking of is: "Too many Authentication Failures for user root" although putty reported a different error.

The question is: how to recover from this error condition and let putty login again? Restarting sshd seems to not help

http://superuser.com/questions/187779/too-many-authentication-failures-for-username — Ciro Santilli OurBigBook.com, Mar 09 '16 at 16:28
Be sure to disable your ssh agent (e.g. pageant on Windows) if you get a `Too many Authentication Failures` error before you are able to login at all. — Mahn, Mar 30 '16 at 16:27

score 174 · Answer 1 · edited Aug 17 '21 at 19:24

174

"Too many Authentication Failures for user root" means that Your SSH server's MaxAuthTries limit was exceeded. It happens so that Your client is trying to authenticate with all possible keys stored in /home/USER/.ssh/ .

This situation can be solved by these ways:

ssh -i /path/to/id_rsa root@host
Specify Host/IdentityFile pair in /home/USER/.ssh/config

A single host in the config file should look something like this:

Host example.com
  IdentityFile /home/USER/.ssh/id_rsa

You can also set the user so you don't need to enter it on the command line and shorten long FQDN's too, see this example:

host short
  IdentityFile /home/USER/.ssh/id_rsa
  User someuser
  HostName really-long-domain.example.com

You then connect to the really-long-domain.example.com server with:

ssh short

Note: if you choose to use only the second option, and try to use ssh example.com you will still get errors (if that;s what brought you here), the short version will not give the errors, you can also use both options so you can ssh anyuser@example.com without the errors.

Increase MaxAuthTries value on the SSH server in /etc/ssh/sshd_config (not recommended).

edited Aug 17 '21 at 19:24

CodingInTheUK

143
9

answered Apr 05 '11 at 21:33

Peta Sittek

1,852
2
11
6

20

This should really be the accepted answer! – BenMorel Dec 02 '14 at 20:00
4

To be an accepted answer, the answer would really have to be about the software mentioned in the question. =) – rakslice Apr 07 '15 at 04:26
4

Another cause of the limit being exceeded could be your ssh agent. `ssh -vv` showed multiple versions of two keys (supplied by ssh-agent) being tried. I assume this is due to me rebooting infrequently and having replaced some keys that expired; apparently ssh-agent doesn't overwrite old keys with new ones. I killed ssh-agent and the problem went away. – Mark Jul 11 '17 at 01:42
What drawback would there be from increasing `MaxAuthTries`? I doubt many attacks are carried out by attempting lots of different keys. Besides if an attacker wanted to do that, they can just close the connection and open a new one each time they hit the limit. They are not going to succeed in brute forcing a key anyway. – kasperd Sep 18 '17 at 19:12
@Mark Thank you! Restarting ssh-agent fixed it for me! – winduptoy Sep 26 '17 at 14:33
2

I would combine #2 with moving all (or most of) your ssh keys to a separate directory, say `~/.ssh/keys`. When no specific key is given (via the `-i`option or the `config` file), ssh tries all keys from `~/.ssh` before even attempting to offer a password prompt. If you have many ssh keys, that means you never get to the password prompt on a new server. – daniel kullmann Jul 17 '18 at 07:22
This, and @WillVerna's post, are the best answers, and are buried down a long list of low-usefulness posts... – dr_ Sep 25 '18 at 14:12
`ssh -o IdentitiesOnly=yes -i path/to/key.pem username@host` did the trick for me after discovering this ansnwer – Roberto Mar 17 '20 at 21:01
I do git clone from a local debian server (192.168.178.x) on powershell and get `fatal: protocol error: bad line length character: git@..FATAL ERROR: Server sent disconnect message type 2 (protocol error): "Too many authentication failures"`. On another powershell client pc, it works without error. The client user id_rsa.pub is in the authorized_keys of the git user on the server. Git clone from github works from this client, but not from the local server in the home network. – Timo Nov 03 '20 at 08:28
@kasperd Maybe its hard to brute a key, but its not hard to flood a server with auth requests. Sure if somebody wanted to they could do it no matter how many you set it to, even just one, with a script they could hit you with a loop of endless single auth attempts and likely take down the service/possibly the server. limiting it is more about speeding up the auth to allow a user to connect more quickly. – CodingInTheUK Aug 12 '21 at 01:35
1

@danielkullmann I missed your comment here last time i visited this question. You made a very good point there. moving the certs to another directory would eliminate the problem. You could still keep a "general use" cert in .ssh for places where you are less concerned about the security. Assuming you have any of those, if you are using certs for authentication its probably safe to assume security is high on your priorities. All the same its a good catch.Something i would like to see is cert authentication becoming common place but I doubt that will be any time soon. – CodingInTheUK Aug 17 '21 at 04:46

score 162 · Answer 2 · edited Apr 22 '15 at 13:38

162

If you get the following SSH Error:

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

This could happen if you have (default on my system) five or more DSA/RSA identity files stored in your .ssh directory. In this case 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).

So if you have a number of private keys in your .ssh directory you could disable Public Key Authentication at the command line using the -o optional argument.

For example:

$ ssh -o PubkeyAuthentication=no root@host

edited Apr 22 '15 at 13:38

ThoriumBR

5,302
2
24
34

answered Sep 20 '13 at 21:36

Will Verna

1,621
1
10
3

2

Thank you so much! Using Ubuntu Server here which I can access only by SSH. I had set "MaxAuthTries 1" after blindly followed a tutorial on internet. – Andre Figueiredo Oct 06 '15 at 21:15
You just saved my life! Not using key auth so the other answers weren't helping. This solved it soooo easily!! – George Green Jan 16 '17 at 19:37
14

This is **the** answer – smac89 Jun 01 '18 at 03:36
I simply copied across my key again, using password authentication, and now it works every time. I have many keys in my `.ssh` directory, I don't think it's the amount that matters. – Ken Sharp Jul 15 '19 at 11:17
1

This is the most relevant answer and should really be the default behavior for ssh-copy-id hence if I like to copy my id to a server, it usually isn't there. But if ssh tries first to authenticate against the server using pubkey, the server aborts the connection before being able to enter the password. – Sprinterfreak Jul 28 '19 at 15:30
I am using ssh agent forwarding ( -A option) so I can not specify identity file by "-i" because the identity file does not even exist on the machine of issuing ssh command, but still want pubkey auth, what should I do? – sevenever Oct 17 '19 at 06:36
This happens to me quite often while I'm tinkering with a new cloud server I set up for experimentation, since I have several keys in `/.ssh` and haven't copied yet any public key to the server. Setting `PubkeyAuthentication=no` in `ssh-copy-id` allows me to copy the key and then login flawlessly. – gerlos Mar 29 '21 at 08:20
1

@KenSharp The number of keys matter, but only in so far as the key order matters. If your key happens to be within the limit you will not have an issue. However, if max tries is set to 5 and your key is not in those first 5 then you will get tried out. – CodingInTheUK Aug 12 '21 at 02:01
Was kinda surprised to find that this is not the default approach \o/ – danwild Jul 19 '22 at 04:27

Ninjaxor · Answer 3 · 2017-12-02T23:25:17.723

26

For me this problem was solved by creating the below ssh_config for the host I was connecting to.

(~/.ssh/config)

Host example
HostName example.com
User admin
IdentityFile ~/path/to/ssh_key_rsa
IdentitiesOnly=yes

The problem occurred because I have way too many ssh keys in my ~/.ssh folder, like 16 or so. And without both of those IdentityFile AND IdentitiesOnly directives in the config, my machine was apparently trying all of the keys in ~/.ssh and reaching the max number of attempts before attempting the correct IdentityFile.

edited Dec 02 '17 at 23:25

answered May 12 '17 at 22:11

Ninjaxor

449
5
7

2

I have ~30 keys in my config which caused this OP error on a new small device. I added the "IdentitiesOnly=yes" and it connected. I learn something new every day... – dturvene Dec 15 '19 at 19:35
The 'IdentitiesOnly=yes' flag is really helpful. You can also make a wildcard host for your config file over the hosts you would like to use it with, I've got 'Host * IdentitiesOnly=yes PreferredAuthentications=publickey' – AveryFreeman Oct 29 '20 at 16:31
This fix my issue, it work for ssh and sftp command line but not for sftp client like filezilla – Mohamed EL HABIB Apr 23 '21 at 05:52
After updating ssh-server I got this issue, looks like the defaults may have changed. Can add it as CLI parameter like this `ssh -o IdentitiesOnly=yes` – Pedro Apr 27 '22 at 05:07

score 25 · Answer 4 · answered Nov 09 '10 at 11:21

25

On the remote machine open /etc/sshd_config and change value

MaxAuthTries 30

This is typical problem when You have installed multiple keys or open multiple connections. Server checking step by step each key and if MaxAuthTries is setup on 3 then after first 3`rd tries will disconnect You. Typical ssh security.

I suggest You to use verbose mode during connection to remote machine to analyze problem.

ssh -v -p port_number user@servername

Guessing like most poeple on this forum do is WRONG and its wasting of time. First try to analyze problem, collect informations and then ask.

Have fun.

answered Nov 09 '10 at 11:21

In my specific case, the problem was that I was logged in with agent forwarding, trying to run a script that used it's own SSH identity. When I ran it with agent forwarding, it was too many identities before it tried it's own. So I set up the script to throw away the agent environment and that cleared it up. I also could have increased the MaxAuthTries, but I didn't need to in this case. – Sean Reifschneider Nov 21 '10 at 00:04
3

Thanks. `-v` showed my ssh client trying to use multiple keys (I have quite a few now). I cleaned them from the agent with `ssh-add -D` – joeytwiddle Jul 14 '14 at 07:54
See also: https://serverfault.com/questions/139870 – Curious Sam Jun 10 '20 at 15:25

score 15 · Accepted Answer · answered Jul 06 '09 at 12:08

15

Are you sure that root login to ssh is allowed?

Check sshd_config and verify that root login is permitted. sshd will need to be restarted if the setting changes.

answered Jul 06 '09 at 12:08

damorg

1,226
7
10

how to restart sshd: https://www.cyberciti.biz/faq/howto-restart-ssh/ – Zé Carlos May 29 '20 at 13:19

score 12 · Answer 6 · answered Jul 06 '09 at 12:03

12

This is bad practice. Just have a regular user on the remote box and connect through ssh using it, then gain root access using su/sudo.

answered Jul 06 '09 at 12:03

Anonymous

1,550
1
14
18

3

True, good advice, and not the answer to the question asked. – mlp Jan 21 '22 at 20:23

score 12 · Answer 7 · answered Sep 18 '17 at 19:03

12

To temporarily address this issue until things can be fully addressed as noted elsewhere, you can reset a user's PAM tally so they can try again:

pam_tally --reset --user <USERNAME>
pam_tally2 --reset --user <USERNAME>

answered Sep 18 '17 at 19:03

andyfeller

241
2
3

1

This is what I really wanted every time I looked up this question! – Tmanok Sep 22 '22 at 18:01
I am getting error pam_tally: Couldn't create /var/log/faillog pam_tally: Authentication error – Naren Verma Jun 27 '23 at 11:43

score 7 · Answer 8 · edited Jul 30 '15 at 14:26

7

I fixed this problem in my systems by running following commands:

eval $(ssh-agent)
ssh-add  ~/.ssh/keyname

Then trying ssh in remote machine

edited Jul 30 '15 at 14:26

GregL

9,370
2
25
36

answered Jul 30 '15 at 11:08

Sunil Shakya

170
1
2

This answer is great. Even when I specify a specific key with `-i` my ssh tries to use the keys in ~/.ssh/ *first* and fails. This fixes that! – bbeecher Dec 28 '22 at 22:44

score 6 · Answer 9 · edited Apr 12 '18 at 13:34

6

I would recommend you, as Anon above posted, use another user to gain ssh access then use the su command to gain root access.

Also make sure to enable PermitRootLogin in the /etc/ssh/sshd_config file on the server.

edited Apr 12 '18 at 13:34

kenorb

6,499
2
46
54

answered Jul 06 '09 at 12:08

Rodent43

697
3
11

True, good advice, and not the answer to the question asked. – mlp Jan 21 '22 at 20:23

score 6 · Answer 10 · edited Nov 02 '17 at 06:40

6

I also faced the same issue. This can easily happen if you are using Pageant and have a large number of keys loaded into it, since these servers count each offer of a public key as an authentication attempt.

(This advice is taken from here.)

edited Nov 02 '17 at 06:40

MadHatter

79,770
20
184
232

answered Nov 02 '17 at 06:24

Prabath Dolawatta

519
1
5
13

3

We're not very keen on link-only answers around here, as the links rot, and the answer becomes useless. Keep the link, by all means, but if you could summarise the solution in a paragraph or two, you might well have yourself an upvotable answer here. – MadHatter Nov 02 '17 at 06:26
3

I hope you'll forgive my subsequent edit; now (I hope) it makes it clear that the advice you refer is to is the advice you give, but still credits the original source. +1 from me for trying hard to improve your answer! – MadHatter Nov 02 '17 at 06:42
I had "Too many authentication failures" problem in Putty, too. After I removed all other keys from PageAnt, finally logged in successfully. – klor Jun 06 '19 at 10:40

score 2 · Answer 11 · edited Apr 22 '15 at 12:20

I was bitten by a similar problem. However the real cause was that I had ForwardAgent yes in the config file of a machine along the pipe. I was connecting from machine A into machine B into machine C.

The error message was shown in the ssh attempt from B -> C, but it was caused by A having the forwarding active. So C was first served all the keys from A, and only then the ones from B.

It suddenly appeared when I added one more key to A.

Fjor · Answer 12 · 2021-08-20T13:44:03.740

As @sufferer mentioned in another answer, some Linux distros include monitors to protect from brute force attacks on external visible services like SSH, for example DenyHosts or fail2ban. These monitors check the log files looking for failed attempts and add filters to block IP addresses that have too many failures (the number is configurable and independent from the sshd config).

If your distro includes fail2ban, which protect services adding rules to the iptables firewall, you could check which services or "jails" are supervised using the command:

sudo fail2ban-client status

The jail for the SSH service is sshd, so to check if there are banned IPs you can use:

sudo fail2ban-client status sshd

and to unban some IP a.b.c.d:

sudo fail2ban-client set sshd unbanip a.b.c.d

If you have DenyHosts, the banned list is in the file /etc/hosts.deny; you can edit this file directly as root. To grant some IP a.b.c.d permanent access, you could add the line sshd:a.b.c.d to the file /etc/hosts.allow.

As always, the man command is your friend:

man fail2ban
man hosts.deny

There should exist other similar utilities, but I only have used these.

Note that increasing the number of retries allowed in the sshd configuration does not free banned IPs, only permits more failures in the same connection. If the number allowed is exceeded, the user/attacker simply reconnects again to try n times more.

Other services had the ban list integrated (as shown in the answer of Rajnesh Thakur about restarting the VNC server).

Note: If you use fail2ban and use a jail.local file for configuring jails, add the following to the top of the file to stop your ip address being banned:

[DEFAULT]
ignoreip = 10.10.1.1 10.0.2.0/24

Restart fail2ban afterward, for example using systemctl restart fail2ban. The first IP allows a single address, the second allows all of subnet 10.0.2.x; adjust as required.

score 1 · Answer 13 · edited Apr 16 '12 at 06:06

1

I fixed this issue on my Mac by:

setting the root password with "sudo passwd root" then
editing and saving the ssh config file with "nano /etc/ssh_config" and
changing the RSAAuthentication to "no" rather than yes.

edited Apr 16 '12 at 06:06

Lucas Kauffman

16,880
9
58
93

answered Dec 28 '11 at 05:50

tallbr00

11
1

score 0 · Answer 14 · answered Jun 15 '21 at 10:18

Nixops refused to give me ssh connections, after doing ssh-add -l I found out I had many keys in the agent:

ssh-add -l
2048 SHA256:xxxxxxBXXEstjp/OODVNw/WAU/dNv+zu0/IxJZxTUWM /home/jappie/.ssh/id_rsa (RSA)
256 SHA256:xxxxxx+uIS0cAOdJIlRfc0Wild3aodjJY3Fs9j8WplI NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxMMxz5V379R++v7IjZpa+PGFikQ+WBhkN9yRAw NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxM4AJV1AhHL11wifU2o0y4Ky0pSSYlIHOxs+5o NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxjKWr/aJsQj6Cd8Vpe4Zo/7yb2luWSPlzoXaW8 NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxXoZkITGG/pTWkKq0ubXWT/Q3BwtyHWtVY3D8w NixOps auto-generated key (ED25519)
256 SHA256:xxxxxx3ZMmAXtuPnxX99vJoYr5rydkcRGfWufSFvIDg NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxFR/oD93DohmWdiS1QcwDS0tiJyRqX5uR8I4UE NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxV44yA+DhYHGvDle+i5YarMX3ugY2qUeHV6FKw NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxyoKllIkVQ6MEN2JwuOGHYmrnzSK51piaXSBew NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxlHHHkdH2zuxOSpBNw00c3dBcgonh9BO6dqwRY NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxebuWyWwUj1iiTbSNrb3Gd9Bq0cVOwWtVoKMDU NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxT0IA0ig94WKvhhamWtASQgjSfj2Ad3SDbPGdA NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxr3Hbndz86uSMIBHu/8ZNgPyOrAzpgcSf1JjgY NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxnTspGF7+kVe9/USm/PYUOsfu2kSUK2hG8i9Bc NixOps auto-generated key (ED25519)
256 SHA256:xxxxxx40Sb4izDy99l0CS5hfy8FYu3IbbyZhHnb6CTk NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxSV+yLE1pbD77sI5QOSf5fAq1Svj4ifGh0KIYU NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxva3zv+mgd22TwPAPTgO4dkrfb4pGMCGJejjyI NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxWmwOyUWdD+UezKDi+mYGcJF5OenFwHmHirv4I NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxeBMCRNiZXA9D8WSXA8zgT9k3wv2UUpbjWhqdo NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxoMN+z3H2yD4GwfoMgLA3i/xWRFZSnygNZGY4k NixOps auto-generated key (ED25519)
256 SHA256:xxxxxx6J3LYfDQk6koL8Zv6NEJhURllMmYLFffqYVJE NixOps auto-generated key (ED25519)
256 SHA256:xxxxxxfM94iCdSm8Fc2WxIyuqTeKiD9FuyVfvv+ctjA NixOps auto-generated key (ED25519)

ssh-add -D didn't work of course. What did work was using gpg-connect-agent directly, eg gpg-connect-agent 'keyinfo --list' (found here) which resulted in this for me:

S KEYINFO xxxxxxx2CECE4871B251B5EF291EE7A1841E02DC D - - - C - - -
S KEYINFO xxxxxxxC3F58B90BCF0272E5DF0C0162E5CE6F86 D - - - C - - -
S KEYINFO xxxxxxxB2F4BC9A48FD0948ACF8E57A6D5FEA353 D - - - C - - -
S KEYINFO xxxxxxx060C5B4E738BCEB42E092EC60B3A89F39 D - - - C - - -
S KEYINFO xxxxxxx1D6011780C890257107521213F1A8CF4A D - - - C - - -
S KEYINFO xxxxxxxFAE404870B8F4E53ABC5DD58A8F31F734 D - - - C - - -
S KEYINFO xxxxxxxB8D008C2F0F44DBF7690E7FA0C969D26E D - - - C - - -
S KEYINFO xxxxxxxD14B730225EE367C38C0E1D2796F59B2E D - - - C - - -
S KEYINFO xxxxxxxC2FF3C59717D668DE31E964A4F3CB6390 D - - - C - - -
S KEYINFO xxxxxxx658EA11F094597D1658ACFE91EED1E2C2 D - - - C - - -
S KEYINFO xxxxxxx192F4904A4350A06D299BEC9F1DBD882F D - - - C - - -
S KEYINFO xxxxxxxF5096859B707AFB2D4B0EA8283AEC8350 D - - - C - - -
S KEYINFO xxxxxxxAE3194884396AC27AB8FEDDAFD904868C D - - - C - - -
S KEYINFO xxxxxxxC3FB94F59DF75B09AA6B3C7D8C529AF23 D - - - C - - -
S KEYINFO xxxxxxx8204A609B025706B2420AC24BC0F9CBEE D - - - C - - -
S KEYINFO xxxxxxx00AAC043929D0C5F309B77E947914983A D - - - C - - -
S KEYINFO xxxxxxxA9AC520089E0EF4775824D7F5D981691A D - - - C - - -
S KEYINFO xxxxxxx6D0DDFBF294C0326845EA7A1C9B158A2F D - - - C - - -
S KEYINFO xxxxxxx99CD07C5DE54813BDF6C83F8746D343E7 D - - - C - - -
S KEYINFO xxxxxxx9E5A100363F3E8794F2E6BBA44F63976B D - - - C - - -
S KEYINFO xxxxxxxDCC46D5C998BFD2C3D5A2AF28357C481F D - - - C - - -
S KEYINFO xxxxxxxBB321AB73F242C4EEB48FC73A24AB7EEE D - - - C - - -
S KEYINFO xxxxxxx7F273F322DE256C7A188D50B9B6162047 D - - - C - - -
S KEYINFO xxxxxxxC99A1E0C119C64B6CDACB1B5E56EF4320 D - - - C - - -
S KEYINFO xxxxxxx6A90DEFE2CBFD47BDB499AD3E8FFD525F D - - - C - - -
S KEYINFO xxxxxxx12289B276F80910D626D1C09A26995A76 D - - - C - - -
S KEYINFO xxxxxxxF2EAB2BC1F863E364271D5C07D3AB8AF0 D - - - C - - -
S KEYINFO xxxxxxx5B4AC281DEF7EBCF4411FA7CF9A3BDF0B D - - - C - - -
S KEYINFO xxxxxxx0E10305BAA05252F00A5774CC4EFFE53D D - - - C - - -
S KEYINFO xxxxxxx9226C5B4F9EB3C595D0E1F579DD3B038C D - - - C - - -

which I modified with vim into gpg-connect commands and simply pasted in pg-connect-agent:

DELETE_KEY --force xxxxxxx2CECE4871B251B5EF291EE7A1841E02DC
DELETE_KEY --force xxxxxxxC3F58B90BCF0272E5DF0C0162E5CE6F86
DELETE_KEY --force xxxxxxxB2F4BC9A48FD0948ACF8E57A6D5FEA353
DELETE_KEY --force xxxxxxx060C5B4E738BCEB42E092EC60B3A89F39
DELETE_KEY --force xxxxxxx1D6011780C890257107521213F1A8CF4A
DELETE_KEY --force xxxxxxxFAE404870B8F4E53ABC5DD58A8F31F734
DELETE_KEY --force xxxxxxxB8D008C2F0F44DBF7690E7FA0C969D26E
DELETE_KEY --force xxxxxxxD14B730225EE367C38C0E1D2796F59B2E
DELETE_KEY --force xxxxxxxC2FF3C59717D668DE31E964A4F3CB6390
DELETE_KEY --force xxxxxxx658EA11F094597D1658ACFE91EED1E2C2
DELETE_KEY --force xxxxxxx192F4904A4350A06D299BEC9F1DBD882F
DELETE_KEY --force xxxxxxxF5096859B707AFB2D4B0EA8283AEC8350
DELETE_KEY --force xxxxxxxAE3194884396AC27AB8FEDDAFD904868C
DELETE_KEY --force xxxxxxxC3FB94F59DF75B09AA6B3C7D8C529AF23
DELETE_KEY --force xxxxxxx8204A609B025706B2420AC24BC0F9CBEE
DELETE_KEY --force xxxxxxx00AAC043929D0C5F309B77E947914983A
DELETE_KEY --force xxxxxxxA9AC520089E0EF4775824D7F5D981691A
DELETE_KEY --force xxxxxxx6D0DDFBF294C0326845EA7A1C9B158A2F
DELETE_KEY --force xxxxxxx99CD07C5DE54813BDF6C83F8746D343E7
DELETE_KEY --force xxxxxxx9E5A100363F3E8794F2E6BBA44F63976B
DELETE_KEY --force xxxxxxxDCC46D5C998BFD2C3D5A2AF28357C481F
DELETE_KEY --force xxxxxxxBB321AB73F242C4EEB48FC73A24AB7EEE
DELETE_KEY --force xxxxxxx7F273F322DE256C7A188D50B9B6162047
DELETE_KEY --force xxxxxxxC99A1E0C119C64B6CDACB1B5E56EF4320
DELETE_KEY --force xxxxxxx6A90DEFE2CBFD47BDB499AD3E8FFD525F
DELETE_KEY --force xxxxxxx12289B276F80910D626D1C09A26995A76
DELETE_KEY --force xxxxxxxF2EAB2BC1F863E364271D5C07D3AB8AF0
DELETE_KEY --force xxxxxxx5B4AC281DEF7EBCF4411FA7CF9A3BDF0B
DELETE_KEY --force xxxxxxx0E10305BAA05252F00A5774CC4EFFE53D
DELETE_KEY --force xxxxxxx9226C5B4F9EB3C595D0E1F579DD3B038C

Problem solved. Note that I replaced some of the signatures with x in case this is private (I don't think so and I deleted them anyway).

score 0 · Answer 15 · answered Jul 22 '21 at 09:18

0

If your server still has an enabled password authentication, you can copy your ssh-key to it using ssh-copy-id and avoid Too many Authentication Failures problem:

ssh-copy-id -i id_rsa_your_key.pub -p 22 -o PubkeyAuthentication=no username@server

answered Jul 22 '21 at 09:18

James Bond

103
3

score 0 · Answer 16 · answered Jan 12 '22 at 23:07

It's possible that there are some sshd errors which needs to be addressed.

Here is one example which I've experienced:

sshd[2999527]: Authentication refused: bad ownership or modes for directory /home/user

sshd[2999527]: message repeated 3 times: [ Authentication refused: bad ownership or modes for directory /home/user]

If you're using authorized key (ssh-add -L), and the permissions to home directory (e.g. 770) or ~/.ssh/authorized_keys file on the remote machine are bad (e.g. too wide), it won't authenticate you due to errors.

I was able to workaround the login by adding:

Host SOMEHOST
  IdentitiesOnly yes

which for some reason ignored the access to authorized_keys file and I was able to connect using a regular password in order to fix the directory permissions by:

sudo chmod 750 /home/$USER

score 0 · Answer 17 · answered Aug 21 '22 at 21:59

If this is from a VPS spun up by cloud provider then it may be because it's using fail2ban by default. SSH from another IP (or from provider's webportal if they have interactive ssh) and check to see if your IP was added to the sshd fail2ban jail:

If it in the jail then can can unban with:

Source: Recently had issue with new linode VPS where multiple failed logins of a user caused their IP to be unable to ssh into it.

score 0 · Answer 18 · answered Apr 11 '23 at 14:06

0

i had same problem with amazon Ubuntu 22 LTS, later found it to be the problem with pea-gent, try closing it and add auth key in putty and login it should work.

answered Apr 11 '23 at 14:06

preetam singh

101

score 0 · Answer 19 · edited Jan 25 '16 at 18:39

OK, so in my case this was pretty weird, here it goes...

I have a standard vagrant VM with an SSH key and I can SSH into it using Putty. While trying to get on it during deployment in PHPStorm I get too many authentication failures error. So I increased the MaxAuthTries in my sshd_config and then I got hit with Auth failed error and then Auth cancel.

Now, I don't know exectly why I even tried this but... I added the dot at the end of my SSH key path in the deployment window in PHPStorm. So it was like this:

C:\Users\Deadpool\\.ssh\chimichanga

and now it is like this:

C:\Users\Deadpool\\.ssh\chimichanga.

And it works... In my ".ssh" folder I have more files:

chimichanga - copy of "id_rsa" from vagrant machine
chimichanga.ppk
chimichanga.pub

I'm not sure what that fcuking dot does but using the .ppk file doesn't work so I guess it's kind of magic ;) Oh, and I could get rid of the MaxAuthTries after that "dot trick".

score 0 · Answer 20 · answered Sep 21 '18 at 19:27

Other answers tell you the best way to get connected as root, and the security implications of that, but your explicit question was

how to recover from this error condition and let putty login again?

You mention on the last time that you got connected then the remote server dropped the connection.

What I think you might find is that the remote server is running fail2ban(*) and it "jailed" your IP after your successful login. You can test this by trying to log in again, and you will not even get the login prompt.

There are two solutions, you can either wait out the jail time, at which point things simply go back to normal, but jail time could be anything. Or you can find different computer to log in from, do that and "un-jail" your IP, in this case "different" is from the perspective of the remote server, so another computer behind the same firewall probably won't work either.

(*) fail2ban is a super handy daemon that can periodically check various log files and adjust firewall rules to make the server "disappear" when it detect potentially malicious behaviour from a client. On debian, it comes out of the box configured to detect multiple failed ssh logins from a particular IP, and after 3 (I think) it will drop all packets from that IP. Works brilliantly to stop those scripted, brute force attacks.

score -1 · Answer 21 · edited Jul 15 '19 at 15:07

-1

I resolved this problem by two simple steps on my Ubuntu 16.04 server -

First stop my vnc server or kill the process -

vncserver -kill :1

and then start it again -

vncserver

After that connect it from Remote Desktop client -

192.0.2.99:5901

Done !!

edited Jul 15 '19 at 15:07

Patrick Mevzek

9,921
7
32
43

answered May 10 '17 at 11:39

Rajnesh Thakur

11
1

1

This has nothing to do with the question. – Ken Sharp Jul 15 '19 at 11:19
This actually helped me too. I was connecting to vnc and nothing helped until I just killed and restarted the vncserver – Aryeh Beitz May 30 '22 at 14:29
VNC uses a different protocol and has nothing to do with SSH failing unless you are tunneling VNC over SSH. – reinierpost Sep 30 '22 at 10:39

score -3 · Answer 22 · edited Dec 26 '14 at 19:28

-3

please follow below steps for resolution

Back up /etc/ssh/sshd_config
Increase value of MaxAuthTries in sshd_config
stopsrc -s sshd ; startsrc -s sshd

And check again after above changes

edited Dec 26 '14 at 19:28

Andrew Schulman

8,811
21
32
47

answered Dec 26 '14 at 19:05

Arun Mathuria

1

score -4 · Answer 23 · answered Jun 09 '16 at 19:23

-4

I had the same issue where i kept getting "SServer sent disconnected message type 2 (protocol error): Too many authentication failures for user"

I solved this issue by removing all my ssh (.ppk keys) then logged into the AD intergrated server.

answered Jun 09 '16 at 19:23

Eskimo-Jbk

1

This answer is not useful, and recommending removing .ppk files is dangerous. Please people, if you think you need to remove .ppk files (and I can't think of a good reason you'd want to), rename them to something else, don't delete them. They contain your keys, which you probably need. – Law29 May 27 '17 at 21:04

How to recover from "Too many Authentication Failures for user root"

23 Answers23

Linked