9

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
Improve this question
6
  • Good idea for separate question. I'm looking at my (successful) login's debug output. I see "we did not send a packet, disable method for dsa and we send a publickey packet, wait for reply for rsa. How absolutely certain are you the keys on server and client are correctly paired?? Commented May 27, 2015 at 10:40
  • It indicates that the SSH server cannot access the authorized_keys file... Does your SSH server run under another account than root? Commented May 27, 2015 at 11:40
  • @Otheus I just checked again, the pair matches Commented May 27, 2015 at 12:02
  • @Nasha Yes, login with other users works. For example, login with the same username as the client works fine Commented May 27, 2015 at 12:02
  • 1
    Interesting. I don't see a line such as debug2: key: /home/remi/.ssh/id_rsa (0x7fb7031da7e0). That might have been in the output above the point you posted. Set StrictModes=no on the server and try again. After testing, remove it again. At least it will tell us which direction the problem lies. Commented May 27, 2015 at 13:21

7 Answers 7

Reset to default
25

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).
Improve this answer
4
  • 1
    chmod 755 did the trick, omg why would that be a problem Commented Sep 12, 2019 at 10:07
  • 2
    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. Commented Sep 13, 2019 at 17:09
  • 1
    If this doesn't work, make sure that authorized_keys has also 644 access. Commented Aug 21, 2020 at 14:42
  • According to this answer, permission 700 should also work Commented Mar 16, 2021 at 17:21
5

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

StrictModes no
Improve this answer
3
  • 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. Commented Dec 11, 2021 at 9:24
  • @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. Commented Dec 11, 2021 at 9:35
  • @PJBrunet I think the answer is good. I can not remember, why did I flag it. Probably it was a review. Commented Dec 11, 2021 at 11:08
2

In Ubuntu 22.04 (running this on AWS EC2 with an RSA key instead of a ED25519 key for the default user 'ubuntu' I get the same error: Permission denied (publickey).

The cause is that the RSA-SHA1 algorithm is being quickly deprecated.

And so I get this in /var/log/auth.log: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

The solution for this is mentioned in the same link above.

HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa

in the /etc/ssh/sshd_config file followed by a systemctl restart ssh.service

If you use Ubuntu 22.04 as an SSH client for a server with RSA-SHA1 keys, you have to use the same 2 lines in your ~/.ssh/config file instead. And if you have to use the same set of keys across versions, you have enable those two lines everywhere on both sides, depending on what SSH's into what. This is a workaround and technically insecure, so this should be treated as a stop-gap for transitions not a permanent fix. I guess over time, you should start updating / upgrading your systems and moving to stronger keys e.g. ED25519 keys.

Improve this answer
1

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.

Improve this answer
1
  • 1
    You can use different keys for login if you use appropriate options in ~/.ssh/config, like IdentityFile ~/.ssh/key2 in a Host myhost2 section. Commented Nov 3, 2017 at 15:16
0

Is the server configured to accept RSA keys?

Ensure RSAAuthentication yes is in sshd_config file.

Improve this answer
3
  • Yes, login with other users works. For example, login with the same username as the client works fine Commented May 27, 2015 at 11:50
  • is this option still valid in OpenSSH_7.6p1 ?? Commented Jun 10, 2020 at 22:07
  • 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. Commented Jul 15, 2020 at 4:55
0

I ran into a problem where I'd get we did not send a packet, disable method because the private key file did not have a newline (\n) at the end of the last line.

This was for an Ed25519 key, not RSA (with an RSA private key, I did not experience this problem!).

Improve this answer
2
  • Doesnt seem to be an issue in 2021. Commented Jan 17, 2021 at 18:55
  • @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? Commented Jan 17, 2021 at 21:18
0

If you're British, there's one specific possibility... I spent a whole evening trying to solve this before I realised that I'd named ~/.ssh/authorized_keys as ~/.ssh/authorised_keys.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.