Nate Silva

Aug 30 2011

In CentOS Linux 6.0, you can’t SSH using authorized_keys

The problem

Using CentOS Linux 6.0, you’ve created a ~/.ssh/authorized_keys file on the host and placed your RSA key in that file.

However, when you ssh to the host, you are still prompted for your password. If you enable debug logging on the server, you might see something like this:

Aug 30 21:31:37 mysql sshd[4331]: debug1: userauth-request for user nate service ssh-connection meth
od publickey
Aug 30 21:31:37 mysql sshd[4331]: debug1: attempt 1 failures 0
Aug 30 21:31:37 mysql sshd[4331]: debug1: test whether pkalg/pkblob are acceptable
Aug 30 21:31:37 mysql sshd[4330]: debug1: temporarily_use_uid: 500/500 (e=0/0)
Aug 30 21:31:37 mysql sshd[4330]: debug1: trying public key file /home/nate/.ssh/authorized_keys
Aug 30 21:31:37 mysql sshd[4330]: debug1: restore_uid: 0/0
Aug 30 21:31:37 mysql sshd[4330]: debug1: temporarily_use_uid: 500/500 (e=0/0)
Aug 30 21:31:37 mysql sshd[4330]: debug1: trying public key file /home/nate/.ssh/authorized_keys2
Aug 30 21:31:37 mysql sshd[4330]: debug1: restore_uid: 0/0
Aug 30 21:31:37 mysql sshd[4330]: Failed publickey for nate from 10.33.204.4 port 49454 ssh2

Cause and solutions

This problem may be caused by the SELinux security layer in CentOS. SELinux is not allowing the SSH daemon to read files in your ~/.ssh directory.

There’s more than one way to solve it.

Solution 1 (the “right” way)

Tell SELinux to “label” your ~/.ssh directory such that the SSH daemon is allowed to see it. The following command will re-label everything under /home, including user .ssh directories, with labels as defined in your security policy:

restorecon -R -v /home

In addition, SELinux provides a daemon that is supposed to monitor the filesystem and automatically set the correct labels, so this problem might not happen in the first place. The daemon is called restorecond. You can enable it in the usual manner (for example, chkconfig restorecond on followed by service restorecond start).

Solution 2 (the “wrong” way)

An alternate solution is to put SELinux in permissive mode, where it warns about rule violations but does not enforce them. Be aware that this effectively disables a key security layer! To do this temporarily (until reboot), type:

setenforce Permissive

To make this permanent, edit /etc/selinux/config and change the SELINUX line to permissive.

11 notes

  1. natesilva posted this
Page 1 of 1