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


18 Answers 18


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.


"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:

  1. ssh -i /path/to/id_rsa root@host
  2. Specify Host/IdentityFile pair in /home/USER/.ssh/config .
    • Host host
    • IdentityFile /home/USER/.ssh/id_rsa
    • Host host2
    • IdentityFile /home/USER/.ssh/id_rsa2
  3. Increase MaxAuthTries value on the SSH server in /etc/ssh/sshd_config (not recommended).
  • 16
    This should really be the accepted answer! – BenMorel Dec 2 '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 7 '15 at 4: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 1: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
  • 1
    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 -ioption 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 7:22

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
  • 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 6 '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
  • 7
    This is the answer – smac89 Jun 1 '18 at 3: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

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.

  • 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 0:04
  • 2
    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 7:54
  • See also: serverfault.com/questions/139870 – Curious Sam Jun 10 '20 at 15:25

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


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

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.

  • 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 at 5:52

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.


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>

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

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

Then trying ssh in remote machine


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.)

  • 2
    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 2 '17 at 6:26
  • 2
    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 2 '17 at 6: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 6 '19 at 10:40

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.


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.


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).


I fixed this issue on my Mac by:

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

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:


and now it is like this:


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

chimichanga - copy of "id_rsa" from vagrant machine

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".


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.


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 -


After that connect it from Remote Desktop client -

Done !!

  • 1
    This has nothing to do with the question. – Ken Sharp Jul 15 '19 at 11:19

please follow below steps for resolution

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

And check again after above changes


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.

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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