我不知道这是怎么发生的。 发行版是Scientific Linux 6.1,一切都设置为通过公钥执行validation。 然而,当sshd作为守护进程(service sshd start)运行时,它不接受公钥。 (要获得这段日志,我已经改变了sshd脚本来添加-ddd选项)
debug1: trying public key file /root/.ssh/authorized_keys debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: trying public key file /root/.ssh/authorized_keys2 debug1: restore_uid: 0/0 Failed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2 debug3: mm_answer_keyallowed: key 0x7f266e1a8840 is not allowed debug3: mm_request_send entering: type 22 debug3: mm_request_receive entering debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa debug3: Wrote 64 bytes for a total of 1853 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 2 failures 1
如果sshd以debugging模式/usr/sbin/sshd -ddd
,身份validation就像一个魅力:
debug1: trying public key file /root/.ssh/authorized_keys debug1: fd 4 clearing O_NONBLOCK debug1: matching key found: file /root/.ssh/authorized_keys, line 1 Found matching RSA key: d7:3a:08:39:f7:28:dc:ea:f3:71:7c:23:92:02:02:d8 debug1: restore_uid: 0/0 debug3: mm_answer_keyallowed: key 0x7f85527ef230 is allowed debug3: mm_request_send entering: type 22 debug3: mm_request_receive entering debug3: Wrote 320 bytes for a total of 2109 debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa Postponed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 2 failures 0
有任何想法吗?? 有没有人看过像这样的东西?
笔记:
文件权限已被双重检查:
# ll -d .ssh drwx------. 2 root root 4096 Oct 14 10:05 .ssh # ll .ssh total 16 -rw-------. 1 root root 786 Oct 14 09:35 authorized_keys -rw-------. 1 root root 1675 Oct 13 08:24 id_rsa -rw-r--r--. 1 root root 393 Oct 13 08:24 id_rsa.pub -rw-r--r--. 1 root root 448 Oct 13 12:51 known_hosts
我被问及sshd是否可以在“守护进程模式”下访问root的文件。 我对这个问题最接近的答案是:
# netstat -ntap | grep 22 tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 19847/sshd # ps -ef | grep 19847 root 19847 1 0 09:58 ? 00:00:00 /usr/sbin/sshd
如果sshd以root用户身份运行,我不知道如何访问自己的文件。 SELinux可能是原因吗?
是的,SELinux可能是原因。 .ssh
目录可能被错误标记。 看看/var/log/audit/audit.log
。 它应该被标记为ssh_home_t
。 用ls -laZ
检查。 如果需要,运行restorecon -r -vv /root/.ssh
。
它看起来像你在testing连接时使用不同的键,0x7f266e1a8840与0x7f85527ef230。 尝试使用“ssh -v example.com”连接到以守护进程运行的sshd,并在debugging模式下查找由“提供RSA公钥”string的ssh使用的密钥。