☰

SSH 权限和 chroot

tag-icon • tag-icon ssh debian
SSH 权限和 chroot

目前我使用以下配置

mkdir -p /var/www
chmod -R 555 /var/www
mkdir -p /var/www/user1
chown root:root /var/www/user1
useradd user1
usermod user1 -s /bin/false
usermod user1 -d /var/www/user1
mkdir -p /var/www/user1/html/com.domain.site1
chmod 750 /var/www/user1/html/com.domain.site1
chown -R user1:www-data /var/www/user1/html
chmod -R g+s /var/www/user1/html
groupadd allowSFTP
usermod -a -G allowSFTP user1

对于 SFTP 访问，我将其添加到 sshd_conf

Subsystem sftp internal-sftp
Match Group allowSFTP
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

因此，每个用户只能通过 SFTP 访问自己的目录。

现在我仍然为用户启用了 SSH

Match Group allowSFTPandSSH
    ChrootDirectory %h
    AllowTcpForwarding no
    X11Forwarding no

usermod user1 -s /bin/bash

我如何让用户被困在他的文件夹中？使用 ChrootDirectory，他无法再登录，因为 /bin/bash 不再可用。

如果用户现在使用 npm 或其他东西，则会出现错误，因为用户在文件夹“/var/www/user1/”文件夹或文件夹中的 .npm、cache 等文件中的权限太少。我可以以管理员身份创建这些文件，然后它就可以正常工作了。但我也可以更改一些东西以便用户拥有权限吗？

答案1

用于文件传输的 Chroot 可以很好地隔离传入数据，避免影响系统。OpenSSHForceCommand internal-sftp进一步强制用户只能运行 sftp 命令，并且由于该实现内置于 sshd，因此无需在 chroot 中使用其他程序。

但是，允许 chroot 中的命令会改变一切。现在您需要将程序复制到那里并对其进行修补，这项任务与维护容器映像不太一样。文件权限需要允许它们应该允许的内容，正如您所发现的，这对于构建包等工具来说并不是一件容易的事。通常，可以使用文件权限或 acl 设置您喜欢的任何基于角色的访问控制。虽然现在您没有主目录，只是在 web 服务器 chroot 中转储文件。

考虑不允许在此 chroot 中执行命令。用户提供预构建的软件包，这些软件包会安装在应安装的位置。无需使用 npm 等软件包构建器。有几种方法可以做到这一点，具体取决于您的工作流程。使用花哨的 CI/CD 工具，可以从版本控制触发构建，并最终通过自动过程复制。或者，该人以更手动的过程构建它，然后使用一些仅知道如何将档案提取到 Web 根目录的部署脚本。

相关内容