张瑞15129378030你们有没有遇到过这种情况：某天突然收到安全扫描报告，OpenSSH版本过旧、存在多个高危CVE，要求限期整改。或者等保测评时被指着SSH版本号说事，再或者新上线的自动化平台因为ssh-rsa算法被禁用而连不上服务器。如果你是CentOS运维，这几乎是每年都会撞上的问题——CentOS自带的OpenSSH版本常年不变，而安全要求却一直在升级。这篇文章就围绕CentOS环境下把OpenSSH升级到10.2p1的全过程展开，讲清楚为什么升、怎么升、升完之后怎么处理配置，以及最容易翻车的几个环节。适合需要在存量CentOS系统上做安全加固和版本升级的运维朋友参考。
1. 为什么要动OpenSSH——聊聊版本升级背后的真实驱动力
1.1 安全扫描和漏洞报告的倒逼
很多运维第一次升级OpenSSH，不是在计划内做的，而是被安全扫描报告“逼”出来的。CentOS 7默认的OpenSSH是7.4p1，CentOS 8自带的也不过8.0p1左右，这俩版本在现在的漏洞库里已经是“重点关照对象”了。CVE列表中针对sshd和SSH客户端的漏洞报告一年比一年多，包括远程代码执行、权限提升、信息泄露等各种类型。虽然很多漏洞在实际利用上需要比较苛刻的条件，但等保测评、安全审计、漏洞扫描这类检查，看的就是版本号。你一看到报告里写着“OpenSSH < 9.3p1 存在多个安全漏洞”，基本上就没得商量，必须升级。
我最早一次升级OpenSSH，就是因为某云平台的安全体检报告，直接把OpenSSH列成了“高危”。当时远程操作，边升边冒汗，生怕ssh断掉了连不回去。后来升级次数多了，才慢慢总结出一套比较稳的流程。这套流程不是我发明的，而是每次踩坑之后补出来的，现在分享给你。
1.2 新协议和新算法带来的兼容性变化
除了安全问题，OpenSSH新版本还在不断收紧算法策略。10.2p1这个版本里，很多旧算法默认不再启用。举个例子，ssh-rsa签名算法（基于SHA-1）从OpenSSH 8.8开始就在默认配置里被禁用了，如果你有一些老设备、老脚本还在用ssh-rsa，升级之后会直接连不上。这意味着升级OpenSSH不只是替换几个二进制文件那么简单，你还要同步梳理自己环境里有哪些在用旧算法的客户端或服务端。
另外，新的密钥交换算法（比如sntrup761x25519-sha512、mlkem768x25519-sha512这类后量子算法）也在逐渐进入默认清单。10.2p1这类较新版本，对OpenSSL的版本也有要求，如果系统自带的OpenSSL太老，编译的时候就得带上新版OpenSSL源码一起编，否则很多新特性用不了，有些新算法也支持不了。这些都是升级前需要想清楚的。
1.3 CentOS自带版本和10.2p1的差别在哪里
CentOS自带OpenSSH通常是通过系统源维护的，特点是“稳定但固定”，很少给你主动升级大版本。OpenSSH 10.2p1相对CentOS自带的7.x/8.x版本，提升是跨世代的。除了算法层面的变化，还改进了sshd服务管理方式、增强了FIDO/U2F硬件密钥的支持、优化了scp/sftp的传输逻辑（新版本scp默认走SFTP协议，老版scp走的是RCP，这会导致一些自动化脚本行为发生变化），还修补了一大批已知CVE。
在实际部署中，你编译安装10.2p1之后，完全可以保留CentOS原有的一些配置习惯，因为配置文件路径我推荐继续放在/etc/ssh下，sshd_config的语法大部分也是向后兼容的。不过要注意，有些旧参数在新版本里可能被标记为废弃，启动时会出现警告，虽然不影响启动，但看着难受，也说明你的配置该“洗一遍”了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 升级前必须落实的“保命”准备
2.1 备份：不是可选项，而是保命项
升级OpenSSH最重要的规则就一条：先备份。备份的内容不只是配置文件，还包括现有二进制文件。因为OpenSSH是远程登录的命脉，一旦新版本编译好启动不了，你是要通过旧版本“续命”回去的。我见过有些同事直接拿源码包make install覆盖了系统自带OpenSSH，结果新版本起不来，旧的又被覆盖了，只能靠着物理控制台或者带外管理卡去恢复，那个过程相当痛苦。
建议备份这些内容：
bash复制mkdir -p /root/openssh_backup_$(date +%Y%m%d)
# 备份配置文件
cp -rp /etc/ssh /root/openssh_backup_$(date +%Y%m%d)/ssh_config_bak
# 备份现有二进制
cp /usr/sbin/sshd /root/openssh_backup_$(date +%Y%m%d)/sshd.bak
cp /usr/bin/ssh /root/openssh_backup_$(date +%Y%m%d)/ssh.bak
cp /usr/bin/scp /root/openssh_backup_$(date +%Y%m%d)/scp.bak
cp /usr/bin/sftp /root/openssh_backup_$(date +%Y%m%d)/sftp.bak
# 备份系统服务管理文件
cp /usr/lib/systemd/system/sshd.service /root/openssh_backup_$(date +%Y%m%d)/sshd.service.bak
有些朋友问要不要把整个系统镜像一下，如果你有虚拟化快照或者云平台快照功能，我当然建议先打个快照，这是最彻底的保底方案。但即便有快照，上述备份也建议做，因为快照回滚的成本高，有时候回到旧快照会丢失升级期间产生的其他变更，而手动备份只针对OpenSSH相关文件，回滚更精准。
2.2 应急通道：升级失败也能回到系统的第二把钥匙
一直靠SSH远程操作的朋友，对“应急通道”这个概念可能比较陌生。但升级OpenSSH必须提前想好：如果新sshd起不来，这台机器你还能怎么进去？这里几个方案按优先级排列：
第一种是在升级前先启用telnet作为临时应急。虽然telnet是明文传输，安全性差，但它此刻只是一个“逃生通道”，升级完成、验证SSH正常之后立刻关闭它。对于内网环境，临时开几分钟到几十分钟是可以接受的。CentOS 7启用telnet需要安装telnet-server：
bash复制yum install -y telnet-server telnet xinetd
systemctl enable telnet.socket
systemctl start telnet.socket
如果在系统防火墙里需要放行23端口，升级验证完立刻回收。
第二种是依赖带外管理卡（IDRAC、iLO、IPMI）或者云控制台的VNC。如果有这个条件，SSH断了可以直接从VNC进去恢复。这是我认为最稳的“保底方案”。
第三种是做服务重启的“自动回滚”。这个思路比较高级，写一个脚本放在后台，检测到sshd没起来就自动把旧二进制复制回去。我在生产环境试过一次，虽然最后没用上，但心里踏实了很多。脚本逻辑不复杂，就是用systemctl状态判断加重试次数，但需要注意脚本本身不能依赖SSH，得通过计划任务跑。
2.3 先确认当前系统的依赖状态
编译OpenSSH需要几个基础依赖：gcc、make、perl、zlib-devel、openssl-devel、pam-devel。CentOS 7上有些精简安装的系统连gcc都没有，所以第一步先把这些包装齐。
bash复制yum install -y gcc gcc-c++ make perl zlib-devel openssl-devel pam-devel libselinux-devel krb5-devel
这里的openssl-devel尤其重要，因为OpenSSH编译时要链接OpenSSL库。如果你的系统OpenSSL版本比较老（CentOS 7默认1.0.2系列，CentOS 8默认1.1.1系列），编译OpenSSH 10.2p1通常也能过，但某些新算法可能受限。如果需要完整支持新算法，编译时链接新的OpenSSL是另一个话题，后面我会说。
还要检查一下系统里有没有装一些会影响编译的旧开发头文件，比如/usr/include/openssl如果存在且版本过老，可能会干扰新版本的编译。最保险的方式是在干净环境下编译，也可以指定--with-ssl-dir来指向新版OpenSSL路径。
3. 编译安装——从源码包到系统服务的完整过程
3.1 拿到源码包并解压
源码包获取方式不在这里写了，直接去OpenSSH官网下载openssh-10.2p1.tar.gz，下载之后丢到/usr/local/src下面。
bash复制cd /usr/local/src
tar -zxvf openssh-10.2p1.tar.gz
cd openssh-10.2p1
这里提醒一下：下载后建议校验一下SHA256，尤其是你在非官方镜像站下载的包，校验一下更安心。我习惯把校验结果和下载日期记录在本地文档里，方便追源。
3.2 configure参数说明与选择
OpenSSH的configure参数非常灵活，不同场景选不同的组合。这里给出一套我在CentOS 7上实测可用的配置：
bash复制./configure \
--prefix=/usr/local/openssh \
--sysconfdir=/etc/ssh \
--with-pam \
--with-zlib \
--with-md5-passwords \
--with-privsep-path=/var/empty/sshd \
--with-ssl-dir=/usr/lib64 \
--with-kerberos5=/usr/lib64
逐项解释一下这些参数的含义。
--prefix=/usr/local/openssh是指定OpenSSH安装的根目录，二进制会装到/usr/local/openssh/bin和/usr/local/openssh/sbin里。我这里没用默认的/usr/local，而是单独分了一个目录，好处是升级和回滚都清晰，旧版在/usr/bin/sshd，新版的在/usr/local/openssh/sbin/sshd，互不干扰，临时需要切回去也方便。
--sysconfdir=/etc/ssh这个参数很关键。OpenSSH编译时默认会把配置文件装到prefix/etc下面，但CentOS的SSH配置一直在/etc/ssh，很多系统脚本和服务管理文件都引用这个路径。如果你不指定，升级后可能出现新sshd找配置找错地方、或者配置文件分散在两处的问题。指定到/etc/ssh后，新版本会直接复用原有配置目录，符合CentOS的习惯。
--with-pam用于启用PAM认证支持。CentOS默认的sshd依赖PAM，如果你不开启，用密码登录时可能会出现“Authentication failure”这类问题，因为系统在账号验证时需要通过PAM栈（比如/etc/pam.d/sshd）来做密码强度校验、账户锁定等策略。所以必须带上。
--with-md5-passwords这个选项和旧系统账号兼容性有关。如果你的系统里存在MD5哈希口令的账号，加了它才能用这些账号正常登录。现代系统基本都用SHA512了，但存量CentOS 6升上来的环境里偶尔会有MD5账号，加上也无妨。
--with-privsep-path=/var/empty/sshd是权限分离功能需要的目录。OpenSSH的sshd在接收连接后会降权到低权限用户运行，这个目录就是这个权限分离机制的“家”。编译和运行时必须保证这个目录存在且权限正确。CentOS 7系统里一般没有这个目录，需要手动创建：
bash复制mkdir -p /var/empty/sshd
chmod 755 /var/empty/sshd
chown root:root /var/empty/sshd
--with-ssl-dir=/usr/lib64是指定OpenSSL库路径。CentOS 7的64位系统上OpenSSL在/usr/lib64。如果你的系统同时装了32位和64位OpenSSL，不指定可能会链接到错误的库。
--with-kerberos5=/usr/lib64是为了启用GSSAPI认证支持。如果你之前用过AD域账号登录服务器（比如通过Kerberos认证），这个选项不能丢。不过需要注意，编译时如果找不到krb5-devel，configure会报错，所以前面才要装krb5-devel。
除了这些，还有个常见的参数是--without-hardening。有些编译环境下，如果编译器版本过老，带硬链接保护编译会失败，加上这个参数可以绕过。CentOS 7默认gcc 4.8编译OpenSSH 10.2p1时我试过，不加也能过，但某些特殊平台（比如内网离线系统用了奇怪版本工具链）可能需要。
3.3 编译安装过程和二进制替换
配置完成之后就是常规的make了：
bash复制make -j4
make install
-j4是并行编译，如果你的CPU核数多可以调大，比如-j8。编译过程大概几分钟到十几分钟不等，取决于机器配置。
编译安装完成后，新二进制在/usr/local/openssh/sbin/sshd。但系统服务目前用的还是/usr/sbin/sshd，所以你需要做个替换。我推荐的方式不是直接覆盖，而是先确认新sshd能正常运行，再做替换：
bash复制# 先测试新sshd能否正常解析配置并启动
/usr/local/openssh/sbin/sshd -t -f /etc/ssh/sshd_config
这个-t参数很关键，是配置语法测试。如果这一行能通过，说明新版本和你的现有配置基本兼容。如果报错，先根据错误信息调整配置，再去替换。
之后用新sshd替换旧的：
bash复制# 停止当前sshd
systemctl stop sshd
# 备份旧二进制（应该已经备份过了，这里再留一个当前文件的副本）
cp /usr/sbin/sshd /usr/sbin/sshd.old
# 复制新二进制到系统路径
cp /usr/local/openssh/sbin/sshd /usr/sbin/sshd
cp /usr/local/openssh/bin/ssh /usr/bin/ssh
cp /usr/local/openssh/bin/scp /usr/bin/scp
cp /usr/local/openssh/bin/sftp /usr/bin/sftp
# 重新加载systemd并启动
systemctl daemon-reload
systemctl start sshd
systemctl status sshd
这里需要说明，为什么我不直接改systemd服务文件指向/usr/local/openssh/sbin/sshd。因为很多第三方安全软件、监控脚本、登录审计组件都硬编码了/usr/sbin/sshd和/usr/bin/ssh路径，你不替换，它们调用的还是旧版。直接替换二进制文件是最省事的，也符合大多数运维的预期。而且以后维护，你不会忘了自己的OpenSSH装在哪。
不过也有人喜欢保留新版在独立目录，用符号链接的方式更新。比如ln -sf /usr/local/openssh/sbin/sshd /usr/sbin/sshd。这样也能工作，但要注意有些加固工具会解除符号链接并替换实体文件，到时候就会产生混乱。我个人的习惯是直接复制实体文件。
3.4 离线内网环境的编译补充方案
热搜词里有人问“麒麟v10gfb内网环境升级openssh”，这说明内网部署是个高频场景。内网环境没有外网yum源，常见的做法是提前准备好所有依赖的rpm包，用yum install --downloadonly在同版本的外网机器上下载，然后传到内网安装。或者更彻底一点，直接在内网搭一个本地yum源。
如果你连rpm包都没有，只有源码包，也没关系。OpenSSH的编译依赖其实就那么几个，重点保证gcc、make、zlib-devel、openssl-devel、pam-devel、krb5-devel这几个包存在。有些内网系统装得很精简，连gcc都没有，那就麻烦了，你得先想办法把基础编译工具链搞定。这属于前期规划的问题，如果你负责的内网系统没有编译环境，平时就要把常用开发工具包囤好。
另外建议编译时把configure参数里的路径统一，避免内网环境的动态库和标准路径不一致。比如有台机器OpenSSL装在/usr/local/ssl，而不是/usr/lib64，这时--with-ssl-dir=/usr/local/ssl就很有必要。
4. 升级后的配置迁移与服务验证
4.1 sshd_config配置项的迁移原则
升级完成、sshd能正常启动之后，最重要的工作就是配置迁移。很多朋友以为把二进制换掉就完事了，其实不对劲。OpenSSH大版本升级后，原有sshd_config里难免会有一些旧参数，比如HostKey路径变了、Ciphers和MACs列表里有些算法在新版不支持了、UsePrivilegeSeparation这个参数在新版本里已经废弃等等。
启动时如果看到类似这样的警告：
code复制/etc/ssh/sshd_config line 123: Deprecated option UsePrivilegeSeparation
这就是配置里有过时参数了。虽然sshd还能起，但你要把这些问题清掉，否则看着难受，也可能和后续的新安全策略冲突。我一般按这样的原则处理：
第一，先对比新旧配置差异。如果升级前你没改过多少配置，可以直接用新版本生成的默认sshd_config做基底，然后把你的自定义项逐个加回去。新版源码包里有sshd_config的样例文件，位置在源码目录下的sshd_config，编译安装后默认配置模板会在/usr/local/openssh/etc/sshd_config。可以直接查看里面的默认值和新增加的内容。
第二，保留必要的本地化设置。比如PermitRootLogin、Port、AllowUsers、DenyUsers、MaxAuthTries这些，是根据业务需求配的，必须保留。要注意的是Port，如果你的防火墙只放行了22端口，新版配置里又改成了默认22，那没问题。如果你原本改了端口，必须在升级后保持一样的端口，否则防火墙放行规则对不上，SSH会直接连不上。
第三，检查算法相关的配置。如果旧配置里手动指定了Ciphers、MACs、KexAlgorithms，升级后很可能有些算法已经不再支持。建议先把这些配置改成注释，让sshd自动使用默认值，等确认连接没问题之后，再根据等保要求一条条加回。
4.2 PAM认证和sshd的交互
PAM是CentOS上SSH密码认证的关键环节。升级后很多人遇到“密码正确但登录失败”的问题，十有八九是PAM配置问题。
新版本的sshd链接PAM的方式和旧版本略有差异。编译时你用了--with-pam，运行时sshd会读取/etc/pam.d/sshd。升级前建议先看看这个文件是否存在、内容是否正常。CentOS 7上这个文件通常在pam包安装时自动生成，升级OpenSSH一般不会动它，但如果文件缺失，密码认证基本就废了。
验证PAM是否正常的简单方法是看/var/log/secure里的日志。如果出现pam_unix(sshd:auth): authentication failure，可以先用sshd -t -f /etc/ssh/sshd_config检查配置，再确认PAM配置。一个稳妥的操作是升级前先备份/etc/pam.d/sshd，升级后如果认证出问题，看看是不是被什么东西覆盖了。
另外有个坑：某些安全策略会在PAM配置里加入pam_tally2（登录失败锁定）模块，升级后如果模块版本和内核不匹配，可能导致认证异常。这类问题排查起来比较费时间，所以升级前检查一下PAM配置里有没有这类特殊模块，如果有，提前确认模块对应版本。
4.3 启动验证与多维度检查
启动sshd之后，验证不能只看systemctl显示active（running）就完事。我建议做这么几件事：
一、确认监听端口。ss -lntp | grep sshd，确认sshd在监听预期端口。有些系统同时跑了多个sshd实例，旧进程没退干净，新进程又顶上来了，这时端口被占、服务起不来的情况很常见。
二、检查版本号。ssh -V，应该输出OpenSSH_10.2p1。再/usr/sbin/sshd -V看一下服务端版本，两者要一致。如果你的PATH环境变量指向了别的路径，ssh命令可能还是旧的，所以要用绝对路径。
三、做一次本地回环连接测试。在当前机器上执行ssh -p 22 root@127.0.0.1，输入密码登录一次。这样可以确认密码认证、PAM、密钥互换全链路没问题。
四、用新会话连接。在跳板机或其他机器上用SSH客户端连接这台服务器，确认远程登录正常。连接成功后，再检查/var/log/secure里有没有认证失败的异常记录。
五、确认配置语法。永远保留一条习惯：改任何sshd配置后，先sshd -t再重载。不要直接systemctl restart，万一语法错了，重启后起不来就只能靠应急通道了。
最后，升级完成后记得把旧二进制保留一段时间。我一般会在服务器上留一个sshd.old，至少保留一个完整发布周期，确认新版本稳定、没出现偶发问题之后再清理。磁盘空间不差这几MB，留着就是买保险。
5. 升级过程中最常见的坑与排查思路
5.1 sshd启动失败的完整排查链路
我把升级OpenSSH时最容易翻车的“sshd启动失败”场景展开讲一下，这个排查思路可以复用到很多地方。
现象：systemctl start sshd之后，服务状态是failed。
第一步：看systemctl status sshd -l。这里-l参数很重要，它会输出完整日志而不截断。如果直接卡住或者只显示几行，看不出问题。
第二步：看journalctl -u sshd。系统日志往往直接给出报错原因。常见的报错有：
sshd: /etc/ssh/sshd_config line 30: Bad configuration option: xxx说明配置里有不被新版本识别的参数。sshd: error: Bind to port 22 failed: Address already in use说明22端口被旧sshd进程占用。sshd: error: Could not load host key: /etc/ssh/ssh_host_rsa_key说明主机密钥丢失，权限不对或者密钥类型不再被支持。
第三步：单独运行/usr/sbin/sshd -t做语法检查。这个命令不会启动服务，只解析配置并报告错误，排查速度很快。
第四步：检查端口冲突。升级时如果停掉旧服务失败、或者替换二进制后直接systemctl start，很可能旧进程还占着22端口。先用ps -ef | grep sshd看有几个sshd在跑，再用ss -lntp | grep :22看端口归属。如果确实有旧进程，kill掉再启动新的。
第五步：检查/etc/ssh目录权限。sshd对配置文件所在目录的权限有严格要求，/etc/ssh目录权限不能太开放，建议755或更严格。如果权限过松，sshd会认为配置不安全，拒绝启动。
5.2 authorized_keys权限导致的登录失败
这个坑在升级OpenSSH后特别容易踩。新版本对用户目录和authorized_keys文件的权限检查更严格，尤其是权限过宽时，sshd会直接拒绝使用该密钥。
典型报错日志：
code复制Authentication refused: bad ownership or modes for directory /root/.ssh
原因就是/root/.ssh目录或/root/.ssh/authorized_keys文件的权限不正确。OpenSSH新版要求用户主目录不能是组写/其他用户可写状态，.ssh目录权限不能超过700，authorized_keys权限不能超过600。
处理方法：
bash复制chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
chown -R root:root /root/.ssh
这个坑对老系统特别隐蔽，因为旧版本可能对权限检查没那么严格，很多老管理员习惯直接chmod 777，升级前一直正常，升级后突然所有密钥登录都失效了。所以升级前把每个需要登录的账号目录权限统一检查一遍，能省掉不少麻烦。
5.3 SELinux和防火墙的双重干扰
CentOS默认开启SELinux，而SELinux对sshd的文件访问有精细控制。升级后如果新sshd二进制文件上下文不正确，即使权限对了、配置对了，依然会启动失败或登录被拒。
常见问题：新复制的/usr/sbin/sshd文件SELinux上下文丢失，变成了usr_t而不是ssh_exec_t。这时候sshd无法正常与系统交互。解决方法有两个：
一是用restorecon恢复上下文：
bash复制restorecon -rv /usr/sbin/sshd /usr/bin/ssh /usr/bin/scp /usr/bin/sftp
二是如果还在频繁开发和调试，临时把SELinux设为permissive模式来排查问题，但生产环境不建议长期关闭SELinux。
防火墙方面，如果系统firewalld是开启的，升级后如果换了端口，必须在firewalld里重新放行。注意，firewalld如果曾对旧的22端口做过富规则（比如限制来源IP），升级后这些规则依然有效，不需要重做。但如果确认规则没问题而连接还是被拒，用firewall-cmd --list-all检查一下。
5.4 旧进程残留与连接断开
升级过程中另一个常见现象是旧连接不断、新连接连不上。原因在于：你停止了sshd服务，但是某个长连接（比如跳板机上的SSH会话）还占着sshd进程，systemd停服务时没有完全杀掉这些子进程，导致端口被占；新sshd起不来，新连接自然进不来。
解决办法很简单：停掉sshd后，检查ps -ef | grep sshd，把残留进程清掉，再启动新服务。实际操作中，我一般这样处理：
bash复制systemctl stop sshd
pkill -f "sshd" # 谨慎使用，确保当前连接断开可以接受
sleep 2
systemctl start sshd
但注意，如果你就是用SSH远程操作这台机器，执行pkill的同时你自己的连接也会断开。所以更推荐的做法是在tmux或screen会话里执行升级操作，让操作会话和网络断开解耦。就算SSH连接闪断，tmux里的服务端进程还在跑，重连后可以继续看状态。
另外升级后某些SSH客户端会缓存旧的host key。连接时如果提示REMOTE HOST IDENTIFICATION HAS CHANGED，说明主机密钥和客户端known_hosts里记录的不一致，删掉老记录重新连接即可：
bash复制ssh-keygen -R [服务器IP]
这不是故障，只是正常的指纹变更提示。但如果你本来就想保留原主机密钥不变，那升级前备份/etc/ssh/ssh_host_*并在升级后恢复回去，可以避免客户端指纹变化。这个根据你业务的敏感度来决定。比如有大量自动化脚本通过IP连接服务器，指纹变更会导致首次连接确认提示，这时保留原密钥会更顺滑。
5.5 升级后SSH登录变慢的排查思路
还有一个很奇怪的现象：升级完OpenSSH，SSH登录变慢了好几秒。排查方向通常是DNS反向解析。新版sshd默认会对客户端IP做DNS反向解析，如果内网DNS解析很慢或者反解失败，连接就会卡顿几秒。
处理方法是在sshd_config里设置：
code复制UseDNS no
这个参数在旧配置里也常见，升级后很多默认配置模板会改成UseDNS yes，所以升级完登录变慢，第一反应就查这个。
另一个导致登录慢的原因是GSSAPIAuthentication。如果你的OpenSSH编译时带了Kerberos支持且sshd_config里GSSAPIAuthentication yes，客户端连接时如果Kerberos域配置异常，会在认证阶段等待超时。对于没有用AD域的内网环境，建议设置：
code复制GSSAPIAuthentication no
这与编译时是否带Kerberos支持无关，纯属sshd_config层面控制。升级后SSH变慢，十次里有八次是这两个参数之一引起的。
老生常谈但每次都要重申的收尾建议
升级过这么多次OpenSSH，我现在养成了一个习惯：不管时间多紧，永远先做备份、永远先开应急通道、永远先在tmux里执行操作。这三个“永远”不是什么高级技巧，但能救命。另外一个建议是，升级完成后不要马上删旧包，至少保留一个完整回滚路径到下一个维护窗口。如果身边有同事也在搞类似环境升级，建议把本机完整走过一遍的rpm依赖清单、configure参数、踩坑记录都留档，下次再处理同类系统会快很多。毕竟OpenSSH升级真正难的，不是那几行编译命令，而是对系统整体状态的把握和意外发生时的恢复预案。