Linux系统配置SSH密钥登录后禁用密码登录 安全加固

在Linux服务器安全加固中，禁用SSH密码登录、强制使用密钥认证，是公认的有效手段。但这一步操作存在一个致命风险：如果密钥登录尚未完全生效就贸然关闭密码通道，你将直接把自己锁在服务器门外。这绝非危言耸听，而是无数运维同行用血泪换来的教训。

因此，整个流程的核心原则是：必须在确认密钥登录已稳定、绝对可靠的前提下，才能动手禁用密码登录。下面，我们就来拆解这个过程中的每一个关键环节和隐蔽陷阱。

确认密钥登录已真正生效

很多人执行完 ssh-copy-id 命令后，就以为大功告成。实际上，权限设置不当、配置文件遗漏等问题，常常导致SSH连接“看似成功”，实则悄悄回退到了密码认证。这种假象是后续操作的最大隐患。

• 新开终端测试：最直接的验证方法是，打开一个新的终端窗口，直接执行 ssh user@host。整个过程如果没有任何密码提示，并且能瞬间登录成功，这才算初步过关。
• 强制跳过密钥测试：为了验证密码通道是否真的被关闭，可以故意禁用密钥认证进行测试：ssh -o PubkeyAuthentication=no user@host。此时，服务器应该立即返回类似 No supported authentication methods a vailable 的错误，彻底拒绝连接。
• 检查服务器端权限：这是最容易被忽略的细节。务必登录服务器检查：
  • ~/.ssh/authorized_keys 文件的权限必须设置为 600。
  • ~/.ssh 目录的权限必须设置为 700。
  如果权限设置过于宽松（例如755），OpenSSH出于安全考虑会直接忽略这个授权文件，导致密钥登录失败。
• 确认客户端私钥状态：检查你本地使用的私钥文件是否设置了密码短语。如果私钥本身有密码，那么每次连接时仍然需要输入，这很容易让人误以为“密码登录还在工作”，从而做出错误判断。

修改sshd_config的关键三行

仅仅修改 PasswordAuthentication 这一项是不够的。OpenSSH的认证机制是一个链条，其他相关配置如果保持开启，可能会让密码登录“死灰复燃”。

• 必须同步关闭的配置项：
  • PasswordAuthentication no （核心项）
  • ChallengeResponseAuthentication no （挑战应答认证，另一种密码交互方式）
  • UsePAM no （这一点尤其重要。如果系统没有专门为SSH配置PAM策略，开启PAM反而可能绕过前面的限制，重新启用密码验证。）
• 显式启用密钥认证：添加或确保 PubkeyAuthentication yes 是开启状态。在一些较旧的系统或精简版镜像中，这个选项可能默认是注释掉的，不能想当然。
• 禁用空密码登录：设置 PermitEmptyPasswords no，防止某些账户因密码为空而被意外利用。
• 修改后的语法检查：配置文件修改完成后，千万不要直接重启服务。务必先执行 sudo sshd -t 命令进行语法测试。如果没有任何输出，表示配置语法正确；如果有任何报错，必须根据提示修复配置后再进行下一步。

重启前保留一个“逃生会话”

这是整个流程中成本最低、但价值最高的保险措施。一旦重启后的SSH服务配置错误，你将失去所有远程连接方式，只能通过物理控制台或云服务商的VNC进行修复，过程会非常麻烦。

• 操作原则：绝对不要在当前唯一的SSH会话中执行重启命令。保持这个会话窗口完全不动，作为你的“逃生舱”。
• 正确操作：打开一个新的终端，使用已经验证成功的密钥登录方式，连接到服务器。在这个新会话中执行 sudo systemctl restart sshd 命令。
• 重启后立即验证：服务重启后，立刻在新会话中重复之前的测试：
  • 执行 ssh user@host，应该依然能免密登录。
  • 执行 ssh -o PubkeyAuthentication=no user@host，应该被明确拒绝。
• 故障排查：如果测试失败，无法连接，立即回到你保留的那个原始“逃生会话”窗口。通过查看SSH服务日志来定位问题：sudo journalctl -u sshd -n 50 --no-pager。常见错误包括配置文件某行拼写错误、权限问题等。
• 云服务器额外注意：如果你修改过SSH默认端口（22），重启后还需要同步检查云平台的安全组或防火墙规则，是否放行了新的端口。否则，连接会在TCP层面就失败，与认证配置无关。

后续验证与防退化

安全加固不是一次性的操作，而是一种需要持续维护的状态。系统升级、自动化运维工具执行、甚至某些软件包的安装，都可能悄无声息地覆盖或重置你的 sshd_config 文件。

• 定期检查运行时配置：不要只看配置文件，要检查SSH服务实际加载的配置。命令 sudo sshd -T | grep -E "^(password|pubkey|permit|usepam)" 可以列出所有运行时生效的相关参数，这比阅读静态文件更可靠。
• 监控认证日志：定期查看系统认证日志，检查是否还有密码尝试的记录：grep "password" /var/log/auth.log | tail -10。如果仍有大量密码尝试日志，说明某个配置“口子”依然敞开着。
• 自动化配置管理：如果使用Ansible、Puppet等自动化工具管理服务器配置，务必确保你的配置模板是明确覆盖上述关键行，而不是在文件末尾追加。追加可能导致与文件中原有的旧配置产生冲突或共存。
• 注意特殊环境：对于通过容器镜像快速部署、或CI/CD流程中动态创建的临时服务器，要特别小心。这些环境常常会跳过部署SSH公钥的步骤，如果直接应用禁用密码的配置，会导致整个自动化流程中断。

最后，再强调一个最隐蔽的陷阱：你以为通过 sshd_config 关掉了密码登录，但如果 UsePAM 被设为 yes，并且系统PAM配置中包含了 pam_pwquality 等密码管理模块，那么密码验证可能会在PAM层面“复活”。因此，在大多数追求纯粹密钥登录的场景下，将 UsePAM no 视为必要项，而非可选项，是更为稳妥的做法。