如何在Linux中配置用户只能通过SFTP登录 Linux限制SSH登录权限的方法

便携式，但必须同时满足：shell设为/sbin/nologin、sshd_config启用internal-sftp并用ForceCommand接管、Chroot路径及其所有上级目录属主为root且权限严格755；仅设置nologin会阻塞SFTP，因OpenSSH仍需会话启动才能派发到sftp子系统。

用户只能通过SFTP登录、完全禁止SSH交互式登录，是可行条件的，但必须同时满足三个：shell设为/sbin/nologin（或/bin/false）、sshd_config中启用internal-sftp并强制ForceCommand、Chroot路径及其所有上级属目录主为root 并且权限严格为755。漏掉任何一个都会导致SFTP连接失败或SSH仍可登录。为什么/sbin/nologin还不够？

只能把用户shell设为/sbin/nologin会同时包围SSH和SFTP——因为SFTP基本上还是走SSH协议，OpenSSH需要能“启动一个会话”才能派发到sftp子系统。此时用户尝试sftp user@host会报Received message too long或直接拒绝连接。必须配合sshd_config中的Match User块，用ForceCommand Internal-sftp接管会话，绕过shell检查/bin/false在部分老版本OpenSSH中不被internal-sftp识别，优先选/sbin/nologin创建用户时不要加-m自动建家目录，避免与ChrootDirectory路径冲突Chro otDirectory权限为什么总报错？

OpenSSH对chroot路径有硬性校验：从/开始，逐级向上直到ChrootDirectory本身（如/sftp/john），每一级目录的所属主必须是root，且不能有群组或其他用户的写权限（即chmod） Docker Desktop（linux）

当前 Docker 最新稳定版本之一，主要针对稳定性和兼容性进行了修复优化，适合生产环境与日常开发使用。该版本继续强化 AI 开发支持、容器日志管理以及 Docker Engine 的安全能力，对 Windows/macOS/Linux 平台兼容性进行了进一步优化。

下载错误示例：chown john:john /sftp/john → 登录立即被拒，auth.log里出现fatal: badownership ormodes for chroot directory正确做法：sudo chown root:root /sftp /sftp/john，再sudo chmod 755 /sftp /sftp/john用户真正可写的目录（如/sftp/john/upload）必须在chroot内单独建立，并由chown john:sftponly授权配置sshd_config最容易踩的坑

顺序和语法错误会导致sshd -t校验失败，甚至服务无法重启。关键点不在“写下面”，而在“怎么写、写在哪”。子系统sftp内部-sftp必须放在#子系统上 sftp ...注释行之后，且不能重复出现Match User john块必须放在文件中，且不能忽略在其他Match或UsePAM块内部ChrootDirectory /sftp/%u里的%u是变量，不能写成/sftp/john硬编码（否则批量失效管理）必须关闭PermitTTY yes（默认可能为yes），否则ForceCommand会被绕过SELinux和auth.log是最后的排查依据

即使所有配置和权限都正确，SELinux执行模式时，同样静默拦截chroot操作，立即现象是SFTP连接后中断，auth.log无明显错误，但ausearch -m avc -ts最近能看到拒绝记录。临时验证：运行sudo setenforce 0，再试SFTP；若成功，说明是SELinux策略问题永久修复：执行sudo setebool -P ssh_chroot_rw_homedirs on，或为chroot路径打标：sudo semanage fcontext -a -t ssh_home_t "/sftp(/.*)?"，再restorecon -Rv /sftp所有调试必须看/var/log/auth.log，不是/var/log/syslog或journalctl -u ssh（夜间常无细节）