简介面向系统运维与安全人员的 CentOS 7.9 OpenSSH 与 SSL 升级加固脚本可解决手动升级易出错、步骤繁杂的问题。脚本将 OpenSSH 升级至 10.0p1、SSL 库升级至 3.5.1并内置禁用空密码登录、关闭 root 远程登录、设置空闲超时等安全加固项以降低服务器被非法访问的风险。压缩包共 4 个文件含 3 个 RPM 安装包与 1 个 Shell 脚本整体约 20.42MB脚本会依次完成系统更新、软件安装、配置调整及加固操作同时提醒用户提前备份配置文件以免丢失自定义设置。已有 140 人学习适合在非生产环境先行测试后用于企业级 CentOS 7.9 服务器的批量升级与安全基线加固。通过执行脚本运维人员不仅能快速部署安全更新还能从脚本步骤中理解升级与加固逻辑为后续自主维护和排错提供参考有效降低升级风险并提升维护效率。1. 安全扫描逼着升级CentOS 7.9 上 OpenSSH 10.0p1 与 OpenSSL 3.5.1 的升级困局CentOS 7.9 自带的 OpenSSH 还停留在 7.4 时代OpenSSL 更是老旧的 1.0.2安全扫描报告里一抓一大把 CVE审计要求直接写死要把 OpenSSH 升到 10.0p1、OpenSSL 升到 3.5.1也就是标题里的 ssh10.0p1 与 ssl3.5.1。我见过太多人在线上直接make install结果后续 yum 更新、依赖回溯、二进制路径混乱一起爆发最后被迫重做系统。这篇文章给你一条更稳的路把两个源码包打成 x86_64 的 RPM用一个脚本完成编译、打包、替换、加固、回滚预案五件事。适合正在做安全审计整改、内网漏洞复扫、以及被扫描报告追着跑的运维和虚拟化环境管理人员。2. 升级前准备确认现状、选 RPM 打包、配齐编译依赖2.1 升级前先确认现状三条命令看清版本与系统不要在连版本都没确认的情况下直接开搞。我见过不少人在别的机器上编好的 rpm 包拿到现场硬装结果因为 glibc 版本不同、PAM 库路径不一致装完 sshd 直接起不来。先跑下面这组命令cat /etc/redhat-release ssh -V 21 openssl version -a rpm -qa | grep -E openssh|openssl第一行确认系统是不是 CentOS 7.9配合uname -m确认 x86_64 架构。第二行会输出当前 OpenSSH 版本和它链接的 OpenSSL 版本CentOS 7.9 常见输出是OpenSSH_7.4p1, OpenSSL 1.0.2k-fips。第三行看 OpenSSL 的编译参数和 OpenSSLDir这决定了升级完成后老库文件要处理到什么程度。最后一行是 rpm 层面的包清单升级前后对比全靠它也可以在被审计问到“你升了什么”时直接拿这份清单说话。这里有一个容易被忽略的判断点确认telnet或带外管理口比如虚拟化平台的 console是通的。因为后面编译替换 OpenSSH 时如果当前 sshd 进程被停掉而你手头只有一条 ssh 会话断连就没法重连了。这个不是可选步骤是升级前必须确认的保底通道。2.2 为什么选 RPM 打包而不是源码直接 make install直接把make install往 /usr/local 里塞升级当时看起来顺利实际上给后续留了三个雷。第一yum 不知道 /usr/local 里发生了什么后续安装任何依赖 openssl 的软件包时yum 会按系统库的依赖去解析不会管你 /usr/local 里的新版本第二回滚时没有版本概念要么手工备份整个目录要么假装没发生过第三动态链接库搜索路径一乱系统原有二进制可能被强制拉去加载新版本库产生一堆 undefined symbol 问题。用 RPM 打包的好处在于升级前后rpm -qa能清楚展示新旧版本回滚有rpm -Uvh --oldpackage这个确定性动作配置文件在 rpm 里的归属也清楚。常见做法是准备一份 spec 文件把源码 tar 包交给 rpmbuild 产出 rpm再在目标机器上rpm -Uvh。这样做还有一个隐性收益如果你在内网有多台同样 CentOS 7.9 的机器打好一个 rpm 可以直接分发不用每台机器都走一遍编译。维度源码 make installRPM 打包升级版本管理无靠手动记录rpm -qa 可查回滚方式手动恢复目录容易漏rpm -Uvh --oldpackage批量分发每台编译慢同一 rpm 批量安装依赖感知不感知rpm 依赖可声明干净卸载基本做不到rpm -e 即可2.3 编译链依赖缺少哪个包都会在 configure 阶段翻车编译 OpenSSL 3.5.1 和 OpenSSH 10.0p1 之前需要先把编译工具链和头文件装齐。这套依赖我在 CentOS 7.9 全新机器上验证过多次缺一个都会在 configure 阶段报错yum install -y gcc gcc-c make perl \ pam-devel zlib-devel krb5-devel \ openssl-devel rpm-build逐个说用途gcc、gcc-c是编译器OpenSSL 3.x 有部分代码需要 C 编译make不必多说perl是 OpenSSL Configure 脚本的依赖少了它 configure 直接退出pam-devel提供 PAM 头文件给 OpenSSH 的--with-pam用zlib-devel让 OpenSSL 和 OpenSSH 都能启用压缩支持krb5-devel对应--with-kerberos5如果系统要接 Kerberos 认证环境就必须装rpm-build提供 rpmbuild 打包命令。selinux-policy-devel在某些环境里编译 sshd 时需要但不是每台机器都默认有可以先装后面编译报缺再加。这里有一个现场最容易踩的坑系统里的openssl-devel对应的是老版本 1.0.2 的头文件编译 OpenSSL 3.5.1 时不要指望它会自动切换。顺序必须是先编译安装 OpenSSL 3.5.1再编译 OpenSSH 10.0p1。如果反过来OpenSSH 的 configure 检测到的是旧头文件和旧库编出来的 sshd 链接的还是老库等于白做一次升级动作。3. 写升级脚本OpenSSL 3.5.1 与 OpenSSH 10.0p1 的编译打包替换3.1 脚本骨架按备份、编译、打包、替换四段组织升级脚本不是把两段编译命令堆在一起就行顺序设计和容错比命令本身更重要。我一般这样组织骨架#!/bin/bash # 升级加固一键脚本OpenSSL 3.5.1 OpenSSH 10.0p1x86_64 set -euo pipefail SSH_VERSION10.0p1 SSL_VERSION3.5.1 WORKDIR/data/build_ssh_ssl BACKUP_DATE$(date %Y%m%d%H%M%S) BACKUP_DIR/data/backup_ssh_ssl_${BACKUP_DATE} mkdir -p $WORKDIR $BACKUP_DIR cd $WORKDIR # 1) 备份配置与现网二进制回滚全靠这份 backup_current() { cp -a /etc/ssh $BACKUP_DIR/ssh_etc cp -a /etc/pam.d/sshd $BACKUP_DIR/pam_sshd || true rpm -qa | grep -E openssh|openssl $BACKUP_DIR/rpm_list.txt echo [OK] 备份完成: $BACKUP_DIR } # 2) 编译 OpenSSL 3.5.1 build_openssl() { tar xf openssl-${SSL_VERSION}.tar.gz cd openssl-${SSL_VERSION} ./config --prefix/usr --openssldir/etc/pki/tls shared zlib make -j$(nproc) make install cd $WORKDIR } # 3) 编译 OpenSSH 10.0p1 build_openssh() { tar xf openssh-${SSH_VERSION}.tar.gz cd openssh-${SSH_VERSION} ./configure --prefix/usr --sysconfdir/etc/ssh \ --with-pam --with-selinux --with-kerberos5 \ --with-md5-passwords --with-privsep-path/var/empty/sshd make -j$(nproc) cd $WORKDIR } backup_current build_openssl build_openssh echo [OK] 源码编译阶段完成下一步进入 rpm 打包重点解释脚本开头的set -euo pipefail-e让脚本在任一步出错时立即退出避免编译失败还继续往后装-u阻止引用未定义变量pipefail让管道命令的失败能正确暴露。很多人不写结果装到一半发现 OpenSSL 没编成功OpenSSH 却已经开始安装了。WORKDIR放在 /data 而不是 /root避免 / 分区被源码包和编译中间产物占满CentOS 7.9 的 / 分区通常只有 50G一次完整编译两个组件会吃掉 2G 以上空间。3.2 OpenSSL 3.5.1 编译参数prefix、shared、openssldir 怎么定OpenSSL 3.5.1 的编译参数我推荐这样写./config --prefix/usr --openssldir/etc/pki/tls shared zlib -Wl,-rpath,/usr/lib64--prefix/usr意味着头文件装到 /usr/include/openssl库文件装到 /usr/lib64这是为了让后续 OpenSSH configure 和系统其他软件能按默认路径找到新库。--openssldir/etc/pki/tls指定 OpenSSL 运行时的证书、私钥、openssl.cnf 目录CentOS 7 上这块原本就在 /etc/pki/tls沿用它可以减少对系统原有证书体系的扰动。shared必须带它生成动态库 libcrypto.so 和 libssl.so不带的话只生成静态库后面 OpenSSH 链接时会很痛苦。zlib启用压缩支持。-Wl,-rpath,/usr/lib64是给运行时动态链接器一个搜索路径避免出现明明库装了但加载时找不到的情况。编译过程的输出要看两处./config结束时的 Summary它会列出安装路径、cipher 支持情况make结束后的 exit code。建议把 make 输出重定向到日志文件比如make -j$(nproc) /data/build_ssl.log 21出问题时直接看日志尾部比翻屏幕可靠。我遇到过 make 进行到一半因为内存不足被 kill日志尾部会看到 Killed这时把-j$(nproc)改成-j2再跑。注意此时系统里旧 OpenSSL 1.0.2 的库文件还在新库 soname 是 libcrypto.so.3老库是 libcrypto.so.10。两者并存不会互相覆盖。真正的风险不在安装这一步而在于之后编译 OpenSSH 时 configure 检测到的 openssl 版本是否已经是 3.5.1用openssl version确认一下看到 3.5.1 再继续。3.3 OpenSSH 10.0p1 编译参数PAM、SELinux、Kerberos 一个不能少OpenSSH 10.0p1 的 configure 参数直接决定 sshd 在 CentOS 7.9 上能不能融入系统认证体系。我用的参数组合是./configure --prefix/usr --sysconfdir/etc/ssh \ --with-pam --with-selinux --with-kerberos5 \ --with-md5-passwords --with-privsep-path/var/empty/sshd--sysconfdir/etc/ssh指定配置文件目录这是 CentOS 的惯例路径装完直接覆盖系统原来的 /etc/ssh/sshd_config省得再拷。--with-pam让 sshd 走 PAM 认证和系统账号的密码策略、锁定策略衔接上不启用的话会出现密码正确也登不上、或者登上了没有 session 的情况。--with-selinux让 sshd 带 SELinux 支持CentOS 7 默认 enforcing 模式下少了这个 flag 的 sshd 很可能起服务正常但登录后被 SELinux 拦截。--with-kerberos5如果内网环境接 Kerberos 域建议加上避免二次编译。--with-privsep-path/var/empty/sshd是权限分离进程的工作目录需要提前建好并设置权限脚本里要加mkdir -p /var/empty/sshd chown root:root /var/empty/sshd chmod 755 /var/empty/sshd。--with-md5-passwords是为了兼容系统里还在用 MD5 密码散列的老账户如果你的环境早已切到 SHA512这个参数可以不启用。我这里保留它是考虑 CentOS 7.9 升级场景里总有几个历史账户开着保险。编译完成后先make -j2再make install然后立刻ssh -V确认版本变成 10.0p1。这个动作建议直接写进脚本因为不少人 configure 跑完就以为装好了实际 sshd 还是老版本。3.4 生成 RPM 而不是直接 make install用 rpmbuild 完成打包第 2 章我们定了走 RPM 路线这里实际操作时我习惯先按上面的命令把源码编一遍确认没问题再写 spec 文件用 rpmbuild 打包。spec 的核心字段如下Name: openssh Version: 10.0p1 Release: 1.el7.x86_64 Summary: OpenSSH for CentOS 7.9 security hardening License: BSD Requires: pam, krb5-libs, zlib, openssl %description OpenSSH 10.0p1 rebuilt for security scan remediation. %prep %setup -q -n openssh-10.0p1 %build ./configure --prefix/usr --sysconfdir/etc/ssh \ --with-pam --with-selinux --with-kerberos5 \ --with-md5-passwords --with-privsep-path/var/empty/sshd make -j2 %install make install DESTDIR%{buildroot} %files /usr/sbin/sshd /usr/bin/ssh /usr/bin/scp /usr/bin/sftp /usr/bin/ssh-keygenRequires行要按实际依赖写全特别是openssl这样 rpm 安装时会先确认系统里的 OpenSSL 版本满足要求。%build阶段的 configure 参数和前面手工编译完全一致避免打出来的包行为和手工编译不一致。%files列表要覆盖 ssh、scp、sftp、sshd、ssh-keygen 这些二进制文件漏掉的话装完会发现命令在但行为异常。OpenSSL 3.5.1 的 spec 也是同样套路但它的%post脚本段一定要加ldconfig确保动态链接器缓存更新否则老服务可能因为缓存未更新而加载不到新库。打包命令和执行替换rpmbuild -bb /data/build_ssh_ssl/openssh.spec rpm -Uvh /root/rpmbuild/RPMS/x86_64/openssh-10.0p1-1.el7.x86_64.rpm rpm -Uvh /root/rpmbuild/RPMS/x86_64/openssl-3.5.1-1.el7.x86_64.rpm注意执行顺序先装 OpenSSL 3.5.1 再装 OpenSSH 10.0p1。两个包都用-Uvh而不是-ivh因为-U表示升级能处理旧版本残留的配置和文件。装完立刻检查rpm -qa | grep -E openssh|openssl确认两个新版本都在。这里提醒一句OpenSSL 的 rpm 包替换的是系统级库文件安装过程一旦中断系统可能进入库文件不完整的状态所以生产环境务必配合第 5 章的保底通道操作。4. 加固部分sshd_config、PAM、systemd 三项一起改4.1 sshd_config 里必改的 8 个加固项升级版本只是第一步扫描报告里那些弱加密算法、允许 root 密码登录、空闲会话不断开之类的条目要靠 sshd_config 才能消掉。我每次升级后都会按下面这张表过一遍配置项推荐值作用Protocol2禁用老旧的协议 1PermitRootLoginno禁止 root 直接 ssh 登录PasswordAuthenticationno禁用密码登录走密钥PubkeyAuthenticationyes显式开启公钥认证MaxAuthTries3登录尝试次数上限ClientAliveInterval300空闲 300 秒探活ClientAliveCountMax2探活失败 2 次即断开LoginGraceTime30登录超时 30 秒实际操作时修改 /etc/ssh/sshd_config 前先备份然后用 sed 精确替换而不是手写整个文件防止把默认配置里其他重要项弄丢cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak sed -i s/^#\?PermitRootLogin.*/PermitRootLogin no/ /etc/ssh/sshd_config sed -i s/^#\?PasswordAuthentication.*/PasswordAuthentication no/ /etc/ssh/sshd_config sed -i s/^#\?MaxAuthTries.*/MaxAuthTries 3/ /etc/ssh/sshd_config sed -i s/^#\?ClientAliveInterval.*/ClientAliveInterval 300/ /etc/ssh/sshd_config注意一个致命细节PasswordAuthentication 改成 no 之前先确认至少有一个可用的公钥已经写进对应账号的 authorized_keys否则你把自己关在门外只能走 console。更稳妥的做法是先加一个临时的 AllowUsers 白名单等所有账号的公钥都验证通过后再收紧。Ciphers 和 MACs 如果安全扫描要求弱加密算法全部禁用可以在配置里显式写一套强算法列表但注意 OpenSSH 10.0p1 编译时如果带了老算法支持列表写太短可能导致老客户端连不上内网有旧版 Windows 客户端时尤其明显。我的原则是先保证业务能连再逐步收紧算法别在升级当天把算法列表锁死。4.2 PAM 与 systemd 侧登录策略和启动约束sshd 的 PAM 配置路径是 /etc/pam.d/sshd。升级安装时make install 不会主动覆盖它但如果你的脚本里用了rpm -Uvh --force且打包时把 /etc/pam.d/sshd 也纳入了 %files那么系统里这份文件可能被打包测试机的配置覆盖。所以升级后要检查一下cat /etc/pam.d/sshd重点看有没有auth required pam_securetty.so、session required pam_limits.so、session optional pam_motd.so这几行。CentOS 7.9 默认还依赖pam_systemd.so来注册用户 session缺失会导致登录后 systemd 用户实例不完整表象是 ssh 能连上但systemctl --user不可用journal 里报错。如果发现文件被覆盖把备份还原回去然后systemctl restart sshd。systemd 侧要确认 sshd.service 的启动约束和依赖正常systemctl daemon-reload systemctl enable sshd systemctl start sshd systemctl status sshd --no-pager这里有一件很多人忽略的事CentOS 7.9 的 sshd.service 里有ExecStart/usr/sbin/sshd -D如果升级后 sshd 二进制路径变了比如 configure 时用了非 /usr 前缀service 文件里的路径就要同步修改否则systemctl start sshd报 Executable path 不存在。用脚本升级时建议在脚本里加一段 sed 修正 service 文件路径或者 configure 时坚持用 /usr 前缀这样省了这一步。4.3 升级后自检sshd -t、端口监听、算法列表一次查完很多人在升级完的当口只ssh -V看一下版本号这是最浅的自检。我会按顺序跑下面这组命令sshd -t systemctl restart sshd ss -lntp | grep :22 ssh -Q cipher ssh -Q mac ssh -Q kexsshd -t是最快但也最容易骗过人的检查它只校验配置语法不校验运行时权限和 SELinux所以它通过不代表 sshd 能正常起。重启后再ss -lntp确认 sshd 进程确实监听 22 端口这一步能过滤掉配置检查通过但起服务失败的场景。三个-Q分别列出当前版本支持的加密算法、MAC 算法和密钥交换算法对比扫描报告要求的禁用列表看是否还有残留弱算法。如果某个算法还在需要在 sshd_config 里用 Ciphers、MACs、KexAlgorithms 三个指令显式关闭。算法的自检一定要在业务接入前做等业务上线后再改算法会有一堆老客户端来问你怎么连不上。5. 升级加固避坑指南五个最常见的现场翻车与排查方法把升级加固脚本放到生产环境总会撞上文档没写的现场问题。下面五条是我在不同环境里反复遇到过的按现象、原因、解决三段式写方便你排查时直接对照。5.1 坑 1远程会话中断机器直接失联现象通过 ssh 执行升级脚本脚本跑到替换 rpm 那一步当前会话卡死或断开再尝试 ssh 连接没有任何响应只能通过带外管理口进去。原因脚本在同一个 ssh 会话内执行 rpm 替换时旧 openssh 包被卸载当前 sshd 进程被杀另一个更隐蔽的原因是 rpm 安装新包时 /etc/ssh 下的 host key 被重新生成旧连接不感知新连接因为 host key 变化被客户端拒绝连接。解决升级前先开一个不依赖 ssh 的保底通道比如虚拟化平台的 console 或 telnet。脚本内部做两步保护第一步用 nohup 加延时执行替换动作第二步在替换前把 host key 和整个 /etc/ssh 目录备份到 /data。在替换 rpm 之前加一段延时echo 警告60 秒后将替换 sshd请确认保底通道可用 sleep 60这 60 秒是留给你观察脚本输出的缓冲时间如果发现前面编译日志有异常直接 CtrlC 终止避免带着错误进入替换阶段。5.2 坑 2密码正确但 PAM 拒绝登录现象升级完 OpenSSH 10.0p1 后使用密码认证登录输入正确密码立刻被断开日志显示pam_unix(sshd:auth): authentication failure用 console 却能正常登录。原因打包时把 /etc/pam.d/sshd 也打进了 rpm安装时覆盖了系统原有 PAM 配置或者编译 OpenSSH 时没有启用 --with-pamsshd 自带的认证路径和系统 PAM 规则不匹配。解决先用 console 登录把备份的 /etc/pam.d/sshd 还原如果没有备份从同版本 CentOS 7.9 另一台机器拷贝一份过来修改后systemctl restart sshd。如果是编译参数缺 --with-pam退还源码重新 configure。判断小技巧tail -50 /var/log/secure看认证失败发生在 pam_unix 还是 pam_sss如果根本没走到 pam_sss大概率是 PAM 通道没接上。这个问题在批量分发场景特别容易出因为打包机上的 pam 配置和生产机有差异统一做法是把 pam 文件排除在 rpm %files 之外。5.3 坑 3httpd 等服务起不来ldd 报缺库现象升级 OpenSSL 3.5.1 后系统里依赖 libcrypto 的原有服务比如 httpd、nginx、vsftpd重启时报error while loading shared libraries: libcrypto.so.10或者直接 segfault。原因OpenSSL 1.0.2 的动态库 soname 是 libcrypto.so.103.5.1 的是 libcrypto.so.3。老服务二进制按老 soname 链接新 OpenSSL 不提供 libcrypto.so.10。这是 soname 兼容中断不是简单软链能解决的。解决常见做法是保留老库文件但不在默认路径或者用容器运行老依赖服务。升级前先拉一次依赖清单知道哪些服务会被影响lsof | grep libcrypto | awk {print $1} | sort -u如果这类服务不多直接重编如果很多建议临时把老版本 OpenSSL 的库文件保留在 /usr/lib64 下并做好标记等所有业务迁移完成后再清理。不要图省事做ln -s libcrypto.so.3 libcrypto.so.10糊弄完一会还会出现符号缺失危害更大。这个坑是 OpenSSL 大版本升级特有的升级前心里要有数。5.4 坑 4yum update 把 OpenSSL 拉回老版本现象升级完成几天后某次 yum update 依赖解析时系统提示需要 openssl-libs 1.0.2k并自动把它装回来sshd 重新链接到老库扫描报告里的漏洞又回来了。原因CentOS 7.9 的 yum 仓库里所有 rpm 的依赖都指向 openssl-libs 1.0.2你手工编译装的 OpenSSL 3.5.1 不在 rpm 数据库的依赖链里。yum update 解析依赖时发现升级项不满足老依赖就顺手把老版本带回来。解决在 /etc/yum.conf 的 [main] 段加 exclude或者在执行 yum 命令时带 --exclude 参数echo excludeopenssl* openssh* /etc/yum.conf这条只影响 yum 自动更新不影响手动安装业务软件。建议同时把两个 rpm 包名记进升级报告避免下一个同事看到这里的 exclude 不知道是谁加的排查问题时把系统状态搞乱。另外一个相关动作升级后的一周内不要执行大范围yum update至少让新 sshd 稳定跑过观察期。5.5 坑 5sshd 起不来、配置检查却通过现象升级后执行sshd -t显示配置没有语法错误但systemctl start sshd起不来journal 和 /var/log/secure 都没有明确错误只有Failed to start OpenSSH server daemon。原因大概率是 SELinux 文件上下文问题。新编译的 sshd 二进制放在 /usr/sbin/sshd如果是从源码目录直接复制出来的文件 context 可能是 user_home_t 或 var_t不是 sshd_exec_t/var/empty/sshd 的 context 也可能不对。SELinux enforcing 模式下sshd 启动访问这些路径会被拦截但日志经常只在 audit 里记录。解决先临时setenforce 0验证是不是 SELinux如果是恢复 contextrestorecon -v /usr/sbin/sshd /var/empty/sshd /etc/ssh/ssh_host_ecdsa_key如果 restorecon 解决不了用matchpathcon /usr/sbin/sshd查看期望 context再用chcon修正。这一步要写进升级脚本安装完成、重启服务前先把这几个路径的 context 恢复一遍能省大量排查时间。6. 脚本化与回滚把升级动作固化成可复用流程6.1 参数化脚本版本号、架构、备份路径从外部传入把第 3 章的硬编码版本改成参数脚本就能在不同 CentOS 7.9 x86_64 机器上复用#!/bin/bash SSH_VER${1:-10.0p1} SSL_VER${2:-3.5.1} ARCH${3:-x86_64} RPM_DIR/data/rpm_${SSH_VER}_${SSL_VER}用默认值的好处是平时直接执行脚本就能跑特殊场景需要固定版本时再覆盖。我把这套流程做成了两个子命令--build只负责编译打包--install只负责安装加固。在批量分发场景里编译只在跳板机做一次其他机器只跑安装和加固避免每台机器重复编译。这个拆分在十几台机器的内网环境里能省大量时间。参数化还有一个好处升级报告可以直接把版本参数写进文件名留档时一眼看出每台机器升到了什么版本。6.2 回滚方案保留旧 rpm 才是后悔药升级脚本的最后一节应该是回滚说明。最可靠的回滚动作是升级前把两个旧 rpm 包保存到固定目录需要回滚时用rpm -Uvh --oldpackage装回去rpm -Uvh --oldpackage openssh-7.4p1-1.el7.x86_64.rpm rpm -Uvh --oldpackage openssl-1.0.2k-16.el7.x86_64.rpm--oldpackage参数允许用更低版本替换当前版本是 rpm 的官方回滚入口。注意回滚后要重新执行一次restorecon -v /usr/sbin/sshd因为旧二进制和配置文件的 SELinux context 同样需要修正还要检查 /etc/ssh/sshd_config 是否被旧包覆盖如果覆盖了用第 4 章的备份恢复。整个升级加固流程我建议你在同版本虚拟机里完整跑一遍再删掉新包回滚一次把回滚流程当升级流程一样验证。说一点个人经验某次我在模拟项目X环境里升级完后没有立刻验证一个老业务系统的连接结果第二天业务就报障排查到是 OpenSSL soname 变化导致那个系统加载的底层库不一致。从那以后我养成了一个习惯升级后的一周里每天看一眼系统日志中与 crypto、ssh、SELinux 相关的报错并且把升级前后的 rpm -qa 输出、sshd 配置、SELinux context 都留在升级报告里。升级加固这件事做到能顺利装完只是及格做到能快速回滚、能解释每一步变化才算对生产环境有交代。希望帮到你。本文还有配套的精品资源点击获取
