When I try to log in with SSH, why am I getting the error, 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 to me!

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.

Answer 2

You should check the permissions of your key files. ssh is very strict about them and can refuse to use them for authentication.

• .ssh directory: 700 (drwx------)
• public key (.pub files): 644 (-rw-r--r--)
• private key (id_rsa): 600 (-rw-------)

So (adapt in your context):

chmod 700 ~/.ssh
chmod 644 ~/.ssh/id_rsa.pub
chmod 600 ~/.ssh/id_rsa

Answer 3

Well, as user1686 pointed out, some of what you write doesn't make sense, in that your method and logic doesn't make sense, and they identified that and had some good solutions, i'm going to write on two other things.. the logging on the client side, and also, some examples of useful output from server logs.

Regarding this error message

"Permission denied (publickey)"

It can be very misleading.

For example, you think the public key wasn't accepted, well that isn't necessarily the case! It can even be that the public key was accepted!!

One can check client side logs and server side logs.

I just noticed this re client side logs..

suppose i can't log in, I get that error!

$  ssh user@ip
user@ip: Permission denied (publickey).

To check the client side (maybe not technically called logs or logging, but the client side debugging messages shown with -v), I can run an SSH command that just runs a simple command like pwd, to basically do nothing and exit. And I also redirect the messages that ssh's verbose option gives, into a file so I can read it more easily.

$ ssh -v user@ip pwd 2>a.a
    

There is also a -vvv for more verbose, but -v is enough lines for me.. According to a test I just did, the -v produces 80 lines when logging in is fine.. about 66 when it didn't. The -vvv produces just over 200 lines when logging in fine.

Look at this from the end of a -v output, this is a case where logging in failed (because i'd renamed the private key from id_rsa to id_rsaa)

debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:Ltp8.....KQ/18J3I debug1: Server accepts key: /home/user/.ssh/id_rsa RSA SHA256:Ltp8....KQ/18J3I debug1: Trying private key: /home/user/.ssh/id_ecdsa debug1: Trying private key: /home/user/.ssh/id_ecdsa_sk debug1: Trying private key: /home/user/.ssh/id_ed25519 debug1: Trying private key: /home/user/.ssh/id_ed25519_sk debug1: Trying private key: /home/user/.ssh/id_xmss debug1: Trying private key: /home/user/.ssh/id_dsa debug1: No more authentication methods to try. user@ip: Permission denied (publickey).

Notice that it says the "Server accepts key".. Yet it still says "Permission denied (publickey).". So what I did in putting the public key to authorized_keys, worked.

And i've also had the ""Permission denied (publickey)." message when the username had been wrong.

Here's an example of a working log in , showing -v

debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:Ltp8.....KQ/18J3I
debug1: Server accepts key: /home/user/.ssh/id_rsa RSA SHA256:L....18J3I
Authenticated to ..... using "publickey".
debug1: Remote connections from LOCALH...
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.

When the username is incorrect, it never gets to accepting the public key, it only offers it

debug1: Offering public key: /home/user/.ssh/id_rsa RSA HrKQ/18J3I
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Trying private key: /home/user/.ssh/id_ed25519_sk
debug1: Trying private key: /home/user/.ssh/id_xmss
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: No more authentication methods to try.
userr@ip: Permission denied (publickey).

Looking on the server side log. (user's answer has details on where that can be), mine is /var/log/auth.log

And user mentions to have LogLevel DEBUG, in sshd_config. If you change sshd_config then you can reload it without restarting the server, with the method here https://askubuntu.com/questions/462968/take-changes-in-file-sshd-config-file-without-server-reboot sudo kill -SIGHUP $(pgrep -f "sshd -D")

The server log can show a message for if it's the user, and if the user is ok, then if it's the public key.

If I get the user wrong

/var/log# tail -n 10 auth.log | grep -i 'invalid'
Jun  6 02:24:08 comp sshd[82436]: Connection closed by invalid user roott ip port 52976 [preauth]

if I also get the public key wrong in addition to the user, then I still only get the invalid user message, no message about the public key.

But if I get the user correct and public key wrong.

/var/log# tail -n 10 auth.log | grep -i 'failed'
Jun  6 02:25:09 comp sshd[82456]: Failed publickey for user from ip port 52977 ssh2: RSA SHA256:Lt.../18J3I
:/var/log#

can do grep like this

comp:/var/log# tail -n 10 auth.log | grep -Pi 'invalid|failed'
Jun  6 02:30:58 comp sshd[82506]: Failed publickey for user from ip port 52985 ssh2: RSA SHA256:L.....Q/18J3I

--

root@comp:/var/log# vi ~/.ssh/authorized_keys
(I fixed the public key)

--

comp:/var/log# tail -n 10 auth.log | grep -Pi 'invalid|failed'

(no output there. no error, I logged on)

now for the one below, I did the user wrong.

comp:/var/log# tail -n 10 auth.log | grep -Pi 'invalid|failed'
Jun  6 02:31:59 comp sshd[82693]: Connection closed by invalid user roott ip port 52988 [preauth]
/var/log#

So you can do tail -n 10 auth.log | grep -Pi 'invalid|failed' and if you got the user wrong it'll say. And if you fix that but get the public key wrong, then it will tell you that you got the public key wrong.