我不知道这是怎么发生的。发行版是 Scientific Linux 6.1，一切都设置为通过公钥执行身份验证。然而，当 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 在调试模式下运行/usr/sbin/sshd -ddd，身份验证将非常有效：
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 可能是原因吗？
答案1
是的，SELinux 可能是原因。.ssh目录可能标记错误。查看/var/log/audit/audit.log。它应该被标记为ssh_home_t。使用 进行检查ls -laZ。restorecon -r -vv /root/.ssh如果需要，请运行。
答案2
我也遇到了同样的问题。在我的例子中，restorecon 和 chcon 不起作用。
我不想禁用 selinux。经过大量研究，我最终发现这是因为我的主目录是从其他地方（NFS）挂载的。我发现此错误报告这给了我线索。
我跑了：
> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off
确认 use_nfs_home_dirs 已关闭，然后：
sudo setsebool -P use_nfs_home_dirs 1
打开它。
现在我可以使用我的密钥通过 ssh 连接到我的机器，而无需输入密码。切换 use_home_nfs_dirs 布尔值就是我所需要的。
答案3
补充一下 Mark Wagner 的回答，如果你使用的是自定义主目录路径（即不是/home），则需要确保已设置 SELinux 安全上下文。为此，如果你在（例如）中拥有用户主目录，/myhome请运行：
semanage fcontext -a -e /home /myhome
restorecon -vR /myhome
答案4
看起来您在测试连接时使用了不同的密钥，0x7f266e1a8840 和 0x7f85527ef230。尝试使用“ssh -v example.com”连接到以守护进程和调试模式运行的 sshd，并在字符串“提供 RSA 公钥”周围查找 ssh 使用的密钥。