CentOS 7 rpm包升级OpenSSH 9.5避坑指南

先说一个我自己踩过的坑。去年做安全整改，巡检报告里CentOS 7自带的OpenSSH 7.4列了一长串CVE，当时图省事，直接官网拉源码包，configure、make、make install一套流程跑下来，ssh连接当场断掉，sshd服务起不来，人在远程差点要跑机房。那次之后我专门花了几天时间，把“用rpm包把OpenSSH从7.4升级到9.5”的流程完整捋了一遍，又在一批测试机上反复验证，现在这套方案已经在几十台服务器上跑过，基本能做到提前可控、出问题能回退。

这篇文章适合几类人看：因为等保或安全扫描必须升级OpenSSH的运维、面对纯内网环境只能离线操作的兄弟、以及被源码编译升级坑过想换一条路的人。内容完全围绕rpm包升级展开，从前期准备、rpm包获取，到正式执行、配置合并、兼容性排查、回退方案都会讲到。我尽量把操作命令、判断逻辑、踩坑点写清楚，照着做能少走不少弯路。

1. 为什么CentOS 7要折腾OpenSSH 9.5，以及为什么非rpm不可

1.1 一次源码编译事故让我彻底放弃了这条路

那天的场景我记得很清楚。系统是CentOS 7.9，原来的openssh是7.4p1，漏洞扫描报告出来一大片，领导要求一周内全部整改。我当时想的是“反正是开源软件，编译安装是最标准的做法”，于是在一台核心业务机器上直接操作，下载openssh-9.5p1.tar.gz，解压、配置、编译，一切正常，到make install那一步就开始出问题——旧的文件被覆盖，新的sshd因为配置文件里有个旧参数解析不通过，直接启动失败。

更要命的是ssh连接已经断了，我已经无法远程执行任何修复命令。唯一能做的只有让机房同事帮忙接显示器进控制台，折腾了快两个小时才恢复。后来复盘，问题不在于源码编译这个方式本身有问题，而是它给运维留下的容错窗口太小：编译产物不在rpm数据库里，升级后无法用rpm命令回退，rpm -qa查到的还是旧版本，时间长了系统里是什么状态完全说不清楚。

那次之后我定了一个原则：生产环境的OpenSSH升级，除非有极其特殊的定制需求，否则一律走rpm包路线。版本可查、依赖可解、出问题可回退，这三条对运维来说比“最新版本”重要得多。

1.2 rpm包方式到底解决了什么核心问题

很多人觉得rpm升级和源码编译升级，最终结果不都是把新版sshd装上去吗？其实差别很大。

第一，rpm包解决的是依赖关系。OpenSSH的rpm包拆成了openssh、openssh-clients、openssh-server三个子包，三个包之间有明确的版本依赖。你执行rpm -Uvh *.rpm时，rpm会一次性处理这三个包，内部按依赖关系自动排序，不会出现“clients已经升到9.5，server还是7.4”这种半吊子状态。源码编译装出来的东西不纳入rpm数据库，系统里新旧文件混杂，yum在后续操作中无法感知，这才是最大的隐性风险。

第二，rpm包解决的是回退路径。只要你在升级前把当前版本的三个rpm包保存好，万一9.5有问题，一条rpm -Uvh --oldpackage就能降级回去。源码编译版本想回退？你得先把旧版本重新编译一遍，还要祈祷编译环境和当初一致，这在紧急故障面前基本不现实。

第三，rpm包解决的是配置文件的演进规则。rpm机制会自动处理/etc/ssh/sshd_config：如果你改过这个文件，升级时它不会直接覆盖，而是生成sshd_config.rpmnew；如果你没改过，新版本配置会正常接管。这个机制虽然第一次遇到时有点绕，但搞清楚之后，配置迁移就是有章可循的，比源码编译直接覆盖要安全得多。

1.3 升级前必须想清楚的三个事实

不要把升级想得太简单，动手之前有几个事实必须先确认。

一是CentOS 7系统自带的openssl是1.0.2k版本，这是系统的底线能力。OpenSSH 9.5官方支持的构建环境比较宽泛，但你在CentOS 7上做升级，一定要确保拿到的rpm包是在CentOS 7环境下编译出来的，而不是从CentOS 8或者Stream仓库里顺手拿的。不同大版本的openssl、pam、zlib、krb5库版本不同，跨版本安装轻则提示依赖缺失，重则连sshd都拉不起来。这是rpm升级里最常见的“水土不服”问题。

二是OpenSSH 9.5对旧算法更严格。默认情况下DSA相关的ssh-dss算法已经完全放弃，老的ssh-rsa签名策略在很多组合下也被禁用。如果你现在还在用DSA公钥做登录认证，或者客户端是比较老的Xshell、SecureCRT版本，升级之后很可能会连不上。这不是故障，是安全策略收紧的必然结果，需要在升级前通知相关使用方，提前把密钥换成ed25519或者做好客户端升级计划。

三是升级过程中不会主动删除或重新生成/etc/ssh/ssh_host_*主机密钥。rpm升级机制会保留原有主机密钥，所以不用担心客户端出现“host key changed”的告警。如果你手痒手动执行了ssh-keygen -A，那就另当别论了，新生成的密钥可能会改变主机的指纹信息，反过来引发安全告警。升级前尽量不要动主机密钥文件。

2. 升级前先做三件事：版本盘点、备份和telnet兜底

2.1 盘点当前环境，摸清三套关键基线

打开一台待升级机器，先不要急着下载任何rpm包，把系统现状摸清楚。我通常用一个命令组合完成初步盘点：

bash复制cat /etc/redhat-release
ssh -V
rpm -qa | grep -E 'openssh|openssl'

输出的信息重点看三个维度：系统是不是CentOS 7.x，小版本是多少；当前openssh是7.4p1还是其他版本；openssl是不是系统默认的1.0.2k。这三项直接决定了你后续应该找什么版本、什么依赖的rpm包。

另外还要检查一下当前sshd配置里有没有非默认的改动。比如你改了Port、PermitRootLogin、AllowUsers这些参数，升级后它们需要重新合并进新配置文件里，如果升级前不做记录，后面只能靠diff慢慢找，非常费劲。我的习惯是顺手导出一份当前生效配置的摘要：

bash复制sshd -T | grep -E '^(port|permitrootlogin|pubkeyauthentication|passwordauthentication|allowusers|denyusers)'

把这串输出存到一个临时文件里，升级完成后作为比对依据。这个动作只需要一分钟，但能省掉后面配置合并时的大量排查时间。

2.2 按“可回退”标准准备备份清单

升级OpenSSH这件事，所有操作都要以“出了问题能回到升级前状态”为底线。所以备份不是随便copy一下文件，而是要按可回退的标准来做。

必备份的内容包括：

• /etc/ssh整个目录，尤其是sshd_config和主机密钥文件。用cp -a保留权限和属性
• /etc/pam.d/sshd，OpenSSH依赖PAM做认证，升级后如果PAM配置不兼容，登录会直接失败
• /usr/lib/systemd/system/sshd.service，如果你之前对这个unit文件做过调优，升级时有被覆盖的风险
• 当前三个openssh rpms的安装包本体。这个上面也说过，回滚时需要用到

具体的备份命令类似这样：

bash复制mkdir -p /data/backup/openssh-upgrade-$(date +%F)
cp -a /etc/ssh /data/backup/openssh-upgrade-$(date +%F)/ssh
cp -a /etc/pam.d/sshd /data/backup/openssh-upgrade-$(date +%F)/pam-sshd
cp -a /usr/lib/systemd/system/sshd.service /data/backup/openssh-upgrade-$(date +%F)/sshd.service

关于“当前三个openssh rpm包本体”怎么保存，这里多说一句。如果机器能联网且配置了base源，可以用yumdownloader直接下旧版本；纯内网机器就要提前在别的地方找好同版本rpm包。最保险的做法是从一台干净的、同小版本的CentOS 7机器上，把rpm包拷贝到内网备用目录。别等到升级失败才开始寻找旧包，内网环境里临时找东西通常都很绝望。

2.3 开一条telnet兜底通道，避免远程失联

这一步很多人嫌麻烦会跳过，但我强烈建议你不要跳。OpenSSH升级过程中，最怕的就是sshd服务起不来，而你又没有任何其他远程入口。如果机器在云上，你还有VNC或管理终端可以用；如果是物理机在IDC，那可能真的要跑一趟机房了。

正确的做法是在升级前临时开启telnet作为兜底通道，等OpenSSH升级验证通过之后再关掉。CentOS 7上开启telnet服务，不是直接启动telnet-server服务，而是启用telnet.socket：

bash复制yum -y install telnet-server telnet
systemctl enable --now telnet.socket
systemctl status telnet.socket
ss -lntp | grep 23

如果服务器有firewalld，需要放行23端口：

bash复制firewall-cmd --permanent --add-port=23/tcp
firewall-cmd --reload

开启后一定要实际telnet登录一次，确认能正常弹出登录提示且密码认证可用，再开始升级。我就见过有人以为telnet准备好了，结果telnet.socket没起来，等升级失败才发现兜底通道压根没开。另外，telnet是明文传输，绝对不能长期开着，OpenSSH升级完成、验证可以正常ssh登录后，第一时间关闭：

bash复制systemctl disable --now telnet.socket

如果安全策略允许，也可以不开telnet，而是先开启一个备用ssh端口，只要sshd服务还挂着旧版就立即生效。但备用端口方案的前提是升级过程中sshd本身不能挂，一旦服务起不来，备用端口同样失效。所以对于生产环境，我仍然倾向于telnet兜底，至少它和sshd进程完全独立。

2.4 确认yum源和基础工具可用

不要忽略环境准备。离线环境里，升级rpm包最怕遇到依赖缺失问题，所以先确认机器当前能用的yum源是什么状态：

bash复制yum repolist

如果可以联网，确保base源和epel源至少有一个能用；如果是内网离线环境，确认已经配置了本地yum源。这里提到本地yum源是因为很多离线机房都有内部镜像，上面放着base和epel的rpm包，提前把源配好能让依赖解决省一半力气。

同时检查rpm、yum、tar这些基础命令是否正常。这个看似多余，但真遇到过排查半天最后发现是基础工具链坏了的情况。基础环境正常，再进入下一步的rpm包准备。

3. rpm包怎么来才稳妥：在线构建、离线拷贝和来源校验

3.1 在线环境下，优先自己打包而不是随便下载

需要明确一点：OpenSSH 9.5不在CentOS 7的官方base仓库里，yum直接装是装不上的。这就引出一个问题：rpm包从哪里来？

市面上有一些运维博客会提供编译好的openssh 9.5 rpm包下载，但我不建议直接在现网服务器上拿来就用。rpm包是root权限安装的软件，来源经过多少人之手、有没有被植入东西，完全不可控，安全问题不能赌。如果你是个人测试环境，自己承担风险没问题；但生产环境必须严谨。

最可靠的来源是自己打包。CentOS 7上打OpenSSH的rpm包，需要用到rpmbuild工具链，以及编译OpenSSH所需的一堆开发库。先安装构建依赖：

bash复制yum -y install rpm-build gcc glibc-devel openssl-devel pam-devel zlib-devel krb5-devel

然后准备openssh-9.5p1.tar.gz源码包，以及对应的spec文件。spec文件可以从开源社区找现成的，我自己常用的是基于Red Hat官方spec改的版本，把Source和Version替换成9.5p1就行。把源码包放到~/rpmbuild/SOURCES，spec文件放到~/rpmbuild/SPECS，然后执行：

bash复制cd ~/rpmbuild/SPECS
rpmbuild -ba openssh.spec

构建过程需要几分钟，顺利的话会在~/rpmbuild/RPMS/x86_64目录下生成三个rpm包，大概长这样：

text复制openssh-9.5p1-1.el7.x86_64.rpm
openssh-clients-9.5p1-1.el7.x86_64.rpm
openssh-server-9.5p1-1.el7.x86_64.rpm

用本机同版本环境打出来的包，依赖基本都能对上，这是最稳的获取路径。需要注意，打包机尽量选一台干净的同小版本CentOS 7，不要在已经装过各种定制包的机器上打包，避免引入了不必要的依赖。

3.2 离线内网环境下，rpm包和依赖要一起准备

纯内网环境没有外网，没法在目标机器上现打rpm，那就需要一台有外网的机器来承担“打包机+下载机”的角色。要求是：这台机器和待升级服务器保持相同的CentOS 7大版本，架构也要一致，x86_64就都用x86_64，ARM架构的机器也不要拿x86_64的包去装。

在有外网的打包机上完成上一小节提到的rpmbuild操作，然后把三个rpm包拷贝到离线传输目录。同时还要检查这三个rpm包对系统库的依赖，用rpm自带命令查看：

bash复制rpm -qpR openssh-server-9.5p1-1.el7.x86_64.rpm

CentOS 7自带的openssl版本是1.0.2k，只要是在CentOS 7上编出来的包，依赖的基本都是系统里已有的库。如果输出里有系统里没有的依赖项，比如某个lib缺失，就用yumdownloader把这几个特定依赖包也下载下来一起带进去：

bash复制yumdownloader --destdir=/data/openssh9.5-rpms --resolve 缺失的包名

把整个rpm目录做成一个tar包，再通过内网传输通道拷到目标机器。拷过去之后不要急着装，先做来源校验。

3.3 对拿到的rpm包做来源与完整性校验

无论包是自己打的还是别人给的，安装前都要做一次校验。完整性校验看的是文件有没有被篡改或损坏，常用SHA256：

bash复制sha256sum *.rpm

如果你是在自己的打包机上产出的包，可以用打包机上当时生成的sha256记录比对；如果是别人给的包，至少要和下载页面的官方校验值核对一下。很多安全事件就是栽在“觉得内网环境很安全”上，内网不等于可信，这个意识要有。

如果rpm包有GPG签名，再做一次签名校验：

bash复制rpm -K *.rpm

没有签名也能装，但有签名且能验证通过，说明包在传输过程中没被改过。对于生产环境，我宁愿多花两分钟做校验，也不愿意在装完之后发现文件损坏、依赖错乱再返工。

4. 正式升级：rpm -Uvh执行顺序与配置合并细节

4.1 执行升级的正确姿势

把三个rpm包放到同一个目录，然后执行：

bash复制cd /data/openssh9.5-rpms
rpm -Uvh *.rpm

需要注意的是-U和-F的区别。-U是升级安装，如果系统里没有旧版，它会直接安装新版；-F是只针对已安装的包做升级，系统里没装过的包它会忽略。在升级OpenSSH三件套时，我统一用-U，因为有的机器可能之前只装了server和clients，没装完整的openssh主包，用-F就有漏装风险。

一次性把三个包放在同一个目录、用一条命令安装，rpm会自动解析内部依赖：clients和server都依赖openssh主包的9.5p1版本，如果它们不在同一次事务里，就会出现“先装clients报依赖找不到，再装主包反而被安装记录搞乱”的问题。分开执行最容易踩这种坑，所以我的建议始终是三个包一起升。

升级过程中如果提示配置文件冲突，rpm会打印详细信息。这里要特别注意，如果之前用源码编译方式装过OpenSSH到/usr/local目录，会导致rpm包里的文件路径和已有文件冲突，rpm会拒绝安装。遇到这种情况，需要先把源码编译版本的文件清理干净再继续，重点检查/usr/local/bin/ssh、/usr/local/sbin/sshd这类路径。不过正常的、没有源码编译历史的机器不会遇到这个问题。如果升级报类似“file /usr/bin/ssh already exists”的错，先确认是不是历史遗留的源码版痕迹。

4.2 sshd_config.rpmnew文件怎么合并才不出事

升级完成后，先看/etc/ssh目录下有没有多出.rpmnew后缀的文件：

bash复制ls -l /etc/ssh/sshd_config*

rpm的行为逻辑是这样的：如果系统原配置文件被管理员修改过，升级时新版配置文件不会直接覆盖你改过的文件，而是把新版本保存为sshd_config.rpmnew。换句话说，升级后运行的还是你的旧配置，而新版本的默认配置躺在.rpmnew里睡大觉。

有.rpmnew文件时，处理步骤要规范。先把当前生效的旧配置备份好，再决定怎么合并：

bash复制cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
diff -u /etc/ssh/sshd_config /etc/ssh/sshd_config.rpmnew

diff输出会告诉你新旧配置文件差异在哪里。通常旧配置里有业务自定义项（Port、AllowUsers、UseDNS之类的），新配置里有新版本需要的算法或默认策略调整。稳妥的做法是把旧配置里的自定义项逐一搬到sshd_config.rpmnew里，然后让.rpmnew转正成为正式配置。执行前想清楚哪些自定义项是必须保留的，别把旧配置里已经废弃的参数也一起带过来。

合并完成后，立刻做语法检查：

bash复制sshd -t

这个命令会告诉你sshd_config里有没有语法错误、参数名是不是拼写错了、依赖的算法是否可用。输出为空或者在退出码0的状态下结束，说明配置能被sshd正确解析。如果输出Bad configuration options，说明配置文件里有当前版本不认识的参数，找到对应行删掉或改成新版本的写法。

配置文件权限也要检查一下。sshd对sshd_config的权限要求是不能被group和其他用户写，否则会拒绝启动。如果合并过程中不小心改了权限，执行：

bash复制chmod 600 /etc/ssh/sshd_config

修改完后重启服务前，先让新配置实际生效，我喜欢用一次restart完成最终切换：

bash复制systemctl restart sshd
systemctl status sshd

status如果显示active (running)，说明服务起来了。然后再开一个新ssh窗口测试登录，确认一切正常再继续。这里提醒一点：千万别关掉当前正在连接的ssh会话，要等新窗口测试通过再关，这是最基本的保命操作。

4.3 权限、SELinux和版本校验

服务起来之后，还要检查几处容易忽略的细节。

主机密钥文件在升级后如果没有被动过，权限一般是没问题的。但如果之前手工处理过，或者从备份目录复制过密钥文件，权限可能就乱了。检查一下：

bash复制ls -l /etc/ssh/ssh_host_*_key*

私钥文件权限应该是600，公钥文件应该是644。如果不对，sshd可能拒绝启动或者客户端连上后提示host key问题，执行：

bash复制chmod 600 /etc/ssh/ssh_host_*_key
chmod 644 /etc/ssh/ssh_host_*_key.pub

如果系统开启了SELinux，尤其是enforcing模式，从备份目录复制回来的文件可能会丢失SELinux上下文，导致sshd无法正常读取配置或密钥。修复上下文比临时关闭SELinux要靠谱得多：

bash复制restorecon -Rv /etc/ssh

最后做版本确认：

bash复制ssh -V

这个命令返回的是OpenSSH客户端的版本。想看服务端实际运行的版本，更直接的方式是看进程或连接日志，但大部分场景下客户端和服务端同属一次升级安装，版本保持一致即可。也可以再执行一下：

bash复制rpm -qa | grep openssh

确认三个包的版本都已经是9.5p1，没有残留旧版本。

5. 升级后必踩的几个兼容性坑与处理办法

5.1 老客户端连不上：算法协商失败的快速定位

升级到9.5后最典型的问题，是某些老版本客户端连接时报错。常见报错大概有这几类：

• no matching key exchange method found. Their offer: diffie-hellman-group14-sha1
• no matching host key type found. Their offer: ssh-rsa
• no matching cipher found. Their offer: aes128-cbc

根本原因就是OpenSSH 9.5默认关闭了一批安全性较弱的密钥交换算法、主机密钥算法、加密算法和MAC算法。如果你的客户端是很多年前的Xshell 5、SecureCRT，或者某些内网老旧采集系统自带的老版本ssh库，它们只支持那些被关闭的算法，握手自然失败。

处理方式是在sshd_config里显式加回一批兼容算法。这里的逻辑不是简单全部放开，而是按需兼容：

bash复制vim /etc/ssh/sshd_config

在文件末尾追加：

text复制HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
KexAlgorithms diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
Ciphers aes128-cbc,aes192-cbc,aes256-cbc
MACs hmac-sha1

然后sshd -t检查语法，再restart sshd。添加完之后，老客户端一般就能连上了。

这里必须说一句大实话：放开旧算法等于削弱安全性，和升级OpenSSH的初衷是有冲突的。正常顺序应该是先推动客户端升级，让客户端支持新算法，然后再升级服务端。但现实环境里总有那么一两台设备动不了，优先级又很高，这时候才用上面的兼容配置，而且要做好记录、明确期限，不建议永久保留。如果安全策略特别严格，就保持默认配置，把连不上的客户端列入遗留清单单独处理。

5.2 证书和公钥登录突然失效的处理链路

升级后如果密码登录正常，但密钥登录失败，不要急着怀疑sshd_config，先看日志：

bash复制journalctl -u sshd -f

或者看/var/log/secure，常见报错是no matching key type或者key_load_public: invalid format。前者属于算法兼容问题，在sshd_config里放开PubkeyAcceptedAlgorithms +ssh-rsa就能解决；后者通常是用户侧的公钥格式太老，服务端解析不了，本质上还是算法策略收紧的连带效果。

如果是DSA公钥，OpenSSH 9.5基本已经不可能支持了。查一下用户侧是不是DSA密钥：

bash复制ssh-keygen -l -f /root/.ssh/authorized_keys

第1列能看到密钥类型，比如ssh-dss就是DSA。如果是DSA，直接给用户重新生成ed25519密钥对：

bash复制ssh-keygen -t ed25519

然后重新配置公钥登录。这个过程要提前通知用户，别等用户发现自己登不上再从零开始。

5.3 GSSAPI和PAM引发的登录慢、登录后被踢

升级到9.5后，有些机器会出现“能登录但特别慢”的现象，或者“输完密码登录成功了，但立即被断开”。这两种情况通常不是OpenSSH本身的bug，而是PAM和GSSAPI相关配置在新旧版本间有细微差别。

登录特别慢，首先检查反向DNS解析。sshd默认开启了UseDNS，如果DNS不稳定，每次连接都会卡在解析上。不依赖DNS的机房环境，直接把UseDNS关掉：

text复制UseDNS no

如果是Kerberos环境，还会涉及GSSAPI。如果机器不依赖GSSAPI做认证，直接关闭：

text复制GSSAPIAuthentication no
GSSAPICleanupCredentials yes

登录后被踢，大概率是PAM配置不兼容。有的旧机器在/etc/pam.d/sshd里写了很老的pam模块调用，新版sshd执行时可能找不到模块或者模块行为变化，认证直接失败。先看日志确认是哪个模块报错，然后对照备份文件做调整。这里我不建议直接照搬新系统的PAM配置，最稳妥的是保留系统原有的/etc/pam.d/sshd，只删掉日志里明确报错的模块行。如果问题还是复现，可以临时把PAM相关的认证方式关掉测试：

text复制UsePAM no

但这是最后手段，正常环境不建议关PAM，会影响密码复杂度控制和账户锁定策略。

5.4 升级失败需要回滚时怎么处理

先明确回滚的前提：升级前保存了旧版本rpm包。如果没有保存旧包，回滚会非常被动，可能只能从备份目录还原文件再手工处理。所以我在前面反复强调，旧版rpm包一定要留好。

回滚的命令格式是：

bash复制rpm -Uvh --oldpackage /data/backup/openssh-upgrade-20241201/openssh-7.4p1-*.rpm

--oldpackage参数允许rpm把高版本降级到低版本，执行后旧版配置文件如果之前备份过，也要一并恢复。回滚完成后务必重启sshd并测试登录，确认服务正常后再关掉telnet兜底通道。

不要用yum remove openssh-server来“卸载重装”。openssh-server被很多系统组件依赖（比如snmpd、smtp等），yum remove会把依赖它的包一起删掉，破坏性远超想象。回滚的正确姿势永远是rpm -Uvh --oldpackage降级，而不是卸载再装。

5.5 非默认端口的SELinux和firewalld坑

如果你的sshd_config里配置了非22端口，升级后还会遇到两个隐蔽问题。

第一个是SELinux。SELinux enforcing模式下，sshd进程默认只允许绑定22端口。如果改了端口，直接restart sshd通常会启动失败，日志里有类似Permission denied的记录。解决办法是给sshd添加端口上下文：

bash复制yum -y install policycoreutils-python
semanage port -a -t ssh_port_t -p tcp 2222

第二个是firewalld。很多人只改了sshd_config的Port，忘了放行新端口，重启sshd后从外面连不上，还以为是OpenSSH升级的问题。升级前就确认好：

bash复制firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --reload

无论是否升级OpenSSH，修改sshd端口后都应该做这两步检查。我见过太多案例是升级成功、服务正常、防火墙没放行，最后误判成升级失败，白白浪费了大量时间。

升级完成后，最后再做一次整体巡检，确认所有安全项正常：

bash复制sshd -T | grep -E 'port|permitrootlogin|pubkeyauthentication|passwordauthentication'
systemctl status sshd
ssh -V

同时确认telnet兜底通道已经关闭，避免留下明文登录入口。

6. 我最后保留的几个操作习惯

超过两年多的OpenSSH升级做下来，我给自己定了几个不成文的规矩，每次执行前都在脑子里过一遍，也算是一条相对完整的收尾经验。

第一，批量升级一定要分批，不要一次性全网操作。哪怕rpm包已经在测试机验证过，也不能保证所有机器配置完全一致。我会先拿一台最不重要的机器试，确认配置合并逻辑没问题，再逐步扩大到核心业务机器。顺序大致是：测试机、非核心业务机、核心机，每批之间留观察时间。

第二，升级前永远保留旧的rpm包和配置文件备份，哪怕这台机器看起来再不起眼。回滚能力是升级操作的最后一道防线，没准备好这道防线，就等于把整个操作的安全性押在了“升级一定成功”这个假设上。这个假设在真实生产环境里太奢侈了。

第三，每次升级后都记录一份配置变更备忘。这次升级了哪个版本、sshd_config合并了哪些参数、开放了哪些兼容算法、什么时候到期，这些信息对后续排查问题非常有帮助。特别是在多人共同维护的环境里，一份清晰的变更记录能避免后来接手的人对着旧配置一头雾水。

最后再分享一个小技巧。升级OpenSSH前如果担心配置合并出错，可以先在测试机上装一遍，人为制造一次sshd_config修改，观察rpm升级时是否会生成.rpmnew，以及合并逻辑是什么样子。这个演练成本很低，但能让你在正式升级时心里有底。毕竟，真正的坑往往不是技术本身，而是没预料到的细节。