为什么需要 SFTP chroot 牢笼
当一台服务器同时服务多个用户或项目时，默认的 SFTP 登录会让每个账号都能浏览整个文件系统。用户一旦拿到凭据，就能读取 /etc 下的配置、其他站点的目录，甚至尝试访问数据库备份。这种”登录即全盘可见”的默认行为，是很多数据泄露事故的起点。
SFTP chroot 牢笼（chroot jail）解决的就是这个问题：它把某个用户的可访问范围”关”在一个指定目录里，用户登录后只能看到并操作这个目录，目录之外的文件系统对他完全不可见。本文会带你从零配置一个可用的 chroot 牢笼，并说明每一步背后的原因，方便你在自己的服务器上直接落地。
配置前需要明确一点：chroot 牢笼不是银弹，它限制的是”文件系统可见范围”，不负责拦截所有攻击。但它能把误操作、越权读取和部分横向移动的风险明显收窄，是成本最低的权限收窄手段之一。如果你正在规划服务器权限方案，可以先参考我们整理的服务器配置与优化分类，了解常见的权限与安全做法。
配置前的准备：理解 chroot 的工作方式
在动手改配置之前，先理解 chroot 牢笼在 OpenSSH 里是怎么工作的，这能帮你避免很多”配置了却连不上”的坑。
OpenSSH 从 6.0 版本开始内置了 SFTP 子系统的 chroot 支持，核心机制是：当用户通过 SFTP 登录时，sshd 会调用一个内部子系统 internal-sftp，并配合 ChrootDirectory 指令把该用户的根目录切换到指定路径。切换之后，用户看到的 / 就是那个目录，目录之外的一切都不存在。
这里有一个关键约束：ChrootDirectory 指向的目录及其所有上级目录，必须由 root 拥有，且其他用户不能有写权限。否则 sshd 会拒绝启动该用户的 chroot 会话。很多新手在这里卡住，因为把目录权限设成了 777 或让用户自己拥有，结果登录直接被拒。
理解了这一点，配置思路就清晰了：先建一个 root 拥有的”牢笼根目录”，再在里面放一个用户可写的子目录作为实际工作区。下面我们用一个具体例子演示完整流程。
第一步：创建牢笼目录结构
假设我们要给用户 webuser 配置牢笼，工作目录放在 /srv/sftp/webuser。先创建目录并设置权限：
sudo mkdir -p /srv/sftp/webuser
sudo chown root:root /srv/sftp
sudo chmod 755 /srv/sftp
sudo chown webuser:webuser /srv/sftp/webuser
sudo chmod 755 /srv/sftp/webuser
这里的关键是：/srv/sftp 归 root 所有，/srv/sftp/webuser 归 webuser 所有。这样 webuser 登录后只能在自己的工作区里读写，无法越到牢笼根目录之外。如果你希望用户能上传文件，工作区目录必须归该用户所有，否则会报权限不足。
第二步：修改 sshd 配置启用 chroot
编辑 /etc/ssh/sshd_config，在文件末尾追加以下内容：
Match Group sftpusers
ChrootDirectory /srv/sftp/%u
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no
这段配置的含义是：凡是属于 sftpusers 组的用户，登录后都被强制进入 /srv/sftp/用户名 这个牢笼，并且只能使用 SFTP 子系统，无法执行 shell 命令，也无法做端口转发。%u 会自动替换为当前登录用户名，这样每个组内用户都能自动映射到自己的目录。
配置完成后，需要重启 sshd 让改动生效：
sudo systemctl restart sshd
重启前建议先检查配置语法，避免把自己锁在服务器外面：
sudo sshd -t
如果输出没有报错，再执行重启。这一步的检查习惯能帮你避免”改完配置连不上服务器”的尴尬局面。
第三步：创建用户并加入 sftpusers 组
如果 webuser 还不存在，先创建用户并设置密码：
sudo useradd -m -s /usr/sbin/nologin webuser
sudo passwd webuser
这里把用户的 shell 设为 /usr/sbin/nologin，目的是禁止该用户通过 SSH 登录执行命令，只允许 SFTP 文件传输。接着把用户加入 sftpusers 组：
sudo usermod -aG sftpusers webuser
如果你希望多个用户共享同一个牢笼目录，可以把他们都加入 sftpusers 组，并让他们的工作区指向同一个目录。但要注意，共享目录意味着这些用户彼此能看到对方的文件，如果业务上需要隔离，建议每个用户单独建目录。
第四步：验证 chroot 是否生效
配置完成后，用 SFTP 客户端连接测试。以命令行方式为例：
sftp webuser@your-server-ip
登录成功后，执行 pwd 会看到根目录 /，但实际对应的是服务器上的 /srv/sftp/webuser。此时尝试访问牢笼之外的路径，比如 cd /etc，会直接报错或看不到内容，说明 chroot 已经生效。
如果登录时报错 Connection closed，最常见的原因是目录权限问题。请检查 /srv/sftp 是否归 root 所有且权限为 755，以及 /srv/sftp/webuser 是否归 webuser 所有。另一个常见原因是 sshd_config 里 Match 块的位置不对，Match 之后的配置会覆盖之前的默认值，务必把 Match 块放在文件末尾。
常见问题与排障
配置 chroot 牢笼时，有几个高频问题值得提前了解。
问题一：用户无法上传文件。 这通常是因为工作区目录归 root 所有，用户没有写权限。解决办法是把工作区目录的所有者改为该用户，例如 sudo chown webuser:webuser /srv/sftp/webuser。
问题二：登录后看不到任何文件。 如果工作区目录是空的，SFTP 客户端会显示空目录，这是正常现象。你可以先在服务器上放一个测试文件，再登录确认能否看到。
问题三：需要让用户访问多个目录。 chroot 牢笼本身只支持单一根目录，如果用户需要访问多个目录，可以通过 mount --bind 把其他目录绑定到牢笼内部。例如：
sudo mount --bind /var/www/project-a /srv/sftp/webuser/project-a
这样用户就能在牢笼内看到并访问 project-a，而不会暴露整个 /var/www。
权限收窄的边界与建议
chroot 牢笼能有效收窄文件系统可见范围，但它不替代其他安全措施。以下几点建议值得留意：
- 牢笼只限制 SFTP 会话，如果用户还能通过其他方式（如 Web 应用漏洞）访问服务器，chroot 无法拦截。
- 定期检查
sshd_config的Match规则，避免新增用户时误把普通用户也关进牢笼。 - 对高权限账号，建议配合密钥登录和
AllowUsers白名单，进一步缩小攻击面。 - 如果服务器上运行着多个站点，建议为每个站点单独建牢笼目录，避免站点间文件互相可见。
如果你需要一台权限可控、便于隔离的服务器来承载这些配置，可以了解 Hostease 的独立服务器方案，它提供 root 权限，方便你按本文步骤自由配置 chroot 牢笼。对于预算有限、又需要隔离多个项目的场景，VPS主机（虚拟专用服务器，即在一台物理机上划分出的独立运行环境）也是常见选择。
总结
SFTP chroot 牢笼是收窄服务器文件访问权限的实用手段，核心思路是：用 root 拥有的牢笼根目录 + 用户可写的工作区，配合 sshd_config 的 Match 规则，把每个用户限制在指定目录内。配置的关键在于目录权限和 Match 块位置，这两点最容易出错。
建议你在生产环境改动前，先在测试服务器上完整走一遍本文的步骤，确认登录、上传、越权访问都被正确拦截后再上线。如果你需要更细粒度的权限控制，可以结合 mount --bind 扩展牢笼内的目录，或参考我们关于网站性能优化的文章，把安全与性能一起纳入服务器管理流程。