一直使用CentOS作为服务器系统，平时装完系统以后都是建立publickey认证机制，然后关闭密码认证。原本是一件轻车熟路毫无压力的事情，不想前日新装一台机器按照正常配置以后居然使用publickey方式认证不成功，但是使用密码认证是可以的。
具体现象表现为使用SecureCRT登陆时，出现如下出错提示：
Public-key authentication with the server for user sw failed. Please verify username and public/private key pair.
查看服务器日志，找不到有用的相关记录。
之后直接在另一台机器上使用ssh连接，打开verbose模式（ssh -vvv），如下：
<span style="color: #000000;">debug1: SSH2_MSG_SERVICE_ACCEPT received</p><p>debug2: key: /home/sw/.ssh/identity (0xXXXXXXXXX)</p><p>debug2: key: /home/sw/.ssh/id_rsa ((nil))</p><p>debug2: key: /home/sw/.ssh/id_dsa ((nil))</p><p>debug3: Wrote </span>64 bytes for a total of 1109<span style="color: #000000;"></p><p>debug1: Authentications that can continue: publickey</span>,<span style="color: #000000;">password</p><p>debug3: start over</span>, passed a different list publickey,<span style="color: #000000;">password</p><p>debug3: preferred publickey</span>,keyboard-interactive,<span style="color: #000000;">password</p><p>debug3: authmethod_lookup publickey</p><p>debug3: remaining preferred: keyboard-interactive</span>,<span style="color: #000000;">password</p><p>debug3: authmethod_is_enabled publickey</p><p>debug1: <span style="color: #ff0000;">Next authentication method: publickey</span></p><p>debug1: Offering public key: /home/sw/.ssh/identity</p><p>debug3: send_pubkey_test</p><p>debug2: we sent a publickey packet</span>,<span style="color: #000000;"> wait for reply</p><p>debug3: Wrote </span>512 bytes for a total of 1621<span style="color: #000000;"></p><p>debug1: Authentications that can continue: publickey</span>,<span style="color: #000000;">password</p><p>debug1: Trying private key: /home/sw/.ssh/id_rsa</p><p>debug3: no such identity: /home/sw/.ssh/id_rsa</p><p>debug1: Trying private key: /home/sw/.ssh/id_dsa</p><p>debug3: no such identity: /home/sw/.ssh/id_dsa</p><p>debug2: we did not send a packet</span>,<span style="color: #000000;"> disable method</p><p>debug3: authmethod_lookup password</p><p>debug3: remaining preferred: </span>,<span style="color: #000000;">password</p><p>debug3: authmethod_is_enabled password</p><p>debug1: <span style="color: #ff0000;">Next authentication method: password</span></p><p>sw@xxx.xxx.xxx.xxx's password: </span>
可以看到，ssh先尝试了使用publickey进行认证，但是失败了，日志也没有显示相关原因，然后降级到使用密码认证。
接下来，又将服务器sshd的日志级别设置为DEBUG3（修改/etc/ssh/sshd_config中的LogLevel），期望得到有用的信息。修改以后重启sshd，然后再尝试连接，查看/var/log/secure，得到如下日志信息：
Mar 6 16:42:14 data sshd<span style="color: #800000; font-weight: bold;">[</span><span style="color: #800000;">1517</span><span style="color: #800000; font-weight: bold;">]</span><span style="color: #000000;">: debug1: trying public key file /home/sw/.ssh/authorized_keys</p><p>Mar </span>6 16:42:14 data sshd<span style="color: #800000; font-weight: bold;">[</span><span style="color: #800000;">1517</span><span style="color: #800000; font-weight: bold;">]</span>: debug1: restore_uid: 0/0<span style="color: #000000;"></p><p>Mar </span>6 16:42:14 data sshd<span style="color: #800000; font-weight: bold;">[</span><span style="color: #800000;">1517</span><span style="color: #800000; font-weight: bold;">]</span>: debug1: temporarily_use_uid: 500/500 (e=0/0<span style="color: #000000;">)</p><p>Mar </span>6 16:42:14 data sshd<span style="color: #800000; font-weight: bold;">[</span><span style="color: #800000;">1517</span><span style="color: #800000; font-weight: bold;">]</span><span style="color: #000000;">: debug1: trying public key file /home/sw/.ssh/authorized_keys</p><p>Mar </span>6 16:42:14 data sshd<span style="color: #800000; font-weight: bold;">[</span><span style="color: #800000;">1517</span><span style="color: #800000; font-weight: bold;">]</span>: debug1: restore_uid: 0/0<span style="color: #000000;"></p><p>Mar </span>6 16:42:14 data sshd<span style="color: #800000; font-weight: bold;">[</span><span style="color: #800000;">1517</span><span style="color: #800000; font-weight: bold;">]</span>: Failed publickey for sw from xxx.xxx.xxx.xxx port 27816<span style="color: #000000;"> ssh2</p><p>Mar </span>6 16:42:14 data sshd<span style="color: #800000; font-weight: bold;">[</span><span style="color: #800000;">1517</span><span style="color: #800000; font-weight: bold;">]</span>: debug3: mm_answer_keyallowed: key 0xXXXXXXXX is not allowed
日志信息只提到Failed publickey，并没有明确说明出错原因。
检查各种配置文件，各种文件访问权限，数次折腾无果。心中郁闷，因为这台机器软硬件环境都和其它机器一样，而且SSH的publickey认证也是配置过无数次的了。最后求助万能的Google，发现serverfault上有一个案例的现象和出错信息与我遇到几乎一样，提问者怀疑是SELinux导致的。下面的回复证实了确实是SELinux的问题，并且给出了解决方案：
Yes,<span style="color: #000000;"> SELinux is likely the cause. The .ssh dir is probably mislabeled. <span style="color: #ff0000;">Look at /var/log/audit/audit.log. It should be labeled ssh_home_t.</span> Check with ls -laZ. Run restorecon -r -vv /root/.ssh if need be.</p><p>Yep</span>, SELinux was the cause: type=AVC msg=audit(1318597097.413:5447): avc: <span style="color: #ff0000;">denied { read } for pid=19849 comm="sshd" name="authorized_keys" dev=dm-0</span> ino=262398 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file It works after running "restorecon -r -vv /root/.ssh". Thanks a lot.
我如获救命稻草，马上用ls -laZ检查了一下我的.ssh目录，果然不是ssh_home_t，心中窃喜，立刻使用restorecon对.ssh目录的context进行了恢复。
再次尝试进行连接，结果还是不行，现象和出错信息与之前一样。于是我查看了其它机器上的.ssh目录的context，都没有标为ssh_home_t，但是那些机器上的SSH服务都是正常的。我又仔细看了一下网上那个案例的描述和错误信息，我还是怀疑是SELinux导致的。于是我想把SELinux暂时关了试试，使用setenforce 0把SELinux关闭，重新尝试连接，publickey认证正常了。
确认了是SELinux引发的问题，接下来我查看了/var/log/audit/audit.log，发现有如下日志：
type=AVC msg=audit(1362560807.992:320): avc: <span style="color: #ff0000;">denied { search } for pid=1595 comm="sshd" name="/" dev=sda3</span> ino=2 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir
这条日志与网上案例唯一不同的地方在于案例中是sshd对分区dm-0中的authorized_keys文件没有read权限，而我的机器上是sshd对分区sda3的根没有search权限。
确认了问题所在，我仔细回忆了系统的安装过程与其它机器有什么不同之处。日志中提到的sda3是系统的/home分区，当时装系统的时候由于操作失误/home分区只有200M，装完系统以后发现了这个问题，于是我把sda3分区删除重建，然后挂载到/home。这么一折腾，/home目录上的context就不对了。
之后我对/home目录的context进行恢复：
<span style="color: #800000; font-weight: bold;">[</span><span style="color: #800000;">root@data ~</span><span style="color: #800000; font-weight: bold;">]</span><span style="color: #000000;"># restorecon -r -vv /home/</p><p>restorecon reset /home context system_u:object_r:file_t:s0->system_u:object_r:home_root_t:s0</p><p>restorecon reset /home/lost+found context system_u:object_r:file_t:s0->system_u:object_r:lost_found_t:s0</p><p>restorecon reset /home/sw/.pki context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:home_cert_t:s0</p><p>restorecon reset /home/sw/.pki/nssdb context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:home_cert_t:s0</span>
然后setenforce 1打开SELinux，重新连接SSH，认证成功，问题解决。
SELinux是Linux是的MAC（强制访问控制）系统实现，我还不太了解，接下来准备系统地学习一下SELinux相关知识。
来源URL：http://www.cnblogs.com/qcly/archive/2013/07/27/3219535.html