127

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

Improve this question
2

24 Answers 24

Reset to default
17

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.

Improve this answer
1
177

"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

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 [email protected] without the errors.

  1. Increase MaxAuthTries value on the SSH server in /etc/ssh/sshd_config (not recommended).
Improve this answer
11
  • 20
    This should really be the accepted answer!
    – BenMorel
    Dec 2, 2014 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, 2015 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, 2017 at 1:42
  • 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 -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, 2018 at 7:22
  • 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, 2021 at 4:46
176

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
Improve this answer
9
  • 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, 2015 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, 2017 at 19:37
  • 15
    This is the answer
    – smac89
    Jun 1, 2018 at 3:36
  • 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, 2019 at 15:30
  • 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, 2021 at 2:01
30

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.

Improve this answer
4
  • 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, 2019 at 19:35
  • 1
    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'
    – Avery Freeman
    Oct 29, 2020 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, 2021 at 5:52
  • 1
    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, 2022 at 5:07
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.

Improve this answer
3
  • 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, 2010 at 0: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, 2014 at 7:54
  • See also: serverfault.com/questions/139870
    – Curious Sam
    Jun 10, 2020 at 15:25
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.

Improve this answer
1
  • 3
    True, good advice, and not the answer to the question asked.
    – mlp
    Jan 21, 2022 at 20:23
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>
Improve this answer
2
  • 1
    This is what I really wanted every time I looked up this question!
    – Tmanok
    Sep 22, 2022 at 18:01
  • I am getting error pam_tally: Couldn't create /var/log/faillog pam_tally: Authentication error
    – Naren Verma
    Jun 27, 2023 at 11:43
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

Improve this answer
1
  • 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, 2022 at 22:44
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.)

Improve this answer
3
  • 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 2, 2017 at 6: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 2, 2017 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, 2019 at 10:40
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.

Improve this answer
1
  • True, good advice, and not the answer to the question asked.
    – mlp
    Jan 21, 2022 at 20:23
2

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.

Improve this answer
2

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.

Improve this answer
1

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.
Improve this answer
0

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

Improve this answer
0

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.

Improve this answer
0

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

Improve this answer
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
Improve this answer
0

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
Improve this answer
0

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:

enter image description here

If it in the jail then can can unban with: enter image description here

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.

Improve this answer
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.

Improve this answer
0

Having too many ssh keys in ~/.ssh directory may cause this problem. The ssh will try each and every key from the above directory and probably may end up attempting too many failed authentication before identifying the right key.

Adding an ssh_config as mentioned below will help ssh identify the correct key.

(~/.ssh/config)

Host *
  IdentitiesOnly=yes
Improve this answer
-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 !!

Improve this answer
3
  • 1
    This has nothing to do with the question.
    – Ken Sharp
    Jul 15, 2019 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, 2022 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, 2022 at 10:39
-3

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

Improve this answer
-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.

Improve this answer
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, 2017 at 21:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .