Linux SSH 仅允许密钥登录怎么做：账户白名单、配置检查和可回退发布

给服务器关掉 SSH 密码登录，本意是减少撞库和弱口令风险，最常见的事故却是管理员刚保存配置，就发现自己的密钥没被加载，只能跑到机房操作或者靠云控制台的救援模式救急。真正稳妥的做法不是一次性改完所有开关，而是先确认现有密钥通路正常，再收紧可登录的账户范围，最后留一条仍然在线的老会话做回退兜底。

先验证至少一个普通运维账号能用密钥稳定登录，再关闭密码入口；配置落盘后必须先跑 sshd -t 做语法校验，并且在旧会话不退出的前提下新开一次连接测试。新连接验证成功，才允许重载 SSH 服务。

先确认哪些账号和密钥属于受保护资产

SSH 加固保护的不只是 22 端口本身，还包括运维账号、公钥、跳板机来源和预留的救援入口。生产机至少应明确一个日常运维账号，例如 deploy；它的私钥由谁保管、对应公钥写在哪个位置、是否已经具备可用的 sudo 权限，都要先核对清楚。

这里别急着网上随便复制配置片段。先开另一个终端窗口用目标账号登录一次，并确认 ~/.ssh/authorized_keys 的属主和权限正确。如果当前还依赖密码登录，先补全密钥通道并做一次新会话验证，再进入关闭密码登录的阶段。

把加固规则放进独立配置片段

很多主流发行版会自动加载 /etc/ssh/sshd_config.d/ 下的自定义配置片段。新规则单独存放，日后排查问题和回滚撤销都更清晰；如果当前环境没有这个自动加载的机制，就在主配置的对应位置添加配置，同时提前备份好原文件。不同版本的 SSH 支持的配置项略有差异，部署前可以用本机的 man 手册和语法检查命令确认。

# /etc/ssh/sshd_config.d/60-access.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AllowUsers deploy ops
MaxAuthTries 3

AllowUsers 是生效的访问白名单，不是注释文本。启用后不在列表里的所有账号都会被直接拒绝，因此自动化发布账号、跳板机专用账号也要提前梳理清楚加到列表里。如果要加来源地址范围限制，先只在隔离测试环境试匹配规则，避免网络地址写错导致所有正常登录都被挡住。

先做语法检查，再查看实际生效项

保存文件后第一步不要直接重载服务，先让 SSH 守护进程预读取配置。sshd -t 能提前发现明显的语法错误；sshd -T 适合直接查看配置生效后的关键参数。这两个命令执行通过，只说明配置本身格式合法，不代表你的密钥一定能正常登录，所以后面仍要新开真实会话做验证。

sudo sshd -t
sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin|pubkeyauthentication|maxauthtries'

# 保持当前会话不退出，另开终端验证
ssh deploy@server.example

新会话发起后应该直接进入密钥认证流程，不再弹出密码输入提示。如果没走密钥认证流程，先回到仍在线的旧会话检查用户名、公钥文件权限、配置片段加载顺序和服务日志，不要为了临时连上就把密码认证重新开放给所有账号。

用双会话把回退路径留在手里

最安全的配置发布方式，是旧会话和新会话同时在线：旧会话负责兜底回退，新会话负责验证刚落地的新规则。新会话能正常运行 sudo、读取目标存储路径并再次发起登录后，再用对应发行版的 SSH 重载命令让新配置接管后续所有新连接。

1. 会话 A 保持在线，全程不关闭这个连接的认证状态。
2. 在会话 A 写入新配置片段并运行 sshd -t 做校验。
3. 在会话 B 用白名单里的账号新建密钥登录，确认没有弹出密码提示。
4. 重载 SSH 服务后再次建立会话 C 确认可用；整个流程任意一步失败，都在会话 A 移除新配置片段并重载服务快速恢复。

系统日志也要纳入日常检查范围：连续登录失败的账号、来源地址和认证方式能帮助判断是外部扫描流量还是内部配置遗漏。不要把密钥明文内容写进日志或工单，只记录账号、时间和失败原因就足够后续复盘。

相关问题

关闭密码登录后还能用云控制台救援吗？

通常云控制台提供的是带外管理入口，但具体实现方式由平台决定。不要把它当作唯一的回退方案；发布新配置前仍应保持现有 SSH 会话在线，并提前确认普通运维账号的密钥通路正常可用。

AllowUsers 和 AllowGroups 选哪个？

账号很少且人员变动不频繁时，AllowUsers 更直观好维护。团队账号由统一用户组管理时，可以考虑 AllowGroups，但必须把组成员变更也纳入正规权限流程。

为什么 sshd -t 通过后仍可能登录失败？

语法检查只证明配置本身能被正常解析。公钥没有放到对应账号的目录下、家目录权限不符合 SSH 要求、白名单账号遗漏和多个配置片段加载顺序冲突，都会让实际认证失败。

密钥登录是否意味着不需要再看认证日志？

不是。密钥减少了密码猜测的攻击面，但失效密钥、异常来源和白名单遗漏这类问题仍需要通过日志发现。把失败请求趋势和异常账号纳入日常检查更可靠。

收尾：远程入口要先能验证，再谈关闭

SSH 加固最重要的不是记住几行配置参数，而是让每条访问路径都可解释、可验证、可撤销。先准备好普通账号和可用密钥，后收紧密码和 root 远程入口权限；先开新会话验证，后重载服务。这个执行顺序守住了，安全性和可维护性才能一起提高。