OpenSSH升级实战：从CVE漏洞修复到CentOS/麒麟ARM源码编译

1. 升级OpenSSH前必须想清楚的几件事

1.1 升级OpenSSH的真正原因

做运维的都知道，OpenSSH是Linux服务器上最核心的远程管理通道，它一旦出问题，你连机器都摸不着。但就是这么关键的服务，恰恰是安全公告里的常客，尤其是近几年OpenSSH相关的CVE通报明显变多了。以影响面比较大的CVE-2024-6387为例，这是一个存在于sshd信号处理逻辑中的远程代码执行漏洞，攻击者可以在未认证的情况下利用竞争条件触发内存安全问题，影响范围覆盖了从8.5p1到9.7p1的多个版本。如果你的系统还停留在OpenSSH 7.4或者更老的版本，那基本属于在公网上裸奔的状态。

除了安全因素，合规要求也是升级的硬性驱动力。做过等保测评的朋友应该深有体会，测评项里明确要求服务器SSH协议版本不能过低，很多扫描器也会直接报出“SSH协议版本过旧”的中高危风险项。银行、政企、医疗这些行业对服务器的安全基线卡得非常严，OpenSSH版本是必查项。所以不管你是主动想加固，还是被动迎接检查，升级OpenSSH都是躲不过去的一步。

1.2 升级前必须做的环境盘点

升级OpenSSH不是简单地把新版本装上去就完事，它牵扯到系统底层的SSL库、编译工具链、PAM认证模块、SELinux策略等多个环节。我在动手之前，一般会先把下面的信息摸清楚，宁可多花半小时盘点，也不要在升级过程中手忙脚乱。

第一步，确认系统版本和架构。 输入以下命令，记录下系统的发行版名称、版本号、内核版本和CPU架构：

bash复制cat /etc/os-release
uname -a
uname -m
arch

这里有个很容易忽略的细节：uname -m输出的是当前系统的架构类型，x86_64表示64位x86架构，aarch64表示64位ARM架构。这个参数直接决定你后面下载哪个架构的RPM包或者用什么编译参数，千万别搞错。

第二步，确认当前OpenSSH和OpenSSL的版本。 这两个软件是配套关系，OpenSSH编译时会依赖OpenSSL提供加密算法支持，版本跨度太大会出兼容性问题。

bash复制ssh -V
openssl version
rpm -qa | grep -E 'openssh|openssl'

注意：升级OpenSSH时最好不要随意升级OpenSSL的大版本，除非你有明确需求。OpenSSL升级影响面太大，ldd关联的库会被很多其他程序引用，搞不好就把系统搞坏了。我见过有人为了避免OpenSSH编译依赖问题顺手把OpenSSL升了，结果yum、wget、curl全部罢工，最后只能进单用户模式修复，教训非常惨痛。

第三步，确认编译环境和依赖库。 源码编译方式下，你需要确认系统里有gcc、make、zlib-devel、pam-devel等基础包。CentOS 7默认装的是gcc 4.8.5，编译OpenSSH 9.8p1没有任何问题。银河麒麟V10的编译环境也基本类似，可以先用yum list installed | grep gcc检查一下。如果缺包，优先用系统自带的yum源安装：

bash复制yum install -y gcc make zlib-devel pam-devel openssl-devel

这里多说一句，openssl-devel这个包非常关键。OpenSSH源码编译时如果没有找到OpenSSL的头文件，会自动降级到内部自带的兼容实现，虽然也能编过，但功能上会有损失，所以这个依赖包一定要装上。

第四步，确认远程操作的容错方案。 升级OpenSSH最怕的就是升级到一半ssh连接断了，然后又没有其他登录通道，结果只能干瞪眼。我强烈建议在操作之前先做两件事：

• 检查服务器上是否已经启用了其他远程管理通道，比如带外管理卡（ILO/iDRAC/华为iBMC）、VNC、或者云平台的控制台VNC登录。
• 如果条件允许，开一个screen或者tmux会话，在里面执行升级操作。这样即使网络抖动导致ssh断开，screen会话里的进程也不会被中断，重新登录后还能继续看进度。

另外一个非常实用的土办法：先复制一份sshd二进制和相关配置做备份，同时把当前版本的RPM包缓存下来，这样万一升级失败，可以快速用RPM方式回滚。

2. 不同架构下的升级方案选型

2.1 源码编译安装

源码编译是跨架构场景下最通用的方式，x86和ARM都能用同一套代码编译出对应架构的二进制文件。它的核心优势是自己掌握编译参数，可以选择功能特性，比如是否需要PAM认证、是否需要GSSAPI支持，还能控制安装路径，灵活度最高。

源码编译需要注意的一个问题是编译出来的二进制文件依赖系统里的OpenSSL和Zlib等底层库。如果生产环境的系统版本比较老，底层的OpenSSL版本偏低，而新版本OpenSSH又要求较高版本的OpenSSL，可能会出现编译失败或运行时报错。解决思路一般有两个：要么同步升级系统底层的OpenSSL（风险高，不建议），要么在编译OpenSSH时配合匹配版本的OpenSSL一并编译安装到自定义路径（相对安全但工作量增加）。

对于CentOS 7.9和银河麒麟V10来说，系统自带的OpenSSL版本基本都能满足OpenSSH 9.x的编译要求，所以直接用系统的OpenSSL是首选方案。

2.2 RPM包安装

RPM包的好处是安装卸载方便，系统里rpm数据库有记录，后续升级和卸载都一目了然。但问题在于OpenSSH官方并不直接发布RPM包，你能找到的RPM包大多来自第三方源或者个人维护的仓库，质量参差不齐。在x86架构下，你还能找到一些口碑较好的第三方源，但到了ARM架构下，可用的RPM包就非常稀少了，能找到的基本都是针对特定发行版定制的，兼容性未必有保障。再加上银河麒麟系统的RPM包通常由麒麟官方维护，外部渠道的RPM包装上去可能会和系统自带的配置文件、依赖库冲突，反而不如源码编译来得干净。

我个人的建议是：如果你只是想快速把大版本升级一下，而且能找到与当前系统完全匹配的RPM包，那用RPM包安装也没问题；但如果你的环境包含ARM架构，或者银河麒麟的版本比较特殊，那么源码编译是更稳妥的选择。

2.3 两种方案的对比分析

为了让你快速决策，我把两种方案的关键差异整理成一个对比表格：

从表里能看出来，对于涉及CentOS、银河麒麟、x86和ARM四类混合场景的升级任务，源码编译是覆盖面最广、可控性最强的方案。下面我会以源码编译为主线，把整个实操过程完整拆解给你。

3. 实操记录：源码编译升级全过程（x86与ARM通用）

3.1 准备编译环境与依赖

这一步是把编译所需的工具链和依赖库装齐。前半段已经提到了需要安装的包，这里给出完整的命令，你在CentOS 7.9和银河麒麟V10上都可以直接执行：

bash复制yum install -y gcc gcc-c++ make automake autoconf zlib zlib-devel \
    openssl openssl-devel pam pam-devel perl perl-devel tcp_wrappers-devel

补充说明一下，tcp_wrappers-devel这个包在CentOS 7.6以上的版本可能已经找不到了，找不到就跳过，不影响核心编译。另外，如果需要启用LDAP认证或者GSSAPI认证，还需要额外安装对应的开发包，但常规场景下不需要。

装完依赖后，最好顺手把内核开发头文件也确认一下：

bash复制yum install -y kernel-devel

这个包对于一个普通的OpenSSH编译来说不是必需的，但在编译过程中如果遇到某些与内核模块相关的告警，有它兜底会方便排查。

3.2 下载OpenSSH源码并校验

OpenSSH官方源码包的下载地址是https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/，建议选择当前最新稳定的portable版本。以OpenSSH 9.8p1为例，需要下载两个文件：

bash复制cd /usr/local/src
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.8p1.tar.gz
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.8p1.tar.gz.asc

下载完成后，一定要校验文件的完整性和签名。先看SHA256摘要：

bash复制sha256sum openssh-9.8p1.tar.gz

把输出的哈希值和OpenSSH官网上公布的SHA256值做对比，确认无误后再验证PGP签名。验证签名需要先导入OpenSSH官方发布的签名公钥，过程稍微繁琐，但值得做：

bash复制gpg --keyserver keyserver.ubuntu.com --recv-keys 0x9D4A3C4D
gpg --verify openssh-9.8p1.tar.gz.asc openssh-9.8p1.tar.gz

如果你所在网络环境无法访问外部的keyserver，至少也要做SHA256校验。安全是底线，源码包被篡改的后果比不升级还要严重。

3.3 编译安装的具体步骤

解压源码包：

bash复制tar -zxvf openssh-9.8p1.tar.gz
cd openssh-9.8p1

接下来是配置编译参数。这一步是整个过程中最关键的，参数选错了轻则功能缺失，重则编译失败或者升级后无法开机启动。我这里给出一套经过验证的配置组合：

bash复制./configure --prefix=/usr \
    --sysconfdir=/etc/ssh \
    --with-md5-passwords \
    --with-pam \
    --with-zlib \
    --with-ssl-dir=/usr \
    --with-privsep-path=/var/empty/sshd \
    --with-privsep-user=sshd \
    --with-tcp-wrappers \
    --with-kerberos5=/usr

逐个解释一下关键参数的选择原因：

• --prefix=/usr：把OpenSSH安装到/usr目录下，这样二进制的路径是/usr/bin/ssh、/usr/sbin/sshd，和系统默认路径保持一致。如果你用默认的/usr/local前缀，那么新版二进制会在/usr/local/bin下，旧版本还在/usr/bin下，系统启动脚本会去/usr/sbin里找sshd，导致你升级了半天系统用的还是老版本，这个坑不少人踩过。
• --sysconfdir=/etc/ssh：配置文件路径指向/etc/ssh，和CentOS、麒麟的默认配置目录一致，避免新版本读取不到旧配置导致的异常。
• --with-pam：启用PAM认证支持。生产环境强烈建议开启，不然系统里配置的密码策略、用户锁定等功能会失效。
• --with-ssl-dir=/usr：指定OpenSSL的安装根目录，让编译过程找到系统自带的OpenSSL头文件和库文件。
• --with-privsep-path=/var/empty/sshd和--with-privsep-user=sshd：配置权限分离机制使用的空目录和专用用户。这个机制能把sshd的网络处理部分和特权部分隔离开，即使被攻击也能降低影响范围。
• --with-kerberos5=/usr：启用Kerberos5认证支持，对于需要对接AD域控和Kerberos认证的企业环境很有用。

配置完成后，执行编译：

bash复制make -j$(nproc)

-j参数后面的数字表示并行编译的线程数，$(nproc)会自动获取当前CPU的核心数。在4核的机器上相当于make -j4，8核就是make -j8，能明显缩短编译时间。但要注意，如果服务器的内存比较小（比如只有2GB），并行任务太多可能导致内存耗尽，编译中途直接报错，这时候可以把线程数调低一些，比如make -j2。

编译完成后，先不要急着运行make install，而是保留旧版本的可执行文件作为备份：

bash复制cp /usr/sbin/sshd /usr/sbin/sshd.bak.$(date +%Y%m%d)
cp /usr/bin/ssh /usr/bin/ssh.bak.$(date +%Y%m%d)
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%Y%m%d)

确认备份完成后，执行安装：

bash复制make install

make install会把新版本的文件安装到前面配置指定的路径下。安装完成后立刻检查一下关键文件的版本：

bash复制/usr/sbin/sshd -V
/usr/bin/ssh -V

按我的经验，sshd -V在较新版本中不一定支持直接输出版本号，如果提示参数有误，可以用ssh -V确认版本，或者直接strings /usr/sbin/sshd | grep "OpenSSH_"查看编译时的版本字符串。

3.4 配置文件迁移与服务切换

安装完成后，最重要的就是配置文件处理。新版OpenSSH对配置项的兼容性总体不错，但有些旧配置项在新版本中会被弃用或者修改行为。比如UsePAM参数在新版本中区分度更高了，部分老版本的Ciphers和MACs配置如果太老，新版本sshd会因为不识别而拒绝启动。

我的建议是：不要直接用旧配置启动新sshd，而是先做一次配置语法检查：

bash复制/usr/sbin/sshd -t -f /etc/ssh/sshd_config

如果检查通过，会静默返回；如果配置有问题，会明确提示哪一行出错。这里有一个常见的坑：新版本OpenSSH默认禁用了ssh-dss（DSA）算法，如果你的sshd_config里明确指定了HostKey /etc/ssh/ssh_host_dsa_key，启动时会报警告。处理方法是从配置文件中删除或注释掉该类行。

配置检查通过后，重启sshd服务：

bash复制systemctl restart sshd
systemctl status sshd

重启之后，立即检查sshd进程是否正常运行：

bash复制ps -ef | grep sshd
ss -tlnp | grep 22

然后新开一个终端窗口，尝试用新的连接登录服务器，确认登录正常后再关闭当前这个老会话。这个步骤是为了防止新连接建立不上时，你至少还有一个老会话能救场。

3.5 升级失败时的回退预案

升级失败的情况并不罕见，尤其在配置文件不兼容或者依赖库缺失的时候。如果升级后发现无法登录或者sshd反复重启，先不要慌，按照下面的优先级逐个排查：

第一步，通过主机控制台或带外管理进入系统。 如果云主机，用云厂商提供的VNC登录窗口；如果是物理机，通过ILO/iDRAC/iBMC的控制台登录。这是最可靠的兜底通道。

第二步，确认sshd服务状态。 如果服务起不来，尝试手动启动并且查看详细的错误日志：

bash复制systemctl start sshd
journalctl -u sshd -n 50

第三步，如果确认是新版本兼容问题，执行回退。 把你备份的旧版本二进制文件还原：

bash复制cp /usr/sbin/sshd.bak.20250101 /usr/sbin/sshd
cp /usr/bin/ssh.bak.20250101 /usr/bin/ssh
systemctl restart sshd

这里要提醒一下，cp回去的备份文件属主和权限可能已经变化了，最好顺手修正一下：

bash复制chmod 755 /usr/sbin/sshd
chmod 755 /usr/bin/ssh
chown root:root /usr/sbin/sshd /usr/bin/ssh

回退完成后，再次用新窗口测试登录，确认无碍后再做后续排查。整套升级操作中，“先备份、后替换、留退路”这个思路永远是第一位的。

4. 银河麒麟与CentOS的差异点处理

4.1 银河麒麟系统的特殊之处

银河麒麟V10是很多政务和国企环境里的主力操作系统，虽然它和CentOS在RPM包管理方式上很接近，但实际使用中有几个明显的差异点，处理不好会卡住整个升级流程。

系统来源和软件源差异。 银河麒麟V10分为服务器版和桌面版，两者的软件源配置方式不同，默认软件源里的包版本也和CentOS仓库不完全一致。如果你的环境是内网隔离的，需要先确认是否有可用的本地镜像源；如果是连外网的，注意默认源地址可能指向麒麟官方的仓库，配置文件在/etc/yum.repos.d/下。在升级OpenSSH之前，先执行一遍yum makecache确保软件源可用。

PAM文件差异。 CentOS 7的PAM配置文件是/etc/pam.d/sshd，而银河麒麟V10的PAM配置可能在/etc/pam.d/sshd之外还关联了/etc/pam.d/login等文件。编译OpenSSH时如果启用了PAM，安装后新sshd默认会读取/etc/pam.d/sshd。如果麒麟系统里这个文件的配置和CentOS不同，可能导致密码认证失败。处理的办法是升级后务必在一个新终端中测试密码登录，发现认证失败时，对比/var/log/secure和/var/log/messages里的PAM报错内容，通常需要修改/etc/pam.d/sshd里的pam_stack配置或者调整UsePAM yes的搭配。

SELinux策略差异。 银河麒麟V10默认可能是强制模式（Enforcing），SELinux对sshd的端口监听、文件权限、进程能力都有严格的约束。升级后如果sshd状态显示active but异常，或者客户端连接时提示Connection closed by remote host，需要检查SELinux的AVC拒绝日志：

bash复制ausearch -m avc -ts recent

如果确认是SELinux策略导致的，有两个处理方向：一是精准放行sshd相关的布尔值，比如setsebool -P ssh_sysadm_login on；二是用audit2allow生成并加载自定义策略模块。我不太建议直接setenforce 0，除非你明确知道SELinux在这个环境里本来就没在用。

密钥生成差异。 银河麒麟V10系统里的ssh-keygen版本可能比CentOS 7自带的版本新，生成的默认主机密钥算法可能包含ssh-ed25519。在编译安装OpenSSH 9.x后，这本身不是问题，但如果你后续又把系统回退到老版本OpenSSH，老版本可能不认识Ed25519算法，导致重启后主机密钥读取失败。所以不管是CentOS还是麒麟，升级前都建议保留老版本生成的RSA主机密钥，升级后如果检测到没有合适的HostKey，再手动生成：

bash复制ssh-keygen -t rsa -b 2048 -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key
chmod 600 /etc/ssh/ssh_host_*_key

4.2 ARM架构下的编译注意事项

ARM架构服务器的编译过程和x86有比较大的差别，主要体现在以下几个方面。

编译器指令集差异。 在ARM服务器上编译，系统默认的gcc会生成aarch64指令集的代码，这本身没什么需要特意处理的，编译参数和x86完全一样。但如果你是在x86开发机上做ARM交叉编译，那就要用aarch64-linux-gnu-gcc这一套交叉编译工具链，配置时还要加上--host=aarch64-linux-gnu，这个参数告诉configure脚本目标平台不是本机，它会自动调整对交叉编译的检测逻辑。

性能差异。 ARM服务器的单核性能相比同代x86服务器普遍偏弱，编译OpenSSH这种代码量不算特别大的软件，在x86上大约一两分钟就编完了，在ARM上可能要跑到五六分钟，但OpenSSH的源码体量本身不大，这种时间差距完全在可接受范围内。真正要注意的是别因为觉得ARM慢就减少-j并行数，相反，ARM服务器通常核心数不少（比如鲲鹏920有64核），make -j$(nproc)反而能发挥多核优势。

二进制兼容性。 ARM架构下没有“x86二进制直接跑在ARM上”这种兼容能力，只能通过QEMU用户态模拟或者容器实现有限度的兼容，但性能损失很大。所以如果你在x86机器上编译出了一个静态链接的sshd，想着拷贝到ARM服务器上用，基本行不通。老老实实在目标机器上做本地编译，或者搞一套标准的交叉编译流水线。

4.3 本地编译与交叉编译的实际场景选择

在我处理过的项目里，接触最多的场景是两类：

场景一：目标机器可以联网、有编译环境。 这种情况直接本地编译，简单直接，编译参数不用额外加--host，也不会遇到交叉编译时依赖库路径找不到的问题。

场景二：生产内网环境，不能联网，或者目标机器是低配的ARM板卡，编译太慢。 这种情况就要考虑交叉编译。典型的做法是在一台x86的构建机上安装aarch64-linux-gnu-gcc，提前把所有依赖库（zlib、openssl、pam）的ARM版本都准备好，然后：

bash复制./configure --host=aarch64-linux-gnu \
    --prefix=/usr \
    --sysconfdir=/etc/ssh \
    --with-pam \
    --with-zlib \
    --with-ssl-dir=/usr/aarch64-linux-gnu \
    ...其他参数...
make -j$(nproc)

交叉编译过程中比较容易踩的坑是，configure脚本会去检测/usr/include下的头文件，但那是x86宿主机的头文件，不是ARM目标机的头文件。解决办法是把ARM平台的头文件路径通过CFLAGS=-I/usr/aarch64-linux-gnu/include传进去，库文件路径通过LDFLAGS=-L/usr/aarch64-linux-gnu/lib指定。这个坑不踩一次很难体会，踩过一次之后你就会明白为什么很多人宁愿在ARM机器上本地编译等那几分钟，也不愿意碰交叉编译。

5. 升级过程中典型问题与排查实录

5.1 sshd服务启动失败，错误日志指向libcrypto.so

这是我遇到过频率最高的问题，尤其是升级OpenSSH 9.x版本、而系统里的OpenSSL还是1.0.2老版本的时候。现象是执行systemctl restart sshd后，服务状态是failed，journalctl -u sshd -n 30里能看到类似error while loading shared libraries: libcrypto.so.10: cannot open shared object file的信息。

排查思路是先用ldd /usr/sbin/sshd检查动态库依赖，确认当前sshd链接的是哪个版本的libcrypto。如果系统里同时存在libcrypto.so.10和libcrypto.so.1.1，而新版本sshd需要的是1.1，那么链接器找不到对应库就会报错。解决办法是安装或升级系统的openssl到1.1版本，或者通过设置LD_LIBRARY_PATH临时指定库路径。但LD_LIBRARY_PATH这种方式只适合临时验证，不适合生产环境，因为它会影响所有程序的库加载行为。最稳妥的做法还是把系统的openssl版本对齐到OpenSSH编译时所用的版本。

5.2 升级后root用户无法密码登录

升级完OpenSSH后，很多人会遇到root用户用密码登录直接提示Permission denied，而普通用户却能正常登录。这个问题的根源一般出在/etc/ssh/sshd_config里修改了PermitRootLogin这一项。

新版本OpenSSH默认配置对root登录的限制更严格了，如果你的旧配置里没有显式写上PermitRootLogin yes，从某个版本开始默认值变成了prohibit-password，也就是只允许密钥登录，禁止密码登录。处理方法很简单：

bash复制echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
systemctl restart sshd

这里要权衡一下，如果系统安全基线不允许root直接密码登录，那就保持默认的prohibit-password，用密钥登录更安全。

5.3 客户端连接时提示Unable to negotiate algorithm

这个问题的本质是客户端和服务器端支持的密钥交换算法不一致。老版本系统（比如CentOS 6/7早期的客户端）默认支持的算法集合比较旧，而新版本OpenSSH为了安全考虑默认禁用了部分旧算法（比如diffie-hellman-group1-sha1、ssh-dss），所以客户端发起连接时，服务器上找不到双方共同支持的算法就报错了。

解决办法是在服务器端的sshd_config里显式启用旧算法，但这样会降低安全性。我只建议在内网、低安全等级的测试环境中使用：

bash复制KexAlgorithms +diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
HostKeyAlgorithms +ssh-dss
Ciphers +aes128-cbc,aes256-cbc
MACs +hmac-sha1

改了配置之后记得用sshd -t检查语法，然后重启服务。如果是生产环境，更推荐的做法是升级客户端的OpenSSH版本，而不是降低服务端的安全标准。

5.4 升级后版本号没变，configure和make install都成功了

这个问题多数情况下是安装路径不对导致的。如果你configure时用了默认的--prefix=/usr/local，那么新版本装在/usr/local/bin和/usr/local/sbin下，而系统原有的ssh还是/usr/bin/ssh。因为/usr/bin在PATH里的优先级通常高于/usr/local/bin，你执行ssh -V看到的还是老版本。

处理方法是把安装路径指定为/usr，或者安装后手动把新版本软链到/usr/bin/ssh、/usr/sbin/sshd。另外还要注意，systemd的sshd服务单元文件里调用的是/usr/sbin/sshd，如果你把二进制装到了/usr/local/sbin，服务起的一定是旧版，这个隐蔽问题很容易漏掉。

5.5 升级后系统日志大量刷sshd的错误信息

如果你在/var/log/messages或/var/log/secure里看到error: Could not load host key: /etc/ssh/ssh_host_ed25519_key之类的提示，说明系统缺少对应算法的主机密钥。新版本sshd在启动时会尝试加载它支持的所有主机密钥类型，如果某个算法对应的密钥文件不存在，就会报错并跳过该类型。

解决方法是生成缺失的密钥文件：

bash复制ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key
ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key

生成后修改权限为600，属主为root，然后重启sshd即可。

5.6 常见问题速查表

6. 升级后的验证与加固建议

6.1 升级结果的完整验证流程

升级完成后，不要只看一眼版本号就说“完事了”，我建议你按照下面的清单逐项验证：

版本验证：

bash复制ssh -V
/usr/sbin/sshd -V

进程与监听验证：

bash复制systemctl status sshd
systemctl is-enabled sshd
ss -tlnp | grep 22

登录验证：

在一个新终端窗口里，分别测试以下登录场景：

• 远程IP登录，确认网络通路正常
• 使用普通用户登录，确认PAM认证正常
• 使用root用户密钥登录，确认PermitRootLogin配置生效
• 如果生产环境用跳板机，跳板机登录也要测试一遍

配置完整性验证：

bash复制/usr/sbin/sshd -T | grep -E "permitrootlogin|passwordauthentication|pubkeyauthentication"

sshd -T会输出实际生效的配置全量，让你看到当前sshd真正使用的参数值，而不是注释后的默认值。

6.2 升级后的安全加固建议

既然花力气升级了OpenSSH，不妨借着这个机会把SSH服务的安全基线顺手拾掇一下。这里给出几个高性价比的加固点：

禁用空密码登录。

bash复制PermitEmptyPasswords no

限制密码重试次数和登录超时时间。

bash复制MaxAuthTries 4
LoginGraceTime 30

限制可登录的用户或用户组。 如果服务器只给运维组的人使用，可以显式声明允许登录的用户集合：

bash复制AllowGroups wheel

或者：

bash复制AllowUsers ops01 ops02

合理配置SSH监听地址。 如果业务只需要内网访问，就不要把22端口暴露到所有网卡上：

bash复制ListenAddress 192.168.10.10

开启sftp子系统并限制根目录。 如果服务器上开了SFTP给外部用户上传文件，强烈建议把SFTP用户限制在指定的目录里，防止用户通过SFTP跳到系统其他目录：

bash复制Subsystem sftp internal-sftp
Match Group sftpusers
    ChrootDirectory /data/sftp/%u
    ForceCommand internal-sftp
    X11Forwarding no
    AllowTcpForwarding no

经过这一套调整，SSH服务的安全性会有一个明显的提升。

根据我这几次在CentOS 7.9和银河麒麟V10上处理OpenSSH升级的经验，最想提醒你的一句话是：升级本身不复杂，真正考验人的是对回退方案和异常处理的把握。只要留好备份、理顺依赖、想清楚服务切换顺序，即使中间出了岔子，也能在几分钟内恢复原状。另外，ARM服务器的升级流程跟x86比没有本质区别，但一定记得以目标机器上的实测为准，别被网上那些只针对x86的教程带偏了节奏。希望这份操作记录能帮你少走一些弯路。