仅当sshd是守护程序时,公共密钥身份验证才会失败


33

我不知道这是怎么发生的。该发行版是Scientific Linux 6.1,所有内容均已设置为通过公钥执行身份验证。但是,当sshd作为守护程序运行(服务sshd启动)时,它不接受公共密钥。(要获得此日志,我更改了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
sshd初始化脚本会做一些有趣的事情吗?(应该是/etc/init.d/sshd吗?)您不是在命令行上执行的吗?代替“ service sshd start”,请尝试“ sh -x /etc/init.d/ssh start”。
PT

Answers:


42

是的,SELinux可能是原因。该.ssh目录可能是贴错标签。看看/var/log/audit/audit.log。应该贴上标签ssh_home_t。用检查ls -laZrestorecon -r -vv /root/.ssh如果需要,请运行。


1
是的,SELinux是原因:type = AVC msg = audit(1318597097.413:5447):avc:对于pid = 19849拒绝{读取} comm =“ sshd” name =“ authorized_keys” 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运行“ restorecon -r -vv /root/.ssh”后可以工作。非常感谢。
user666412 2011年

1
感谢感谢selinux命令行修复我一直试图寻找为什么它可以使用ssh密钥身份验证以ssh身份作为我的redhat enterprise 6.2服务器的根源,但是我不能以非root用户身份使用ssh身份。无需输入密码。“ ssh -v”完全没有表示任何异常。我检查并重新检查了/home/example/.ssh上的文件保护,直到我运行“ / usr / sbin / sshd -d”,并且由于某种原因可以正常工作,我才意识到其他事情正在发生,并且尝试了其他谷歌搜索并找到了这个。因此,症状是,我可以ssh作为RO
保罗中号

1
我必须在整个文件系统(即restorecon -r /YMMV)上执行此操作。
Irfy 2014年

1
我尝试了此操作-但仍然无法正常工作。在审核日志中,我有type=AVC msg=audit(1434642809.455:94717): avc: denied { search } for pid=27032 comm="sshd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir–不确定这是什么意思
Yehosef

1
答案是name="/"-我必须restorecon -r /按照@Irfy的建议运行。
Yehosef

3

我遇到过同样的问题。就我而言,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

打开它。

现在,我可以使用我的密钥而不是输入密码即可将密码切换到我的机器上。为我切换了use_home_nfs_dirs布尔值。


1

要添加到Mark Wagner的答案中,如果您使用的是自定义主目录路径(即不是/home),则需要确保已设置SELinux安全上下文。为此,例如,如果您有用户主目录/myhome,请运行:

semanage fcontext -a -e /home /myhome
restorecon -vR /myhome

如果您使用的是CentOS,则需要运行此程序以获取semanagesudo yum install policycoreutils-python
sm4rk0 '18

0

看起来您在测试连接时使用了不同的密钥,即0x7f266e1a8840与0x7f85527ef230。尝试使用“ ssh -v example.com”连接到以守护程序形式运行并在调试模式下运行的sshd,并在字符串“ Offering RSA public key”周围查找ssh使用的密钥。


是的,有id_rsa和id_dsa。DSA密钥不见了,我将重做测试。
user666412 2011年

debug3: mm_answer_keyallowed: key 0xFFFFFFFFFF每当sshd收到新连接时,中提到的值都会更改。要对此进行确认,请找到SSH可以运行的服务器,将sshd LOGLEVEL启动到debug3,重新启动sshd,运行tail -f /var/log/secure |grep mm_answer_keyallowed,然后登录几次,每次连接之间等待几秒钟(或几分钟)。您会看到该值每次都会更改。实际上,这看起来像是对我的反击。
Stefan Lasiewski 2013年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.