Permission denied (publickey)

Question

This has dogged me for years.

Two IDENTICAL servers. Logged in to both as 'bob'.

Try to ssh from bob@server1 to bob@server2.

Permission denied (publickey).

On BOTH servers:

rm -r ~/.ssh

On server1:

ssh-keygen
ssh bob@server2

Permission denied (publickey).

Ok, so let's force it to use password instead:

mv ~/.ssh ~/oldssh
ssh bob@server2

Permission denied (publickey).

I've even tried putting the contents of server1's id_rsa.pub into the authorized_keys on server2 and server2's in server1.

None of this makes sense!

Answer 1

On BOTH servers:

rm -r ~/.ssh

On server1:

ssh-keygen
ssh bob@server2

How does server2 know that it's supposed to accept the brand new key you just made? It doesn't. After creating a key with ssh-keygen, you must copy it to server2's ~/.ssh/authorized_keys file.

I've even tried putting the contents of server1's id_rsa.pub into the authorized_keys on server2

Yes, that's basically required.

---

Ok, so let's force it to use password instead:

mv ~/.ssh ~/oldssh
ssh bob@server2

The error message indicates what mechanisms the server offered to you. In this case, because it only offers publickey authentication, clients cannot force it to use password or any other method.

To use password authentenableication, you first have to allow it in the server's /etc/ssh/sshd_config (using the PasswordAuthentication and ChallengeResponseAuthentication options).

Once that's done, you can even use ssh -o PreferredAuthentications=password bob@server2 to prefer a specific mechanism. That way you won't need to move the keys away temporarily, nor move them back.

---

This has dogged me for years.

Sounds like it is about time to check server2's system logs. The SSH service can tell you why it is rejecting or ignoring your keys. You will need the sshd_config option LogLevel DEBUG to get the most information out of it.

All sshd log messages go to the security log, usually /var/log/auth.log or /var/log/security, or at least journalctl -b if systemd is used.

The most common reason is that the "broken" server is refusing to read your authorized_keys file due to "too open" file permissions. For example, if ~/.ssh/ is world-writable or even owned by a diffrent user, that's considered a security problem and causes sshd to ignore your file. On Linux use namei -l ~/.ssh/authorized_keys to check this.

Review also the whole sshd_config file itself. It might be set up to look for authorized_keys in a completely different, nonstandard location.