你有没有遇到过这种尴尬场面？你给了某个同事或外包团队一个 SFTP 账号，让他们上传项目文件，结果第二天一看，其他目录的文件也被动过了。你问他们怎么回事，他们一脸无辜地说：“我以为那是我自己的目录……”
这时候你会猛然醒悟：你以为配置完 SFTP、建完账号、分完目录，一切就安全了。但事实是——默认配置下，SFTP 用户很容易越权访问到别人的目录，甚至全站文件。
这可不是小问题。在企业环境里，一个账号权限放开了，不止意味着数据泄露，更可能是合规上的大雷，轻则挨批，重则被追责。
那怎么防止这种“越权式访问”？能不能做到每个 SFTP 用户都像住进自己小房间的房客，别人的门一个都打不开？答案是可以，关键在于账号隔离配置。
一、为什么 SFTP 默认配置容易越权访问？
SFTP 本质上是基于 SSH 协议的子系统，只要你给了某个用户 SSH 权限，它就天然拥有了访问整个文件系统的能力。除非你手动配置限制，否则：
- 用户登录后可以
cd /，看到整个系统目录； - 可以进入
/home/otheruser，只要权限没锁死就能读写； - 能探索你不想他看到的系统目录或共享路径。
尤其在多用户 SFTP 传输系统中，不隔离账号目录简直是邀请别人翻你文件柜的邀请函。
二、账号隔离的核心机制：Chroot
要实现“账号隔离”，最直接有效的方式就是——把用户关进小黑屋。
当然我们说的是技术意义上的“关”——用 Chroot（change root）机制，把某个用户的根目录变成它的家目录。这样一来，这个用户在登录后看到的“/”，其实是 /sftp/user1 这个路径，其他路径根本访问不到。
就像是你把一个人安排到酒店房间，他看得到的所有世界就只有这个房间，他怎么走也走不到隔壁。
三、实战操作：基于腾讯云 Linux 搭建隔离 SFTP
下面以腾讯云一台 Ubuntu 实例为例，带你实战配置一个多用户隔离的 SFTP 系统。
1. 创建 SFTP 根目录结构
bashsudo mkdir -p /sftp/user1/upload
sudo mkdir -p /sftp/user2/upload
注意：根目录 /sftp/user1 必须是 root 拥有，不能让用户自己拥有！
bashsudo chown root:root /sftp/user1
sudo chown user1:user1 /sftp/user1/upload
这样就形成了一个“只给走廊钥匙，不给房门钥匙”的结构。
2. 添加用户并指定目录
bashsudo adduser user1
sudo passwd user1
设置密码后，配置用户 shell 为 /usr/sbin/nologin（防止其登录系统）
bashsudo usermod -s /usr/sbin/nologin user1
并设置其 home 目录到我们指定的目录：
bashsudo usermod -d /upload user1
（注意这里的 /upload 是相对路径，在 Chroot 后等于 /sftp/user1/upload）
3. 编辑 SSH 配置文件
bashsudo vim /etc/ssh/sshd_config
在文件尾部添加：
bashMatch User user1
ChrootDirectory /sftp/user1
ForceCommand internal-sftp
AllowTcpForwarding no
如果有多个用户，也可以用：
bashMatch Group sftpusers
然后统一添加用户到这个组。
4. 重启 SSH 服务
bashsudo systemctl restart ssh
此时，user1 登录后只能看到 /upload 目录，尝试 cd .. 会失败，完全出不去。
四、如何验证隔离是否生效？
- 登录 user1：
bashsftp user1@yourserver.com
- 执行
cd ..：
bashsftp> cd ..
Couldn't canonicalize: No such file or directory
- 尝试列出根目录外内容：
bashsftp> ls /
upload
能看到的只有自己目录下的东西，说明隔离生效。
五、多人隔离方案扩展建议
在企业环境中，往往需要支持多人、多项目、多权限。以下是几个实用建议：
✅ 按项目组分组：
将同一项目的人员划入同一 SFTP group，统一管理：
bashsudo groupadd projectA
sudo usermod -aG projectA user1
结合 Match Group + Chroot 实现项目级隔离。
✅ 设置只读/读写权限：
有些用户只能下载文件，不允许上传或删除，可以通过 chmod 配合目录权限控制：
bashchmod 755 upload # 只读
chmod 775 upload # 可读写
也可以建立额外的 incoming 与 outgoing 子目录细分权限。
✅ 自动创建用户目录脚本化：
批量新增用户时，写 Shell 脚本自动完成以下流程：
- 创建目录结构
- 设置权限
- 添加用户 & 设置 Shell
- 更新 sshd_config（或使用模板）
- 重启 ssh
这样即使是大规模的账号隔离场景，也能轻松管理。
六、常见错误排查清单
| 错误表现 | 可能原因 | 解决办法 |
|---|---|---|
| 用户登录后掉线 | Chroot 目录权限错误 | /sftp/user1 必须是 root:root 且不可写 |
| 看不到上传目录 | 没有创建 upload 子目录 | 创建 /sftp/user1/upload 并赋予用户权限 |
| 报错“sftp-server not found” | 没启用 internal-sftp | SSHD 配置中加 ForceCommand internal-sftp |
| 能访问其他用户目录 | Chroot 未正确配置或权限未锁定 | 仔细核查 Match User 部分配置 |
七、防越权不是“可选项”，是责任
别再觉得 SFTP 只是个上传工具就放松警惕了。
一旦账号权限出错：
- 研发可能删掉别人重要目录；
- 外包可能误传文件到生产路径；
- 测试环境泄露源码甚至客户数据；
SFTP 越权就像楼道门不锁，指望别人自觉，不如你自己先上锁。
八、实战后的再提升：日志、告警、审计
你还可以在账号隔离基础上做进一步加强：
- 配合
auditd审计每个 SFTP 用户行为； - 设置
fail2ban防止暴力破解； - 使用日志工具如
GoAccess、logwatch监控上传下载行为； - 整合飞书/企业微信通知，每次异常行为自动推送；
这些加固措施能让你的 SFTP 环境不仅“关得住人”，还能“管得住人”。
好了，现在你可以自信地说一句：
“在我的 SFTP 系统里，每个账号都关在自己的房间，钥匙丢了也找不到别人家门。”
服务器安全，权限隔离，是成本最低的投资，也是最容易被忽略的坑。把这篇指南用到实际中，你就比 90% 的运维团队都更专业。