linux sftp 设置了用户对目录有 0700权限，但在上传时报 Permission denied错误
你遇到了一个很典型的情况：在 SFTP chroot 环境中，目录权限 0700 反而导致了上传失败。这看似矛盾，其实是因为在 chroot 的特殊环境下，目录权限的逻辑和我们平常的认知有所不同。
🔍 问题分析：为什么 0700 权限会导致上传失败？
在你之前配置的 SFTP chroot 环境中，目录结构通常是这样的：
/home/testuser/ (属主: root, 权限: 755) ← chroot 根目录，必须归 root 所有且不可写 └── upload/ (属主: testuser, 权限: 700) ← 你设置的 700 权限目录
问题就出在这个 upload 目录的 700 权限上。700 权限意味着只有目录的属主（testuser）可以读、写和执行（进入）。这看起来没问题，因为 testuser 正是属主。但在 SFTP 的 chroot 环境中，权限检查机制更为严格：
-
chroot 根目录检查：
/home/testuser必须归root所有且权限为755，这是 OpenSSH 的安全要求，用于防止用户修改根目录本身 -1-4。 -
写权限要求：对于上传目录，用户不仅需要对目录本身有写权限，还需要目录的属主正确 -10。
-
组权限问题：虽然
700给了用户完全的读写执行权限，但有些 SFTP 实现或特定配置下，如果用户所属组（或其他用户）完全没有权限，可能会触发额外的安全检查 -1。
🛠️ 解决方案：正确设置上传目录权限
方案一：修改为 755 权限（推荐）
将上传目录的权限从 700 改为 755：
sudo chmod 755 /home/testuser/upload
755 权限意味着：
-
所有者（testuser）：读、写、执行（完全控制）
-
组用户（通常也是 testuser 的组）：读、执行（可以进入目录、列出文件，但不能写入）
-
其他用户：读、执行
这个权限设置更符合 SFTP 的预期，同时仍然保持了良好的安全性 -4-8。
方案二：修改为 775 权限（如果需要组内协作）
如果你需要同一个组的多个用户都能上传文件：
sudo chmod 775 /home/testuser/upload
方案三：检查用户所属组
确保 upload 目录的组所有权与用户的组一致：
# 查看用户所属组
groups testuser# 修改目录组所有权
sudo chown testuser:sftp_group /home/testuser/upload # 替换为实际组名
📋 完整的 SFTP 目录权限配置清单
为了确保 SFTP 功能正常，请对照以下清单检查你的目录权限：
| 路径 | 属主 | 推荐权限 | 说明 |
|---|---|---|---|
/home/testuser/ |
root:root |
755 |
chroot 根目录，必须归 root 且不可写 -2-4 |
/home/testuser/upload |
testuser:testuser 或 testuser:sftp_group |
755 或 775 |
上传目录，确保用户有写权限 -5 |
🧪 验证步骤
修改权限后，进行以下验证：
-
重启 SSH 服务：
sudo systemctl restart sshd -
测试上传：
sftp testuser@your_server_ip sftp> cd upload sftp> put testfile.txt -
查看详细日志（如果还有问题）：
sudo tail -f /var/log/auth.log # Debian/Ubuntu # 或 sudo tail -f /var/log/secure # CentOS/RHEL
💡 补充说明
关于之前提到的用户 shell 设置为 /sbin/nologin，这个设置是正确的，它确实能限制用户通过 SSH 登录系统，但不影响 SFTP 的正常使用 -2-5。
如果修改为 755 后问题仍然存在，建议检查一下：
-
目录的父路径权限（如
/home目录本身权限） -
是否启用了 SELinux（可能需要调整策略）-3-8
-
SSH 配置文件中是否有其他限制性设置