Unable to login with SSH-RSA key

Question

This post is following this question : Authentication refused: bad ownership or modes for file /var/git/.ssh/authorized_keys .

The issue as exposed there is solved (about files modes of the .ssh folder.

But an other issue persists so I create a new question :

When I try to login (with verbose options), all seems to work fine but at the end, here is what happened :

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/remi/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/remi/.ssh/id_dsa
debug1: Trying private key: /home/remi/.ssh/id_ecdsa
debug1: Trying private key: /home/remi/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

I don't understand because these lines seems to be a non-sense for me :

• we sent a publickey packet, wait for reply
• we did not send a packet, disable method

Solution 1

You will get this behaviour if the file mode of the user's home directory on the destination host is not set correctly. It's not just the mode of the .ssh directory that has to be correctly set!

ssh to the host and give your password to login, then

chmod 755 ~
logout

Then ssh again and assuming you have everything else set up correctly (see the other answers), you should be able to login.

This is what it looks like when the home directory is wide open (777). Note that it doesn't try the rsa key:

ssh -v user@host
...
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/iwoolf/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/iwoolf/.ssh/id_dsa
debug1: Trying private key: /home/iwoolf/.ssh/id_ecdsa
debug1: Trying private key: /home/iwoolf/.ssh/id_ed25519
debug1: Next authentication method: password
...

Then with the home directory permissions set correctly (755):

ssh -v user@host
...
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/iwoolf/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).

Solution 2

I had a similar problem that resolved when is changed StrictModes from yes to no. Open /etc/ssh/sshd_config and add

StrictModes no

Solution 3

I made the mistake of naming my public and private key a non-standard name. Changing it back to "id_rsa" fixed the problem for me.

Comments

[Rémi B.]

Yes, login with other users works. For example, login with the same username as the client works fine

[Ned64]

You can use different keys for login if you use appropriate options in ~/.ssh/config, like IdentityFile ~/.ssh/key2 in a Host myhost2 section.

[WKordos]

chmod 755 did the trick, omg why would that be a problem

[woolfie]

By setting the home dir permissions to 755, you're removing group and other write permissions. This prevents another user on your system changing permissions of your .ssh directory and obtaining access to your private keys, so now ssh considers your key files secure enough to use.

[U.V.]

is this option still valid in OpenSSH_7.6p1 ??

[dave_thompson_085]

This option applied to SSHv1 only which was broken and unused since last century, although OpenSSH didn't actually delete the code until 7.6 in 2017-10. @U.V.: the config code has deprecated it since 7.4 in 2016-12. The SSHv2 options are PubKeyAuthentication (for all algorithms) since forever and PubKeyAcceptedKeyTypes (for specific algorithms) since 6.8 in 2015-03.

[gXg]

If this doesn't work, make sure that authorized_keys has also 644 access.

[marcelm]

@GabrielA.Zorrilla I can still reproduce the issue all the way up to openssh-8.4p1; it even says Load key "/home/marcelm/.ssh/id_ed25519": invalid format. If you are testing, are you sure your SSH key isn't cached by an agent?

[smac89]

According to this answer, permission 700 should also work

[PJ Brunet]

When this is on, the requirements are vague: "StrictMode checks some cases before the ssh server starts. Ssh key, configuration files ownership, permission checks are performed before ssh daemon starts. If one of them fails the ssh server daemon does not start." Would help to know exactly what StrictModes checks. However, "sshd_config" is for receiving connections (server issue.) The question here is about initiating "ssh" connections from outside, so more related to "ssh_config". IMO turning off StrictModes is a bad idea, it's probably turned on by default for a good reason.

[PJ Brunet]

@peterh Perhaps this answer explains why the accepted answer requires certain permissions? I would verify myself, but I have a completely different problem to solve.

[peterh]

@PJBrunet I think the answer is good. I can not remember, why did I flag it. Probably it was a review.