禁用SCP和SFTP的核心是彻底禁用SFTP子系统：注释或删除sshd_config中所有Subsystem sftp行，重启sshd；辅以移除scp/rsync执行权限及ForceCommand锁定shell，实现分层阻断文件传输。
要禁止用户通过 SSH 协议进行文件传输（即禁用 SCP 和 SFTP），核心思路是切断 SSH 服务中与文件传输相关的子系统和命令执行能力，同时保留正常的交互式 SSH 登录（如需）或完全禁用登录（按需）。这不是单纯“关掉一个功能”，而是分层控制：协议层、子系统层、命令层、可执行文件权限层。
以下是最常用、最可靠且生产环境验证过的几种方法，按推荐顺序排列：
禁用 SFTP 子系统（最直接有效）
SFTP 是 OpenSSH 内置的子系统，禁用它即可阻止所有基于 SFTP 的传输（包括 WinSCP、FileZilla SFTP 模式、sftp 命令等）。
-
编辑
/etc/ssh/sshd_config：sudo nano /etc/ssh/sshd_config
-
找到并注释或删除以下行（确保整行被禁用）：
# Subsystem sftp /usr/lib/openssh/sftp-server # Subsystem sftp internal-sftp
⚠️ 注意：只需保留 零行
Subsystem sftp ...。若存在多行（如旧配置残留 + 新配置），sshd 启动时仅加载第一行，其余忽略——但为防误启，务必全部注释或删净。 -
重启服务生效：
sudo systemctl restart sshd
✅ 效果：sftp user@host 失败；scp file user@host:/path 也失败（因 scp 依赖 SFTP 子系统或 sftp-server 进程）。
禁用 SCP 命令（补充加固，防绕过）
即使 SFTP 已禁，部分老版本 OpenSSH 或自定义环境仍可能通过 scp 直接调用 shell 执行传输（尤其在未启用 ForceCommand 时）。更稳妥的做法是限制用户无法执行 scp 二进制。
-
查看
scp路径：which scp # 通常为 /usr/bin/scp 或 /bin/scp
-
对目标用户（如
devuser）移除执行权限（使用 ACL）：sudo setfacl -m u:devuser:--- /usr/bin/scp
-
验证：
sudo -u devuser scp --version # 应提示 Permission denied
⚠️ 注意：此操作不影响 root 或其他用户；若需批量控制，可对整个 sftpusers 组设置：sudo setfacl -m g:sftpusers:--- /usr/bin/scp
强制限制特定用户仅能执行 shell（反向策略）
如果你希望允许某用户 SSH 登录，但明确禁止其任何文件传输行为（即只给 shell，不给 scp/sftp），可在 sshd_config 中用 ForceCommand 锁定：
Match User reportuser
ForceCommand /bin/bash
X11Forwarding no
AllowTcpForwarding no
PermitTunnel no✅ 效果：该用户能 ssh reportuser@host 进入 bash，但运行 scp 或 sftp 会失败（因为连接一建立就被强制跳转到 /bin/bash，不经过子系统协商）。
⚠️ 注意：ForceCommand 会覆盖所有子系统，包括 SFTP；但它不阻止用户在 shell 内手动调用 curl、wget 或 rsync over ssh —— 若需彻底封禁外传，还需配合网络策略或审计工具。
（可选）禁用 rsync over ssh 和 tar over ssh
这些不属于 OpenSSH 原生子系统，但常被用作“隐蔽传输通道”。若需全面封堵：
-
禁用
rsync执行权限（同scp方式）：sudo setfacl -m u:devuser:--- /usr/bin/rsync
-
或在用户 shell 初始化文件中屏蔽（不推荐主方案，易绕过）：
echo 'alias rsync=/bin/false' | sudo tee -a /home/devuser/.bashrc
不复杂但容易忽略：禁用文件传输 ≠ 禁用登录，也不等于数据绝对安全。真正关键的是明确「谁需要什么权限」，再逐层收紧。上面四步组合使用，可覆盖 99% 的常规 SSH 文件传输场景。
