![为什么人们仍然使用基于 SSH chroot 的 SFTP 监狱,而不是 Systemd 的命名空间功能?](https://linux22.com/image/116193/%E4%B8%BA%E4%BB%80%E4%B9%88%E4%BA%BA%E4%BB%AC%E4%BB%8D%E7%84%B6%E4%BD%BF%E7%94%A8%E5%9F%BA%E4%BA%8E%20SSH%20chroot%20%E7%9A%84%20SFTP%20%E7%9B%91%E7%8B%B1%EF%BC%8C%E8%80%8C%E4%B8%8D%E6%98%AF%20Systemd%20%E7%9A%84%E5%91%BD%E5%90%8D%E7%A9%BA%E9%97%B4%E5%8A%9F%E8%83%BD%EF%BC%9F%20.png)
这个想法可能是愚蠢的或不可行的,我不知道,但我找不到任何关于这个的参考......
您可能知道(SE 肯定知道!),如果文件访问权限足够,则用于加强 SSH 安全性的常见步骤之一是将用户锁定在 chroot 中。 OpenSSH 多年来一直提供这样一个基于 chroot 的监狱。
然而,这种方法缺乏灵活性(全有或全无,仅限 SFTP 等),并且归结为滥用系统调用(这具有安全隐患,因此“监狱必须由 root 拥有”和其他建议很少被理解) 。
现在 OpenSSH 作为sshd.socket
和提供[email protected]
,我很想使用 Linux 命名空间(当时我免费获得)来限制我的用户。
令我感到非常惊讶的是,我在该替代方案中几乎没有发现任何内容。所以我的问题是,有什么理由不使用命名空间而不是 chroot 来实现这种用途?
答案1
您应该尝试一下并报告它是如何工作的。凡事总有人是第一!
但我担心的是这行不通。 OpenSSHchroot
是在所有密钥交换、身份验证和所有操作完成之后调用的,但 Systemd 甚至会在启动 sshd 进程之前强制命名空间(如果我正确理解其行为),并且它可能无法处理用户身份验证。同样在服务文件中,您无法区分连接的用户,因此您可以为所有用户命名空间吗?您将如何作为普通管理员用户连接来维护该系统?我相信这当然是一个好主意并且对其他服务很有用,但我不相信您能够“滥用”它(免费)来满足您对 OpenSSH 的需求。