一次由SELinux引起的SSH公钥认证失败问题

一直使用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),如下:

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug2: key: /home/sw/.ssh/identity (0xXXXXXXXXX)

debug2: key: /home/sw/.ssh/id_rsa ((nil))

debug2: key: /home/sw/.ssh/id_dsa ((nil))

debug3: Wrote 64 bytes for a total of 1109

debug1: Authentications that can continue: publickey,password

debug3: start over, passed a different list publickey,password

debug3: preferred publickey,keyboard-interactive,password

debug3: authmethod_lookup publickey

debug3: remaining preferred: keyboard-interactive,password

debug3: authmethod_is_enabled publickey

debug1: Next authentication method: publickey

debug1: Offering public key: /home/sw/.ssh/identity

debug3: send_pubkey_test

debug2: we sent a publickey packet, wait for reply

debug3: Wrote 512 bytes for a total of 1621

debug1: Authentications that can continue: publickey,password

debug1: Trying private key: /home/sw/.ssh/id_rsa

debug3: no such identity: /home/sw/.ssh/id_rsa

debug1: Trying private key: /home/sw/.ssh/id_dsa

debug3: no such identity: /home/sw/.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

sw@xxx.xxx.xxx.xxx's password:

 

可以看到,ssh先尝试了使用publickey进行认证,但是失败了,日志也没有显示相关原因,然后降级到使用密码认证。 

接下来,又将服务器sshd的日志级别设置为DEBUG3(修改/etc/ssh/sshd_config中的LogLevel),期望得到有用的信息。修改以后重启sshd,然后再尝试连接,查看/var/log/secure,得到如下日志信息:

Mar 6 16:42:14 data sshd[1517]: debug1: trying public key file /home/sw/.ssh/authorized_keys

Mar 6 16:42:14 data sshd[1517]: debug1: restore_uid: 0/0

Mar 6 16:42:14 data sshd[1517]: debug1: temporarily_use_uid: 500/500 (e=0/0)

Mar 6 16:42:14 data sshd[1517]: debug1: trying public key file /home/sw/.ssh/authorized_keys

Mar 6 16:42:14 data sshd[1517]: debug1: restore_uid: 0/0

Mar 6 16:42:14 data sshd[1517]: Failed publickey for sw from xxx.xxx.xxx.xxx port 27816 ssh2

Mar 6 16:42:14 data sshd[1517]: debug3: mm_answer_keyallowed: key 0xXXXXXXXX is not allowed

 

日志信息只提到Failed publickey,并没有明确说明出错原因。 

检查各种配置文件,各种文件访问权限,数次折腾无果。心中郁闷,因为这台机器软硬件环境都和其它机器一样,而且SSH的publickey认证也是配置过无数次的了。最后求助万能的Google,发现serverfault上有一个案例的现象和出错信息与我遇到几乎一样,提问者怀疑是SELinux导致的。

案例 见

下面的回复证实了确实是SELinux的问题,并且给出了解决方案:

Yes, SELinux is likely the cause. The .ssh dir is probably mislabeled. Look at /var/log/audit/audit.log. It should be labeled ssh_home_t. Check with ls -laZ. Run restorecon -r -vv /root/.ssh if need be.

Yep, SELinux was the cause: type=AVC msg=audit(1318597097.413:5447): avc:denied { read } for pid=19849 comm="sshd" dev=dm-0 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,发现有如下日志:

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:http://www.heiqu.com/a26f0830193181095c0395ab3f6d0f1c.html