8

I'm helping a friend who has some trouble connecting using public-key authentication, to a server maintainied by me. Public-key auth works fine for a couple of other users. Of course, my friend's public key is in authorized_keys-file on the server.

debug1: Host 'xxxxx' is known and matches the RSA host key.
debug1: Found key in /home/xxx/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/xxx/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: email@address.com
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/xxx/.ssh/id_dsa
debug1: Trying private key: /home/xxx/.ssh/id_ecdsa
debug1: Next authentication method: password

The following line does not make sense to me

Server accepts key: pkalg ssh-rsa blen 279

Since it seems that the server thinks that the public-key is perfectly correct, so why does it continue to password-authentication instead of authenticating the user?

2
  • 1
    Consider increasing the debug level. I think debug1 is the least verbose. ssh -vvv
    – Daniel Beck
    Feb 11, 2012 at 11:40
  • Good point. However, the issue was solved when my frient removed all previous ssh-keys and generated a new.
    – nip3o
    Feb 17, 2012 at 12:11

3 Answers 3

6

I believe that you are showing client-side logs/debugging output. I would look at the server-side logs as that usually gives more detail about why the server rejected a public-key authentication attempt.

E.g. insecure permissions on users home or .ssh directories.

1
  • 1
    On my centos system, the log file was /var/log/secure
    – Jared Beck
    Apr 1, 2012 at 17:21
4

In my case, the issue was that the user it was attempting to connect as was root, and I had disabled root ssh login (which probably everyone should do). So, make sure your friend is attempting to connect via the correct, non-root user account.

2

I have recently experienced this with Gerrit's SSH interface. The problem was that my local SSH agent offered up a bunch of different keys to the Gerrit server, and after some limit the server just refused to accept further keys (but still replied with the Server accepts key). I don't know if this behavior is specific to Gerrit or a generic OpenSSH thing.

The fix was to force select the right key in ~/.ssh/config:

Host gerrit.example.org
  IdentityFile ~/path/to/my_key
  IdentitiesOnly yes

After making sure that ~/path/to/my_key.pub exists (it can be created with ssh-keygen -f ~/path/to/my_key -y > ~/path/to/my_key.pub), the ssh agent could provide the key without having to re-enter the passphrase, but did not provide any other keys.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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