wec*_*ecx 10 permissions ssh-keys
我正在管理一个 RedHat 服务器,用户使用基于私钥/公钥的身份验证通过 SSH 登录。
我想防止他们意外更改/删除/chmoding 〜/.ssh文件夹的内容。他们中的一些人已经递归地 777-chmod 了他们自己的整个主文件夹,因为“这样更容易与同事共享文件”,结果搬起了石头砸自己的脚。
知道我该如何实现这一目标吗?最好有标准的Linux权限系统。
sym*_*ean 21
简短的回答是你不能。
SSH 对权限非常挑剔,不会使用它不喜欢外观的文件。此外,用户在系统范围的配置之前ssh_config
被解析。
话虽如此,可以将文件放在其他位置并将目录作为每个用户的只读文件系统安装$HOME/.ssh
。(这是可能的 - 但我不知道 ssh 和相关工具将如何处理这个问题)。
他们中的一些人已经递归地 777-chmoded 了他们自己的整个主文件夹
那么你就会遇到更大的安全和培训问题。
HBr*_*ijn 16
很难保护用户免受自身无知和无能的影响。
但取决于您需要允许用户管理自己的程度以及您为他们管理的程度:您可以将 sshd 配置为在其主目录之外的替代位置以及~/.ssh/authorized_keys
.
一个相对复杂的解决方案是 指令,而不是依赖authorized_keys文件指定一个用于查找用户公钥的程序,例如:/etc/ssh/sshd_config
AuthorizedKeysCommand
LDAP目录
一个数据库
一个(简单的)网络服务
或者当您的用户名与 Github 用户名相同时,您可以允许用户使用他们上传到此处的密钥对进行身份验证:
AuthorizedKeysCommand /usr/bin/curl https://github.com/%u.keys
Run Code Online (Sandbox Code Playgroud)
正如这个答案中提到的;您需要为 AuthorizedKeysCommand 创建合适的 SELinux 策略,因为它会被默认策略阻止。
我喜欢这种方法,因为它可以解决围绕授权密钥管理的许多问题:它增加了集中管理,消除了当您想在 ssh 中禁用密码身份验证时向服务器获取授权密钥的先有鸡还是先有蛋的问题。
它利用了公钥并不是特别敏感的事实(与相关的私钥不同),因此集中管理不会增加风险(恕我直言),甚至可能提高您的控制和报告能力。
稍微不太复杂的是将密钥存储在其主目录之外的目录中。例如使用/etc/ssh/<username>
(替换<username>
为实际用户名)。该目录应具有 755 权限并由用户拥有。将authorized_keys
文件移入其中。authorized_keys 文件仍应具有 644 权限并由用户拥有。
在/etc/ssh/sshd_config
调整AuthorizedKeysFile
设置中
AuthorizedKeysFile /etc/ssh/%u/authorized_keys
Run Code Online (Sandbox Code Playgroud)
并重新启动 ssh 守护进程
我能想到的最好的解决方案是制作.ssh
并authorized_keys
root 拥有。
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
Run Code Online (Sandbox Code Playgroud)
由于.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
Run Code Online (Sandbox Code Playgroud)
无论采用哪种方法,用户都无法再在 下创建自己的文件.ssh
,因此您可能还需要为他们提供一些额外的文件。我想到的一些是:known_hosts
、config
和/id_rsa{.pub,}
或其他关键类型。
一些 Linux 文件系统支持文件属性,特别是不可变标志。设置了不可变标志的文件/目录无法删除、修改或更改其权限。只有 root 可以设置/清除该标志。
即使使用默认的所有权/权限,此命令也能解决问题:
# chattr +i ~test/.ssh/{authorized_keys,}
Run Code Online (Sandbox Code Playgroud)
现在.ssh
不能authorized_keys
以任何方式修改,甚至不能通过 root 修改。如果 root 需要更新这些文件,您首先需要chattr -i
它们。用于lsattr
检查属性。
这种方法比较简单,但灵活性较差。它还需要文件系统支持;我相信至少 ext2/3/4、XFS 和 btrfs 都支持它。
还有Posix ACL(访问控制列表),它允许更细粒度的控制。我对他们不太熟悉,我不确定他们是否有帮助。
注意:强烈建议不要这样做,但为了完整性而提供。
OpenSSH 服务器有一个名为 的配置指令StrictModes
,它决定 SSH 对权限的挑剔程度:
指定 sshd 在接受登录之前是否应检查文件模式以及用户文件和主目录的所有权。这通常是可取的,因为新手有时会意外地将其目录或文件设置为全局可写。默认为
yes
.
如果禁用该选项,您可以更自由地设置所有权和权限。然而,SSH 默认情况下是严格的,这是有充分理由的。用户 777-chmodding 其 SSH 文件存在安全风险。
归档时间: |
|
查看次数: |
3930 次 |
最近记录: |