发布日期：2026 年 9 月 19 日 · RootGS 技术编辑
为服务器启用密钥登录是常见的安全改进，但“把 PasswordAuthentication 改成 no”并不是完整流程。密钥是否真正被使用、条件配置是否覆盖目标用户、管理员能否提权、自动化任务是否仍可运行，都会影响最终结果。本文以使用 OpenSSH 的 Linux 服务器为例，介绍先验证、后变更、再独立验收的方法；不会假设所有发行版具有相同默认设置。
一、先明确账号、访问路径和恢复入口
列出哪些人和任务通过 SSH 登录：运维人员、备份程序、发布任务、SFTP 客户端，以及经由跳板机进入的账号。每类访问应有明确的账户与密钥归属，不能只测试自己的终端就认定迁移完成。禁止直接 root 登录前，还要验证替代管理员账号能够按预期使用 sudo。
确认服务商控制台、串行终端或其他带外入口确实能用，并了解其恢复操作。保留当前已建立的管理会话，同时另开窗口进行新连接测试。已有会话在配置变更后通常不会重新认证，因此“旧窗口还能执行命令”不能证明新连接正常，也不能作为唯一恢复手段。
二、密钥应在可信客户端生成和保管
私钥应留在受控客户端，服务器保存对应公钥。不要把私钥上传到网页工具、工单或群聊，也不要把多人共用的一把私钥当成便于管理。按人员或用途区分密钥，才能在设备遗失、人员变更时准确撤销权限。是否采用硬件密钥、口令保护和代理，需要结合团队实际管理能力决定。
公钥登录失败时，先确认登录用户名、有效的 AuthorizedKeysFile 路径、文件归属和权限；还要注意 SELinux 等系统机制是否影响访问。不要为了排错直接放宽整个用户目录权限。首次连接或服务器重装后出现主机指纹变化，应通过可信控制台核对，不要为了消除警告盲目跳过主机身份检查。
三、证明这次连接确实使用了指定密钥
SSH 客户端可能自动尝试代理里的多个密钥，密钥不成功后又退回密码。因此一次“能登录”并不能证明计划中的密钥已经可用。下面的示例限制身份选择，并禁止回退到服务器密码和键盘交互认证；请替换用户名、地址与客户端私钥路径。
ssh -o IdentitiesOnly=yes \
-o PreferredAuthentications=publickey \
-o PasswordAuthentication=no \
-o KbdInteractiveAuthentication=no \
-i ~/.ssh/id_ed25519 -l admin example.com如果客户端询问私钥的本地解锁口令，这不等于服务器接受了账号密码。进入后核对账号身份、工作目录和必要的提权操作。自动化任务应另外在自己的执行环境中测试，因为后台任务可能没有交互终端、密钥代理或解锁能力。调试输出有助于分析认证方式，但分享前应遮盖用户名、地址和内部路径。
四、检查真正生效的配置，而不只看一个文件
OpenSSH 可以通过 Include 引入其他配置，并使用 Match 为特定用户、来源地址或连接条件设置不同规则。很多选项采用先取得的值，不能假定把同名设置追加在文件末尾就会覆盖前面的内容。发行版的软件包默认值也可能与上游手册不同，应结合本机版本和实际生效配置判断。
先用 sshd -t 检查语法和相关基础条件，再使用 sshd -T 查看有效配置。存在 Match 时，可用 -C 提供有代表性的连接上下文。以下示例中的用户、主机名和文档地址必须按真实访问场景替换；这些命令需要适当权限，且不会重新加载服务。
sudo sshd -t
sudo sshd -T -C user=admin,host=client.example,addr=192.0.2.20如果 Match 还依赖本地地址、端口等条件，也要传入相应参数。来自公网、VPN 与跳板机的连接可能匹配不同规则，需要分别核对。静态检查能发现部分问题，但不能验证防火墙、PAM、目录权限和客户端的整个登录链路。
五、区分密码认证、键盘交互与多因素认证
PasswordAuthentication 控制密码认证方式；键盘交互认证则有独立开关，某些环境可以通过它进行 PAM 密码或多因素挑战。因此关闭前者不能简单等同于“所有形式的密码输入都已禁止”。应先确定目标究竟是纯公钥，还是公钥加第二因素，再选择配置。
纯公钥方案可以评估同时关闭 PasswordAuthentication 和 KbdInteractiveAuthentication；但如果现有多因素认证依赖后者，直接关闭会破坏该登录流程。AuthenticationMethods 可以组合认证要求，其组合必须与可用方式匹配。不要照抄一组互相冲突的选项，更不要只为让测试通过而随意关闭 PAM。
六、在有恢复路径的窗口中应用变更
保存原配置及文件权限，记录修改内容与恢复方式。确认语法检查成功、指定密钥的新连接已成功、替代管理员具备必要权限，再根据发行版和服务管理方式加载配置。不同系统服务名可能是 ssh 或 sshd，是否支持 reload 也应先确认，不能直接套用不匹配的服务命令。
应用后保留原会话，用新窗口再次连接，检查登录、sudo、文件传输及必要的自动化任务。如果新连接失败，优先利用仍可用的会话恢复配置并再次检查，不要连续叠加修改。服务重启、网络规则变更和密钥迁移最好分步处理，避免故障时无法判断是哪项改动造成。
七、同时验证允许与拒绝的路径
验收不仅要证明合法密钥能登录，还应通过少量受控测试确认不允许的认证方式确实被拒绝。测试要使用独立连接，并考虑已有连接复用、客户端代理和自动封禁工具的影响，避免把复用会话当成一次新的认证结果。
最后记录密钥归属、撤销方法、恢复入口和检查日期。关闭密码登录并不会自动处理泄露的私钥、过宽的 sudo 权限或已经被入侵的账号；后续仍需定期更新系统、审查登录事件并回收过期授权。加固的完成标准是：授权路径可用、禁止路径被拒绝、故障能够恢复，而且每一步都有可核对的证据。
