升级内核后 SSH 突然连不上？GSSAPIKexAlgorithms 不兼容问题的完整排查与解决
前言
作为一名运维工程师，服务器内核升级是日常工作中再常见不过的操作。但就是这样一个看似常规的操作，却可能引发意想不到的基础服务故障。
就在昨天，我遇到了一个非常典型的问题：升级服务器内核并重启后，服务器网络完全正常 —— 能 ping 通网关，客户端也能 ping 通服务器，但所有 SSH 连接全部失败。这个问题看似简单，排查过程却绕了不少弯路，最终发现是一个非常隐蔽的配置兼容性问题。
今天我把整个排查和解决过程完整记录下来，希望能帮到遇到同样问题的同行。
一、问题现象：网络通但 SSH 连不上
1.1 事件背景
- 操作系统：RHEL 8.8（CentOS/Rocky Linux 8.x 系列同样会遇到）
- 操作：执行
yum update kernel升级内核到最新版本 - 重启后现象：
- ✅ 服务器本地登录正常
- ✅ 服务器能 ping 通网关和外网
- ✅ 客户端能 ping 通服务器 IP
- ❌ 所有 SSH 客户端连接失败，提示 "Connection refused"
1.2 初步排查
首先想到的是 sshd 服务可能没启动，于是在服务器本地执行：
systemctl status sshd果然，sshd 服务处于
failed 状态，并且在不断自动重启。接下来查看服务日志，这是排查服务启动失败的关键步骤：
tail -f /var/log/messages日志中反复出现以下错误信息：
systemd[1]: Starting OpenSSH server daemon...
sshd[7653]: command-line: line 0: Bad configuration option: GSSAPIKexAlgorithms
systemd[1]: sshd.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: sshd.service: Failed with result 'exit-code'.
systemd[1]: Failed to start OpenSSH server daemon.
核心错误已经很明显了：
Bad configuration option: GSSAPIKexAlgorithms
OpenSSH 服务启动时遇到了一个它不认识的配置选项。
二、第一波踩坑：找不到的配置参数
看到错误信息后，我的第一反应是去修改 sshd 的主配置文件：
vi /etc/ssh/sshd_config我在文件里搜索
GSSAPIKexAlgorithms，结果什么都没找到。我又检查了 sshd_config.d 目录下的所有子配置文件：
grep -r "GSSAPI" /etc/ssh/sshd_config.d/
依然没有找到这个参数。
这就奇怪了，日志明明说有这个错误的配置项，但我在所有常规的 SSH 配置文件里都找不到它。
三、深入排查：隐藏在加密策略里的 "幽灵" 配置
3.1 发现问题根源
经过一番搜索和思考，我突然想到：RHEL 系发行版有一个全局的加密策略管理系统
crypto-policies，它会自动生成各个服务的加密配置文件。OpenSSH 的配置文件里默认有这样一行：
include /etc/crypto-policies/back-ends/opensshserver.config
这行配置会把系统加密策略生成的 OpenSSH 配置包含进来。
我立刻查看这个文件：
cat /etc/crypto-policies/back-ends/opensshserver.config
果然，在这个文件里找到了包含
GSSAPIKexAlgorithms 的配置行！3.2 为什么升级内核会触发这个问题？
这是很多人都会问的问题：我只是升级了内核，为什么会影响到 OpenSSH 的配置？
其实，升级内核本身并不会直接修改 OpenSSH 的配置，但它通常会伴随以下两个变化：
- 系统包依赖更新：升级内核时，
yum会自动更新相关的依赖包，其中就可能包括crypto-policies包 - 内核与用户空间程序的兼容性变化：新内核可能与旧版本的补丁版 OpenSSH 存在兼容性问题，导致系统在启动时重新生成加密策略文件
而真正的根本原因是：RHEL 系发行版的 OpenSSH 与原生 OpenSSH 的差异。
四、根本原因分析：发行版补丁与上游软件的兼容性陷阱
4.1 GSSAPIKexAlgorithms 到底是什么？
GSSAPIKexAlgorithms 并不是 OpenSSH 官方原生支持的配置项。它是 RHEL/CentOS/Rocky/OpenEuler 等发行版为了支持 Kerberos 单点登录，给 OpenSSH 打的一个专属补丁。这个补丁添加了这个配置项，用于指定 GSSAPI 认证使用的密钥交换算法。
4.2 为什么会不兼容？
当你升级系统时，可能会发生以下两种情况之一：
- crypto-policies 包更新：新版本的 crypto-policies 生成了包含
GSSAPIKexAlgorithms的配置文件 - OpenSSH 包意外升级：你可能不小心升级到了不带 RHEL 补丁的原生 OpenSSH 版本
无论哪种情况，最终结果都是：你的 OpenSSH 程序不认识系统加密策略生成的
GSSAPIKexAlgorithms 配置项。当 OpenSSH 启动时读到这个它不认识的参数，会直接报错并退出，导致整个 SSH 服务无法启动。
五、完整解决过程
步骤 1：备份原始配置文件
在修改任何系统配置之前，养成备份的好习惯：
cp /etc/crypto-policies/back-ends/opensshserver.config /etc/crypto-policies/back-ends/opensshserver.config.bak步骤 2：修改加密策略配置文件
编辑 opensshserver.config 文件：
vi /etc/crypto-policies/back-ends/opensshserver.config
找到包含
GSSAPIKexAlgorithms 的行，在行首加 # 注释掉，或者直接删除这一行。步骤 3：重启 sshd 服务
systemctl daemon-reload
systemctl restart sshd步骤 4：验证服务状态
systemctl status sshd看到
active (running) 就说明服务已经正常启动了。步骤 6：测试 SSH 连接
从客户端尝试连接服务器，确认 SSH 功能恢复正常。
备用方案：重置系统加密策略
如果上面的方法比较麻烦，也可以直接重置系统的加密策略为默认值：
update-crypto-policies --set DEFAULT
systemctl restart sshd
这个命令会自动重新生成所有服务的加密配置文件，通常也能解决问题。
六、总结与预防措施
6.1 问题总结
这次问题的本质是 「系统加密策略配置」与「OpenSSH 程序版本」的不兼容。RHEL 系发行版给 OpenSSH 打了专属补丁，添加了非标准的配置项，当系统更新导致两者不匹配时，就会引发服务启动失败。
6.2 预防措施
- 升级前备份关键配置：特别是
/etc/ssh和/etc/crypto-policies目录 - 升级后检查关键服务：内核升级重启后，第一时间检查 SSH、防火墙等基础服务状态
- 了解系统特性：不同发行版有自己的定制和补丁，不要想当然地认为所有 Linux 系统都一样
- 谨慎升级 OpenSSH：如果需要升级 OpenSSH，优先使用发行版官方仓库的版本，避免直接编译安装原生版本
写在最后
这次排查过程让我深刻体会到，运维工作中细节决定成败。一个看似简单的内核升级，可能会因为一个非常隐蔽的发行版补丁差异，导致最基础的 SSH 服务瘫痪。
希望这篇文章能让你在遇到同样问题时少走弯路。如果你觉得这篇文章对你有帮助，欢迎点赞收藏，也可以分享给身边的运维朋友。
阅读剩余
本站代码模板仅供学习交流使用请勿商业运营，严禁从事违法，侵权等任何非法活动，否则后果自负！
THE END
