wecx Asked: 2023-09-22 01:11:35 +0800 CST2023-09-22 01:11:35 +0800 CST 2023-09-22 01:11:35 +0800 CST 如何防止用户弄乱自己的 .ssh 文件夹？ 772 我正在管理一个 RedHat 服务器，用户使用基于私钥/公钥的身份验证通过 SSH 登录。 我想防止他们意外更改/删除/chmoding 〜/.ssh文件夹的内容。他们中的一些人已经递归地 777-chmod 了他们自己的整个主文件夹，因为“这样更容易与同事共享文件”，这就是搬起石头砸自己的脚。 知道我该如何实现这一目标吗？最好有标准的Linux权限系统。 permissions 4 个回答 Voted Best Answer symcbean 2023-09-22T01:21:54+08:002023-09-22T01:21:54+08:00 简短的回答是你不能。 SSH 对权限非常挑剔，不会使用它不喜欢外观的文件。此外，用户在系统范围的配置之前ssh_config被解析。 话虽如此，可以$HOME/.ssh将文件放在其他位置并将目录作为每个用户的只读文件系统安装。（这是可能的 - 但我不知道 ssh 和相关工具将如何处理这个问题）。 他们中的一些人已经递归地 777-chmoded 了他们自己的整个主文件夹 那么你就会面临更大的安全和培训问题。 HBruijn 2023-09-22T02:01:07+08:002023-09-22T02:01:07+08:00 很难保护用户免受自身无知和无能的影响。 但取决于您需要允许用户管理自己的程度以及您为他们管理的程度：您可以将 sshd 配置为在其主目录之外的替代位置以及~/.ssh/authorized_keys. 授权密钥命令 一个相对复杂的解决方案是 指令，而不是依赖authorized_keys文件指定一个用于查找用户公钥的程序，例如：/etc/ssh/sshd_config AuthorizedKeysCommand LDAP目录 一个数据库 一个（简单的）网络服务 或者当您的用户名与 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 守护进程 marcelm 2023-09-22T18:41:31+08:002023-09-22T18:41:31+08:00 我能想到的最好的解决方案是制作.ssh并authorized_keysroot 拥有。 根拥有的 .ssh/authorized_keys SSH 对权限很挑剔，但并非没有道理。首先，它要求用户本身具有读取权限authorized_keys（这需要对所有父目录具有读取权限）。其次，如果除用户本身或 root 之外的任何用户对/home、.ssh或具有写访问权限，则它会拒绝访问authorized_keys。这不允许o+w, 和g+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 文件存在安全风险。 Gringo Suave 2023-09-24T04:27:36+08:002023-09-24T04:27:36+08:00 每晚运行一个 cron 作业来修复权限。 删除文件有点困难。您也可以从 cron 备份中恢复丢失的文件。但是，似乎您可能会遇到奇怪的边缘情况……可能需要比脚本所能提供的更多的智能。我会从小处开始，谨慎地向恢复功能添加功能。
简短的回答是你不能。
SSH 对权限非常挑剔，不会使用它不喜欢外观的文件。此外，用户在系统范围的配置之前
ssh_config被解析。话虽如此，可以
$HOME/.ssh将文件放在其他位置并将目录作为每个用户的只读文件系统安装。（这是可能的 - 但我不知道 ssh 和相关工具将如何处理这个问题）。那么你就会面临更大的安全和培训问题。
很难保护用户免受自身无知和无能的影响。
但取决于您需要允许用户管理自己的程度以及您为他们管理的程度：您可以将 sshd 配置为在其主目录之外的替代位置以及
~/.ssh/authorized_keys.授权密钥命令
一个相对复杂的解决方案是 指令，而不是依赖authorized_keys文件指定一个用于查找用户公钥的程序，例如：
/etc/ssh/sshd_configAuthorizedKeysCommandLDAP目录
一个数据库
一个（简单的）网络服务
或者当您的用户名与 Github 用户名相同时，您可以允许用户使用他们上传到此处的密钥对进行身份验证：
正如这个答案中提到的；您需要为 AuthorizedKeysCommand 创建合适的 SELinux 策略，因为它会被默认策略阻止。
我喜欢这种方法，因为它可以解决围绕授权密钥管理的许多问题：它增加了集中管理，消除了当您想在 ssh 中禁用密码身份验证时向服务器获取授权密钥的先有鸡还是先有蛋的问题。
它利用了公钥并不是特别敏感的事实（与相关的私钥不同），因此集中管理不会增加风险（恕我直言），甚至可能提高您的控制和报告能力。
授权密钥文件
稍微不太复杂的是将密钥存储在其主目录之外的目录中。例如使用
/etc/ssh/<username>（替换<username>为实际用户名）。该目录应具有 755 权限并由用户拥有。将authorized_keys文件移入其中。authorized_keys 文件仍应具有 644 权限并由用户拥有。在
/etc/ssh/sshd_config调整AuthorizedKeysFile设置中并重新启动 ssh 守护进程
我能想到的最好的解决方案是制作
.ssh并authorized_keysroot 拥有。根拥有的 .ssh/authorized_keys
SSH 对权限很挑剔，但并非没有道理。首先，它要求用户本身具有读取权限
authorized_keys（这需要对所有父目录具有读取权限）。其次，如果除用户本身或 root 之外的任何用户对/home、.ssh或具有写访问权限，则它会拒绝访问authorized_keys。这不允许o+w, 和g+w对于其中有其他用户的组。此设置适用于我，用户可以登录：
由于
.ssh和authorized_keys是 root 拥有的，因此用户无法更改它们的权限或删除它们。他们也无法编辑自己的authorized_keys文件。如果您想允许用户编辑其
authorized_keys，您可以添加组写入权限。这要求该test组除自身之外没有其他成员test：无论采用哪种方法，用户都无法再在 下创建自己的文件
.ssh，因此您可能还需要为他们提供一些额外的文件。我想到的一些是：known_hosts、config和/id_rsa{.pub,}或其他关键类型。替代方案：chattr
一些 Linux 文件系统支持文件属性，特别是不可变标志。设置了不可变标志的文件/目录无法删除、修改或更改其权限。只有 root 可以设置/清除该标志。
即使使用默认的所有权/权限，此命令也能解决问题：
现在
.ssh不能authorized_keys以任何方式修改，甚至不能通过 root 修改。如果 root 需要更新这些文件，您首先需要chattr -i它们。用于lsattr检查属性。这种方法比较简单，但灵活性较差。它还需要文件系统支持；我相信至少 ext2/3/4、XFS 和 btrfs 都支持它。
Posix ACL？
还有Posix ACL（访问控制列表），它允许更细粒度的控制。我对他们不太熟悉，我不确定他们是否有帮助。
严格模式
注意：强烈建议不要这样做，但为了完整性而提供。
OpenSSH 服务器有一个名为 的配置指令
StrictModes，它决定 SSH 对权限的挑剔程度：如果禁用该选项，您可以更自由地设置所有权和权限。然而，SSH 默认情况下是严格的，这是有充分理由的。用户 777-chmodding 其 SSH 文件存在安全风险。
每晚运行一个 cron 作业来修复权限。
删除文件有点困难。您也可以从 cron 备份中恢复丢失的文件。但是，似乎您可能会遇到奇怪的边缘情况……可能需要比脚本所能提供的更多的智能。我会从小处开始，谨慎地向恢复功能添加功能。