0

I have two non-root users in one Linux server. If I make a SSH connection(key-based authentication) to one particular SSH server under first user, then it succeeds:

/* debug messages removed for brevity */
debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '.ssh/id_rsa': 
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8

Now under second user, where I specify the private key file with -i .ssh/SD, the key-based authentication does not succeed. All the SSH client debug messages are exactly the same until here:

/* debug messages removed for brevity */
debug1: Next authentication method: publickey
debug1: Trying private key: .ssh/SD
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '.ssh/SD': 
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Why doesn't SSH client in second case offer the public key? This is a mandatory step in key-based authentication, isn't it?

  • use -vvv for more detailed debug information. It might be visible there. – Jakuje Apr 8 '16 at 15:01
  • With -vvv it printed debug3: sign_and_send_pubkey and debug2: we sent a publickey packet, wait for reply after the debug1: read PEM private key done: type RSA line seen above. – Martin Apr 11 '16 at 20:50
  • this means the key was rejected. Turning the debug3 loglevel on server will tell you the reason for rejecting the key. But even though everyone says permissions are ok, I guess it will end up with them :) – Jakuje Apr 11 '16 at 21:49
2

There are two things I would check.

  1. It appears you are using different ssh keys so make sure the permissions are correct. .ssh folder should be 0700, rsa private key should be 0600, public key should be 0644. Use ls -l ~/.ssh to see permissions.

  2. Make sure the public key is transferred to the 2nd server. You can use ssh-copy-id ~/.ssh/SD.pub to copy the public key to the 2nd server. After it runs you can verify it's there by logging in to the server (as root or using a password) and then cat ~/.ssh/authorized_keys It should have the exact output of cat ~/.ssh/SD.pub on your local system. It may have other keys if you added them before.

If both of those things look good and you still can't get in then you should look at the server logs in /var/log/secure or you can also run a 2nd ssh server in the foreground to view what's happening. On the remote server run

sudo $(which sshd) -p 6666 -D -d

Then on your system try to log into the new ssh daemon with

ssh -p 6666 -i ~/.ssh/SD <SERVER>

You should see log information printed out in the terminal on the server which might have more information for why the login is failing.

As an explanation to the 2nd sshd daemon. You need sudo even though the permissions are usually 0755 for security. You also need to provide the full path to the sshd binary. That is why $(which sshd) is included in the command. -p 6666 sets the port (I just picked one at random). -D will run in the foreground and -d enables debugging.

  • Permissions are correct and public key in SSH server is also correct. – Martin Apr 11 '16 at 20:53
  • Do you have any logs/output from running sshd in debug and in the foreground? – Rothgar Apr 12 '16 at 1:25
0

Why doesn't SSH client in second case offer the public key?

The public key is offered by the client if it exists (i.e. file exists and is in the same folder as the private key with the same named + ".pub").

This is a mandatory step in key-based authentication, isn't it?

No, offering the public key is optional. Only proving that the client owns the private key is mandatory.
More explanation can be found here: https://security.stackexchange.com/a/152638

To illustrated both cases:

  1. Offering public key, then proving client has private key
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: RSA SHA256:3btAL+lsfo8D3Z8PVWLG04j8BqShS2ImfxqwMFPS8BM '.ssh/id_rsa'
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug2: input_userauth_pk_ok: fp SHA256:3btAL+lsfo8D3Z8PVWLG04j8BqShS2ImfxqwMFPS8BM
debug3: sign_and_send_pubkey: RSA SHA256:3btAL+lsfo8D3Z8PVWLG04j8BqShS2ImfxqwMFPS8BM
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
  1. Only proving client has private key
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: '.ssh/id_rsa'
debug3: sign_and_send_pubkey: RSA SHA256:3btAL+lsfo8D3Z8PVWLG04j8BqShS2ImfxqwMFPS8BM
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).

Note that if a public key named .ssh/SD.pub exists and IS NOT related to the private key .ssh/SD (because of a previous key generation for instance), connection will fail. According to the log provided by the OP, this is not the case here, but this is the problem I had when reaching this question. In that case, the log is as follows at client side (and not explicit about why auth failed):

debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:p5eJ+CJ1aRR9xeEcQUDCkbnQ3VUxa8cxjlWUhsYfla4 '.ssh/id_rsa'
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.