AllowUsers是最轻量且优先级最高的用户级白名单机制，认证前过滤请求，不匹配者无密码提示；需重载sshd生效，支持用户名及用户名@主机模式，通配符仅限*和?。
sshd_config 里用 AllowUsers 实现用户级白名单
直接生效、无需重启 sshd 服务（但需重载），AllowUsers 是最轻量且优先级最高的白名单控制方式。它在认证前就过滤连接请求，不匹配的用户连密码提示都不会出现。
实操建议：
- 编辑
/etc/ssh/sshd_config，在文件末尾添加一行：AllowUsers alice bob@192.168.1.*—— 支持用户名、用户名+主机模式（如bob@10.0.0.5或bob@*.example.com） - 多个用户用空格分隔；通配符仅支持
*和?，不支持正则 - 执行
sudo systemctl reload sshd（或sudo service ssh reload）立即生效 - 注意：如果同时配置了
AllowGroups，AllowUsers仍优先生效；但若该用户不在AllowUsers列表中，即使属于允许的组也会被拒绝
为什么不能只靠 PasswordAuthentication no + PubkeyAuthentication yes
禁用密码登录 ≠ 白名单。它只是关闭一种认证方式，所有用户（包括 root、test、backup 等）仍可尝试密钥登录，只要他们有合法密钥和对应账户存在。
常见错误现象：
- 误以为关掉密码就“安全了”，结果发现
john用户的私钥早已泄露，攻击者直接用密钥登录成功 -
Match User块里只写PubkeyAuthentication yes，却没配合AllowUsers或DenyUsers *，导致其他用户依然能走默认策略登录 - 忘记检查
/etc/passwd中是否存在未预期的 shell 用户（如sync、games），它们可能被利用为跳板
Match User 配合 ForceCommand 实现更细粒度控制
当需要对特定用户限制命令执行范围（比如只允许 sftp、禁止交互式 shell），Match User 是唯一可靠手段。它比全局配置更灵活，但必须放在 sshd_config 文件末尾，且每个 Match 块只能写一次。
示例场景（限制用户 sftp-only）：
Match User sftp-only
X11Forwarding no
AllowTcpForwarding no
PermitTTY no
ForceCommand internal-sftp
ChrootDirectory /sftp/%u
关键点：
-
ForceCommand internal-sftp会强制启动 SFTP 子系统，绕过用户 shell，即使用户有/bin/bash也无法获得交互式终端 -
ChrootDirectory路径必须由 root 拥有且不可写（否则 sshd 拒绝启动该用户会话） - 该用户主目录（
/sftp/sftp-only）需满足：属主 root、属组 sftp-only、权限 755；其下子目录（如/sftp/sftp-only/upload）才可设为该用户可写
容易忽略的兼容性与调试陷阱
配置完白名单后连不上？大概率是权限或语法细节出错，而不是逻辑问题。
排查要点：
-
sshd -t必须通过才能重载，但不会校验AllowUsers中的用户名是否存在 —— 若写错用户名（如alise），登录时静默失败，日志里只有Failed password for invalid user alise，容易误判为爆破 - SELinux 启用时，
ChrootDirectory路径需打上system_u:object_r:ssh_home_t:s0上下文，否则internal-sftp启动失败，日志报fatal: bad ownership or modes for chroot directory component - OpenSSH 8.8+ 默认禁用
ssh-rsa签名算法，若老客户端只支持该算法，需显式启用：PubkeyAcceptedAlgorithms +ssh-rsa，否则白名单用户也连不上
真正起作用的永远是最后一条匹配的 AllowUsers 或 DenyUsers，而不是你认为“更靠前”的那条 —— OpenSSH 的匹配顺序是从上到下扫描，但策略叠加规则并不直观，建议白名单只保留一条 AllowUsers 行，其余全注释掉。
