Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

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. – agporwfnz29 Sep 16 '10 at 17:35
    
In my case, AuthorizedKeysFile was commented out and I also had to use an absolute path to authorized_keys. – Andrew Nov 28 '14 at 18:46
    
I get 'Could not open a connection to your authentication agent.' when trying ssh-add – Manticore Sep 4 '15 at 7:14

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

chmod 600 ~/.ssh/authorized_keys
share|improve this answer
    
FYI, I created a small script at github.com/centic9/generate-and-send-ssh-key which runs the necessary steps in one go and additionally ensures all the file/directory permissions which always caused me headaches... – centic Oct 7 '15 at 11:31
    
If this does not work for someone, you should also look at @Gilles's answer. In particular, the home and ~/.ssh directories can't be writeable by anyone other than the user. – ostrokach Nov 5 '15 at 3:01

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
    
Thank you!!! I don't understand why, but your home directory, ~/.ssh, and ~/.ssh/authorized_keys can't be writeable by anyone but you. – ostrokach Nov 5 '15 at 3:00

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

In addition to all of the above, one can always check the sshd log file:

/var/log/auth.log
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

in my case /etc/ssh/sshd_config contained the following param:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys2

But ssh-copy-id created a file with name authorized_keys, so I had to modify the entry to the new name. more info about deprecated authorized_keys2

share|improve this answer

I found that with my system the problem was the user directory (/home/username) was equipped with the wrong permissions set. It was drwxr-x-w- and it needed to be drwxr-xr-x (with write permission only for the owner). The solution was to use chmod:

sudo chmod 0755 /home/username
share|improve this answer

I tried the other fixes but found that I had to change the home directory to not be writable by others. The home directory was 777. I changed it to 755 and it worked.

share|improve this answer
1  
welcome @dulcana, he tries to set a passwrodless ssh login, how changing permisions to 755 could help to solve the problem? – Francisco Tapia Oct 20 '15 at 16:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .