如何防止用户弄乱自己的 .ssh 文件夹?

wec*_*ecx 10 permissions ssh-keys

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

我想防止他们意外更改/删除/chmoding 〜/.ssh文件夹的内容。他们中的一些人已经递归地 777-chmod 了他们自己的整个主文件夹,因为“这样更容易与同事共享文件”,结果搬起了石头砸自己的脚。

知道我该如何实现这一目标吗?最好有标准的Linux权限系统。

sym*_*ean 21

简短的回答是你不能。

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

话虽如此,可以将文件放在其他位置并将目录作为每个用户的只读文件系统安装$HOME/.ssh。(这是可能的 - 但我不知道 ssh 和相关工具将如何处理这个问题)。

他们中的一些人已经递归地 777-chmoded 了他们自己的整个主文件夹

那么你就会遇到更大的安全和培训问题。

  • @PeterCordes:上次我尝试时,如果用户不是root,则root拥有的authorized_keys会被拒绝。 (3认同)
  • 不管怎样,当你说 ssh 或 sshd 很挑剔时,它们会拒绝 root 拥有的文件吗?另外,也许只需“chattr +i”即可使某些文件“不可变”,而不是只读(绑定)挂载。或者“+a”仅允许追加,这可能适用于“known_hosts”(但它不会阻止重命名或更改权限)。(哦,还有另一个答案提到了“chattr”。) (2认同)
  • @joshudson:哦,如果你想让用户完全无法修改,只需“chattr +i”即可。认为“chmod 777 -R ~”是个好主意的无知用户将不知道如何撤消该操作。 (2认同)
  • @joshudson 根拥有的“authorized_keys”对我来说效果很好,请查看我的答案,我在其中解释了该选项以及更多内容! (2认同)

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 守护进程

  • 喜欢 github 的方法 (3认同)
  • AFAIK 也适用于本地 Gitlab,并且您几乎肯定会在那里拥有相同的用户名 (2认同)
  • 对于“/etc/ssh/...”,密钥文件可以由 root:root 拥有,而不是由用户拥有,以进一步减少用户修改其密钥的能力。 (2认同)

mar*_*elm 8

我能想到的最好的解决方案是制作.sshauthorized_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
Run Code Online (Sandbox Code Playgroud)

由于.sshauthorized_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_hostsconfig和/id_rsa{.pub,}或其他关键类型。

替代方案:chattr

一些 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?

还有Posix ACL(访问控制列表),它允许更细粒度的控制。我对他们不太熟悉,我不确定他们是否有帮助。

严格模式

注意:强烈建议不要这样做,但为了完整性而提供。

OpenSSH 服务器有一个名为 的配置指令StrictModes,它决定 SSH 对权限的挑剔程度:

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

如果禁用该选项,您可以更自由地设置所有权和权限。然而,SSH 默认情况下是严格的,这是有充分理由的。用户 777-chmodding 其 SSH 文件存在安全风险。

  • “如果你想允许用户编辑他们的‘authorized_keys’,...” – OpenSSH 中的 `sshd` 检查 `authorized_keys` *和* `authorized_keys2`,所以我认为你可以“劫持”一个并允许用户编辑其他。我会“劫持”“authorized_keys2”,因为我希望像“ssh-copy-id”这样的工具默认附加到“authorized_keys”,并且我不想破坏它们。 (3认同)
  • `authorized_keys2` 已经被弃用了二十年。它仍然受到支持表明它可能永远不会被删除(正如几年前宣布的那样)。但是,由于 sshd 检查在“AuthorizedKeysFile”的“sshd_config”中指定的任何文件(具有合法的所有权和权限),如果您想要备用文件名或位置,请在配置中显式设置它,而不是依赖于添加的支持连接的功能仅适用于 ssh 1.3 和 1.5,还适用于全新协议版本 2.0 (2认同)