ssh-copy-id does not work

Question

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: 

Answer 1

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

Answer 2

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

chmod 600 ~/.ssh/authorized_keys

Answer 3

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)

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

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

/var/log/auth.log

Answer 8

As a complement to Omer Dagan answer for newer CentOS 7, use:

journalctl -f -u sshd

for looking at the sshd logs at the server.

Answer 9

I've had that problem on CentOS 7. For me, it turned out to be a problem with SELinux that prevented access to the user's authorized_keys file. I filtered the audit log for the authorized_keys filename and tried to log in from the client machine:

[root@centos ssh]# tail -f /var/log/audit/audit.log |grep authorized_keys
type=AVC msg=audit(1580206788.877:2649): avc:  denied  { read } for  pid=84056 comm="sshd" name="authorized_keys" dev="dm-0" ino=74366557 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file permissive=0

First, make sure that semanage is available. On CentOS 7, the required package is policycoreutils-python. You can install it by executing

yum -y install policycoreutils-python

Afterwards, I updated the context by executing:

semanage fcontext -a -t ssh_home_t /home/username/.ssh/
restorecon -FRv /home/username/.ssh/

...and it finally worked. I found the solution for that here:

https://serverfault.com/questions/849631/why-is-selinux-blocking-remote-ssh-access-without-a-password

https://blog.tinned-software.net/ssh-key-authentication-is-not-working-selinux/

Answer 10

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.

Answer 11

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