☰

为什么 selinux 会阻止没有密码的远程 ssh 访问？

tag-icon • tag-icon ssh selinux
为什么 selinux 会阻止没有密码的远程 ssh 访问？

我有一台 CentOS 7 服务器。我在尝试不使用密码登录的主机上设置了 /root/.ssh/authorized_keys。（是的，允许远程 root 访问是个坏主意，但这是一台内部服务器。）ssh 失败，selinux 审计日志中出现了这个错误。

type=USER_LOGIN msg=audit(1494544798.597:481313): pid=18660 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/sshd" hostname=? addr=xx.xx.xx.xx terminal=ssh res=failed'

以下是 .ssh 内容的权限和上下文：

# ls -aZ /root/.ssh
drwx------. root root system_u:object_r:ssh_home_t:s0  .
dr-xr-x---. root root system_u:object_r:admin_home_t:s0 ..
-rw-------. root root system_u:object_r:ssh_home_t:s0  authorized_keys
-rw-r--r--. root root unconfined_u:object_r:ssh_home_t:s0 known_hosts

我将权限和上下文与另一个允许无密码 ssh 登录的系统的权限和上下文进行了比较，它们是相同的。

在审计消息中，没有迹象表明 selinux 关注哪个文件，只有“res=fail”。

在正常运行的系统中，日志条目包含以下内容：

subj=system_u:system_r:sshd_t:s0-s0:c0.c1023

所以，我很困惑。/root/.ssh 中没有包含上下文 system_u:system_r:sshd_t 的文件。所以，我不明白为什么要记录该上下文。

有没有办法知道所有 .ssh 相关文件的上下文应该是什么？是的，我玩过 restorecon，但没有成功。

答案1

您很快就跳转到 SELinux....您确定已正确设置 /etc/ssh/sshd_config 以允许通过 ssh 进行 root 访问吗？如果您对配置文件进行了任何更改，您是否重新启动了 sshd 服务。

您是否尝试过将 SELinux 设置为宽松并进行测试。

您知道，如果 SELinux 拒绝访问，我预计会在 /var/log/audit/audit.log 中看到某种类型的 AVC（访问向量缓存）错误。请记住，audit.log 不仅仅用于 SELinux 问题。因此，您收到的只是失败的登录报告，而不是 SELinux 错误。

您是否绝对确定您拥有的公共/私有 openssh 密钥对在 ssh 上下文中确实有效。您可以尝试使用带有 -v 选项的 ssh 命令进行日志记录，以进行调试并查看。

我还会检查 /var/log/messages 和 /var/log/secure 文件以获取更多信息。

答案2

有一个简短的文章关于这个问题。它说

可能是因为 .ssh 文件夹和授权密钥文件上的 SELinux 上下文没有正确设置 [...] 解决此问题的方法是运行

# restorecon -R -v /root/.ssh

本文还展示了如何从一开始就正确设置权限：

# chmod 755 /root/.ssh/
# chmod 600 /root/.ssh/authorized_keys
# restorecon -R -v /root/.ssh

虽然我不同意文章中关于第一个命令的观点，但在我的 VPS 上

# chmod 700 /root/.ssh/

从我的个人经验来看，我学到了有关 ssh-key 认证的几个重要的事情。

  1. 如果您使用的是新版本的 OpenSSH（我的问题始于 OpenSSH 7.0），则 DSA 密钥将不起作用，因为“运行时默认禁用对 ssh-dss 主机和用户密钥的支持”。解决方案是使用 RSA 密钥或在远程计算机和客户端计算机上PubkeyAcceptedKeyTypes=+ssh-dss添加。/etc/ssh/sshd_config~/.ssh/config
  2. 可以通过 -vvvvv向 ssh调用添加选项来调试客户端的问题ssh -vvvvvv [email protected]
  3. 可以通过编辑来调试服务器端的问题/etc/ssh/sshd_config

SyslogFacility AUTH

LogLevel DEBUG

（有关选项的帮助可以通过 获得# man sshd_config）

然后在 ssh 连接期间查看/var/log/debug。如果找不到调试日志，请查看/var/log/messages和/var/log/secure（作为最后的手段，查看 中的设置/etc/syslog.conf）。

答案3

在无法正常工作的情况下restorecon -R -v ~/.ssh，SELinux 应承担责任，根据sealert或audit2allow报告，当 SELinux 上下文.ssh文件夹被更改，以下可以修复基于密钥的身份验证的登录问题：

$ sudo semanage fcontext --add -t ssh_home_t "/path/to/my/.ssh(/.*)?"; \
$ sudo restorecon -FRv /path/to/my/.ssh

当观察到如下所示的 AVC 时，此修复是有效的：

$ sudo audit2allow -w -a
type=AVC msg=audit(1548909218.552:1037): avc:  denied  { read } for  pid=13996 comm="sshd" name="authorized_keys" dev="dm-0" ino=4663556 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file
        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.

答案4

就我的情况来说

根目录＃> journalctl -f

然后告诉 SELinux 允许使用 nfs 主目录：

root＃> setsebool -P use_nfs_home_dirs 1

这解决了我的问题。

相关内容