Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm trying to set up a passwordless SSH login on CentOS 5.4:

  1. I generated RSA public key on the client.
  2. ssh-copy-id from client to server.
  3. Verified ~/.ssh/authorized_keys contains the client key.

The client still prompted for password. What did I miss?

Thanks.

EDIT: checked ssh_config and permissions as advised. This is the debug info from the client:

debug2: key: /home/saguna/.ssh/identity ((nil))
debug2: key: /home/saguna/.ssh/id_rsa (0x2b31921be9a0)
debug2: key: /home/saguna/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 192.168.1.75.
debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/saguna/.ssh/identity
debug3: no such identity: /home/saguna/.ssh/identity
debug1: Offering public key: /home/saguna/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/saguna/.ssh/id_dsa
debug3: no such identity: /home/saguna/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
saguna@192.168.1.75's password: 
share|improve this question
    
I get this too :( –  Matt Joiner Mar 18 '11 at 9:29

5 Answers 5

9/10 times it's because ~/.ssh/authorized_keys isn't at the right mode.

chmod 600 ~/.ssh/authorized_keys
share|improve this answer

Check in /etc/ssh/sshd_config to allow authentication with a key. You should have something like this in it, and make sure the lines are not commented:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

PS: don't forget to restart sshd after you modify the file (/etc/init.d/sshd restart)

share|improve this answer
    
In addition to to Patkos Csaba's answer, check the permissions of your local and remote ~/.ssh folder. –  bytesum Sep 16 '10 at 17:35

The most common problem is invalid permissions on the server side. Check that none of your home directory, ~/.ssh and ~/.ssh/authorized_keys are writable by anyone but you (in particular they must not be group-writable).

If that's not the problem, run ssh -vvv server and look at the client's view of the conversation. In particular, check that the client is trying the key with the server.

share|improve this answer

I'm not an expert here but came across such issue too, here are my two cents in addition to all the other suggestions.

Sometimes ssh-copy-id copies the wrong key to the remote server (may happen if you have several keys and/or are using non-default names for key files) or your authentication agent is misconfigured.

Here's a quote from the man pages:

If the -i option is given then the identity file (defaults to ~/.ssh/id_rsa.pub) is used, regardless of whether there are any keys in your ssh-agent. Otherwise, if this: ssh-add -L provides any output, it uses that in preference to the identity file.

So basically you want to check that:

  • Your system authentication agent (usually ssh-agent) sees the keys that you intend to use (check ssh-add -L output)
    • If you don't see the desired key, add it using ssh-add
  • The ssh-copy-id copied the same key to the remote machine (just log in to the remote server using password and check the contents of ~/.ssh/authorized_keys)
    • If you don't see the desired key on the remote server, you can implicitly tell ssh-copy-id which key to copy: ssh-copy-id -i ~/.ssh/some_public_key

Hope that helps.

share|improve this answer
up vote 0 down vote accepted

The problem was I had RSAAuthentication disbled in /etc/ssh/ssh_config

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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