Linux SSH密钥登录配置与密码登录禁用安全指南

在Linux服务器安全加固实践中，禁用SSH密码登录并强制使用密钥认证，是提升系统安全性的关键步骤。然而，这一操作潜藏着一个高风险陷阱：若在密钥登录未完全生效前就关闭密码通道，很可能导致管理员被永久锁在服务器之外。这并非夸张，而是许多运维人员在实际工作中积累的深刻教训。

因此，整个流程必须遵循一个核心安全原则：务必在确认密钥登录稳定可靠、且经过充分测试后，才能执行禁用密码登录的操作。接下来，我们将详细解析这一过程中的每个关键步骤与常见误区。

第一步：彻底验证密钥登录是否生效

许多管理员在执行 ssh-copy-id 命令后便认为配置完成，实际上，错误的文件权限、遗漏的配置项等问题，可能导致SSH连接表面上成功，实则仍依赖密码认证。这种假象是后续操作失败的主要根源。

• 全新终端连接测试：最可靠的验证方法是，打开一个新的终端窗口，直接运行 ssh user@host。若连接过程无任何密码提示并能快速登录，才算初步验证通过。
• 强制禁用密钥进行测试：为确认密码通道是否已被彻底阻断，可故意禁用密钥认证进行反向测试：ssh -o PubkeyAuthentication=no user@host。此时服务器应返回类似 No supported authentication methods available 的错误，完全拒绝连接请求。
• 检查服务器端关键权限：这是最易出错的环节。请登录服务器逐一核查：
  • ~/.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 视为必要配置而非可选项，是更为稳妥的安全实践。