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

Question

我有一台 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 没有运气。

Answer 1

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

可能是因为在 .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 user@example.com
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）。

Answer 2

您很快就开始使用 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 文件以获取更多信息。

Answer 3

我在 CentOS 7 上遇到了这个问题。我是一个普通的基于 Debian 的 Linux 用户，所以我就像一条离水的鱼。我注意到在某些服务器中它可以工作，而只有一台服务器则不能。他们audit.log没有说什么有用的东西，也secure.log没有提供任何东西。我发现唯一真正的区别是有效和无效的文件和目录之间的一些安全上下文差异。获得安全保障

sudo ls -laZ <user-home>/.ssh

目录的（我假设 sshd_config 有很多默认值）。

您应该看到一些ssh_home_t和user_home_t属性。如果不这样做，请使用该chcon命令添加缺少的属性。

例如：

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home/.ssh"
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

就我而言，我怀疑用户是以非标准方式创建的。他的家是一个目录/var/lib。

更多信息：https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

Answer 4

在restorecon -R -v ~/.ssh不工作的情况下，SELinux 应归咎于每个sealert或audit2allow报告，并且当.ssh文件夹的 SELinux 上下文被更改时，以下可以解决基于密钥的身份验证的登录问题：

$ 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.

Answer 5

就我而言，正在调查

根#>journalctl -f

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

root#>setsebool -P use_nfs_home_dirs 1

这解决了我的问题。