ssh-copy-id does not work

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: 

2

14 Answers

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

chmod 600 ~/.ssh/authorized_keys

4

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

Then restart sshd after you modify the file:

/etc/init.d/sshd restart

5

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

1

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.

1

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.

1

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

/var/log/auth.log

1

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.

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.

2

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:

2

full chmod fix from

log in with password / root and switch to the user you want to be able to connect to then run

chmod go-w ~ && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

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

For me, it worked after I deleted the log file on the server and recreated it:

rm -rf /var/log/auth.log
nano /var/log/auth.log

Ctrl + x

y

Enter

and then

ssh-keygen
(using default options)
ssh-copy-id -i /path-to-public-key user@server

Easy to overlook this, but if you have an encrypted home directory, it will not work for the first session. Subsequent sessions will however work once the home dir is mounted and the authorized_file is accessible.

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

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

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