最近有不少系统管理员反馈，在将服务器上的 OpenSSH 升级到新版本后，突然无法通过 SSH 登录。这一问题不仅影响日常运维，还可能导致业务中断。本文将结合真实案例，深入浅出地分析常见原因，并提供实用排查思路。
OpenSSH 在新版本中可能弃用或修改某些旧配置项。例如，从 OpenSSH 8.8 开始，默认禁用了 ssh-rsa 签名算法；而一些老旧客户端仍在使用该算法，导致连接被拒绝。有用户在升级后发现日志中出现“no mutual signature algorithm”错误，正是这个原因。解决方法是：要么在服务端临时启用 Legacy 算法（不推荐长期使用），要么更新客户端密钥类型为更安全的 ecdsa-sha2-nistp256 或 rsa-sha2-256。
在基于 RHEL/CentOS 或 Ubuntu 的系统中，安全模块如 SELinux 或 AppArmor 可能在升级后重置策略，阻止 sshd 访问关键文件（如 authorized_keys）。一位运维工程师曾遇到升级后 root 用户无法登录的情况，最终发现是 /root/.ssh/ 目录的 SELinux 上下文被重置。通过运行 restorecon -Rv ~/.ssh 恢复上下文后问题解决。
有时升级过程看似成功，但 sshd 服务未完全重启，仍运行旧进程，或者新版本监听了不同端口。某次生产环境中，管理员升级后习惯性执行 service ssh restart，却忽略了 systemd 管理的真正服务名为 sshd，导致旧进程残留，新配置未生效。建议使用 systemctl restart sshd 并通过 ss -tulnp | grep :22 确认监听状态。
OpenSSH 升级虽能提升安全性，但也可能带来兼容性挑战。遇到无法登录时，应优先检查日志（/var/log/auth.log 或 /var/log/secure）、确认配置语法（sshd -t）、验证密钥算法兼容性。提前在测试环境演练升级流程，可大幅降低生产风险。