☰

我如何防止用户弄乱他们自己的 .ssh 文件夹？

tag-icon • tag-icon permissions ssh-keys
我如何防止用户弄乱他们自己的 .ssh 文件夹？

我正在管理一个 RedHat 服务器，用户可以通过 SSH 使用基于私钥/公钥的身份验证登录。

我想防止他们意外更改/删除/修改其内容〜/.ssh文件夹。他们中的一些人已经以递归方式 777-chmod 了他们自己的整个主文件夹，因为“这样更容易与同事共享文件”，结果却弄巧成拙。

知道如何实现吗？最好使用标准 Linux 权限系统。

答案1

简短的回答是你不能。

SSH 对权限非常挑剔，不会处理它不喜欢的文件。此外，用户ssh_config被解析前系统范围的配置。

话虽如此，可能可以将文件放在其他地方，并将目录挂载为每个用户的只读文件系统$HOME/.ssh。（这是可能的 - 但我不知道 ssh 和相关工具会如何处理这种情况）。

其中一些人已经以递归方式 777-chmod 了他们的整个主文件夹

那么你将面临更大的安全和培训问题。

答案2

很难保护用户免受其自身无知和无能的侵害。

但是取决于您需要允许您的用户自我管理的程度以及您为他们管理的程度：您可以配置 sshd 在其主目录之外的其他位置以及其他地方查找密钥~/.ssh/authorized_keys。

授权密钥命令

一个相对复杂的解决方案是/etc/ssh/sshd_config AuthorizedKeysCommand 指令不依赖于authorized_keys文件，而是指定用于查找用户公钥的程序，例如：

  • ALDAP 目录

  • A数据库

  • 一个（简单的）Web 服务

  • 或者当您的用户名与 Github 用户名相同时，您可以允许用户使用他们在那里上传的密钥对进行身份验证：

    AuthorizedKeysCommand /usr/bin/curl https://github.com/%u.keys

正如所提到的这个答案；您需要为 AuthorizedKeysCommand 创建合适的 SELinux 策略，因为它会被默认策略阻止。

我喜欢这种方法，因为它可以解决授权密钥管理方面的许多问题：它增加了集中管理，消除了当您想要禁用 ssh 中的密码验证时将授权密钥获取到服务器的先有鸡还是先有蛋的问题等等。
它利用了公钥不是特别敏感的事实（与关联的私钥不同），因此在我看来集中管理它们不会增加风险，甚至可能提高您的控制和报告能力。

授权密钥文件

稍微简单一点的方法就是将密钥存储在主目录之外的目录中。例如使用/etc/ssh/<username>（替换<username>为其实际用户名）。此目录应具有 755 个权限并归用户所有。将authorized_keys文件移入其中。authorized_keys 文件仍应具有 644 个权限并归用户所有。

在/etc/ssh/sshd_config调整AuthorizedKeysFile环境

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

并重新启动 ssh 守护进程

答案3

我能想到的最佳解决方案是制作.ssh并authorized_keys拥有 root 权限。

Root 拥有的 .ssh / authorized_keys

SSH 对权限要求很高，但并非不合理。首先，它要求用户本身具有对 的读取权限（这需要对所有父目录的读取权限）。其次，如果用户本身或 root 以外的任何用户对、或authorized_keys具有写入权限，则拒绝访问。这不允许包含其他用户的组访问和。/home.sshauthorized_keyso+wg+w

此设置对我有用，用户可以登录：

drwxr-xr-x 19 root root 4096 Sep 22 11:24 /
drwxr-xr-x  3 root root 4096 Sep 22 11:19 /home/
drwx------ 14 test test 4096 Sep 22 11:44 /home/test/
drwxr-x---  2 root test 4096 Sep 22 11:42 /home/test/.ssh/
-rw-r--r--  1 root test   98 Sep 22 11:36 /home/test/.ssh/authorized_keys

由于.ssh和authorized_keys为 root 所有，因此用户无法更改它们的权限或删除它们。他们也无法编辑自己的authorized_keys文件。

如果您想允许用户编辑他们的authorized_keys，您可以添加组写入权限。这要求该test组除了其自身之外没有其他成员test：

-rw-rw-r--  1 root test   99 Sep 22 12:04 /home/test/.ssh/authorized_keys

无论使用哪种方法，用户都无法再在 下创建自己的文件.ssh，因此您可能还想为他们提供一些额外的文件。想到的一些文件包括：known_hosts、config和id_rsa{.pub,}或其他关键类型。

替代方案：chattr

一些 Linux 文件系统支持文件属性，尤其是不可变标志. 已设置不可变标志的文件/目录无法被删除、修改或更改其权限。只有 root 可以设置/清除此标志。

即使具有默认的所有权/权限，此命令也可以解决问题：

# chattr +i ~test/.ssh/{authorized_keys,}

现在.ssh，authorized_keys即使是 root 用户也不能以任何方式修改。如果 root 需要更新这些文件，则需要chattr -i先更新它们。用于lsattr检查属性。

这种方法比较简单，但灵活性较差。它还需要文件系统支持；我相信至少 ext2/3/4、XFS 和 btrfs 都支持它。

Posix ACL？

还有Posix ACL（访问控制列表），允许更细粒度的控制。我对它们不太熟悉，我不确定它们在这里是否有用。

严格模式

笔记：强烈不鼓励，但提供完整性。

OpenSSH 服务器有一个配置指令称为StrictModes，它决定了 SSH 对权限的挑剔程度：

指定 sshd 是否应在接受登录之前检查文件模式以及用户文件和主目录的所有权。这通常是可取的，因为新手有时会意外地将其目录或文件置于全局可写状态。默认值为yes。

如果禁用该选项，您可以更自由地设置所有权和权限。但是，SSH 默认很严格，这是有原因的。用户使用 777-chmodding 修改其 SSH 文件存在安全风险。

答案4

每晚运行一个 cron 作业来修复权限。

删除文件有点困难。您也可以从 cron 的备份中恢复丢失的文件。但是，似乎您可能会遇到奇怪的极端情况……可能需要比脚本所能提供的更多的智能。我会从小处着手，谨慎地为恢复功能添加功能。

相关内容