When configuring SSH password-less login with an ssh-key, the ssh-key generated and transferred to the server seems to not work when I try to login. Why is the ssh-key authentication failing?
You might find yourself in the situation that you have configured SSH passwordless login with SSH-key and transferred the ssh-key either by “ssh-copy-id” or manually, but on the first login attempt, ssh is still asking for a password.
The ssh server log might show you an error message like the following. This would just indicate that the authentication via ssh-key failed but give no reason:
sshd[13961]: debug1: userauth-request for user username service ssh-connection method publickey sshd[13961]: debug1: attempt 1 failures 0 sshd[13961]: debug1: test whether pkalg/pkblob are acceptable sshd[13960]: debug1: temporarily_use_uid: 234/1001 (e=0/0) sshd[13960]: debug1: trying public key file /path/to/users/homedirectory/.ssh/authorized_keys sshd[13960]: debug1: restore_uid: 0/0 sshd[13960]: debug1: temporarily_use_uid: 234/1001 (e=0/0) sshd[13960]: debug1: trying public key file /path/to/users/homedirectory/.ssh/authorized_keys2 sshd[13960]: debug1: restore_uid: 0/0 sshd[13960]: Failed publickey for username from 123.123.123.123 port 37951 ssh2 sshd[13961]: Connection closed by 123.123.123.123
The reason for the key based authenitication failing SELinux. To make certain that SELinux is the reason, check the auditd log. The related line in the /var/log/audit will look something like this:
type=AVC msg=audit(1392479922.440:24765601): avc: denied { read } for pid=13960 comm="sshd" name="authorized_keys" dev=dm-0 ino=786507 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file
The auditd log shows the cause of the problem. The authorized_keys file that is inside the user’s home directory has the wrong context. In this example, the context of the file is “unconfined_u:object_r:httpd_sys_content_t:s0”. The context sshd is running in does not have access to this context, resulting in SELinux denying access to the file. With no access to the file, the key authentication fails.
If this happens on a normal user, you can simply run the following command in the user’s home directory to restore the default context. This is done using the restorecon(8) program. Run the following command in the home directory of the user to restore the default SElinux context:
restorecon -v
When the user’s home directory is not in the default location, this might not help. Lets assume the user’s home directory is the document root of the webserver. Restoring the SELinux context will not solve the problem as the default context for the document root is “unconfined_u:object_r:httpd_sys_content_t:s0”. Instead of restoring the context with restorecon, the context of the files can be set using the chcon(1) program:
chcon -R unconfined_u:object_r:user_home_t:s0 /path/to/users/homedirectory/.ssh/
This command will set the SELinux security context explicitly to “unconfined_u:object_r:user_home_t:s0” which allows sshd to access it. As soon as the command is executed, the ssh login with the ssh-key should work.
When you are using ssh-copy-id, the problem might reappear when you have set the context manually as ssh-copy-id is aware of the security context and executes “restorecon” during the process of adding the ssh-key.$ semanage fcontext -a -t ssh_home_t /path/to/users/homedirectory/.ssh/ $ restorecon -v /path/to/users/homedirectory/.ssh/
When you check the ssh server log now, you should see that the key authentication was accepted when you try to login:
sshd[14993]: Accepted publickey for username from 123.123.123.123 port 38093 ssh2
Read more of my posts on my blog at http://blog.tinned-software.net/.
Thanks to Dave Quigley for pointing out the incorrect context orginally used in this post. And also a big thanks for pointing me to “semanage” for setting the context permanently instead of temporarily as originally explained with “chcon”.