企业官网建设流程全解析

简介：针对国产麒麟操作系统及 CentOS 的运维与安全管理人员，这份资源提供了一套离线环境下的 OpenSSH 一键升级方案。在无互联网连接的服务器或内网环境中，用户无需手动下载更新包和逐一处理依赖，直接执行脚本即可完成 OpenSSL、OpenSSH、zlib 等核心组件的版本升级，修复已知漏洞并降低操作失误。整个资源包以 rar 格式封装，仅含 4 个文件，以 3 个 gz 源码压缩包和 1 个 sh 执行脚本为主，总大小约 20.04MB，结构紧凑、便于传输和分发；gz 包提供编译安装所需源码，sh 脚本负责自动完成解压、配置与安装流程。其中 OpenSSL 3.2.0 与 OpenSSH 9.7p1 属于较新版本，zlib 1.3.1 用于压缩数据支持，脚本封装了复杂的编译和替换流程，降低了运维人员手工操作的门槛。目前已有 2090 人学习下载，对于需要批量维护国产化服务器的团队来说，能有效节省升级时间、提升系统安全性。

1. 离线升级 OpenSSH：别把内网服务器升级成“黑匣子”

一次内网漏洞扫描把同事吓够呛：几十台国产服务器操作系统的 OpenSSH 版本还停在好几年前的版本，扫描报告一行行高危。想升级，机器在隔离网段，外网源不通，包也下载不了；就算拷进去，直接rpm -Uvh又经常翻车——不是缺 openssl-libs，就是 sshd 起不来，连远程都断掉。这套“离线一键升级 OpenSSH 版本以及相关文件”的资源，就是把二进制包、依赖包、备份逻辑和一键脚本打包在一起：解压后跑一个脚本，先备份配置和密钥，再按依赖顺序替换主包，最后校验服务状态。它适合内网服务器、没有外网源的场景，也适合刚接手国产系统、不想被依赖关系折磨的运维新人。下面我从原理到参数、从坑到验证完整拆一遍。

2. 先把原理说清楚：为什么“离线一键升级”不是简单 rpm -Uvh

2.1 生态基础：目标系统不是 Debian，是 rpm/dnf 家族

很多国产服务器操作系统虽然界面、文档各有差异，但底层包管理是同一套基因：采用 rpm 包格式，使用 yum/dnf 做依赖解析，服务管理走 systemd。这意味着你从网上看到的以apt-get升级 OpenSSH 的教程在这里完全不适用，拿到.deb包也装不进去。确认这一点之后，升级路径就很清晰：找对应架构的.rpm包，用rpm命令离线安装。

为什么不用源码编译？这是一个会反复纠结的问题。源码编译看起来“干净”，但 OpenSSH 要和系统里的 PAM、SELinux、Kerberos 打交道，源码包默认配置经常少编译选项，装上后要么 PAM 认证失败，要么日志里看不到登录记录；而且编译产物不在 rpm 数据库里，以后rpm -qa查不到，回滚全靠覆盖二进制，非常被动。离线 rpm 包升级虽然要处理依赖，但装完之后所有文件都在包管理器的视野里，rpm -V可以校验，以后想降级也有依据。我在生产环境里基本只走 rpm 路线，源码编译只适合在测试环境做验证。

另外要注意，这套包管理体系和社区企业 Linux 的版本世代强相关。目标系统如果老一点，仓库默认带的 OpenSSH 版本会明显落后，但系统库比如 openssl-libs、zlib 的版本也被锁在同一个世代。升级 OpenSSH 时，尽量选同一世代工具链编译出的二进制包，而不是无脑拿一个大版本高很多的包硬塞进去，否则后面会遇到动态库不匹配的问题。

2.2 依赖关系：OpenSSH 不是孤立软件包

离线升级最容易踩的第一个坑，是“我只替换 openssh-server 就行”。OpenSSH 是拆成多个包分发的：openssh（公共文件）、openssh-clients（ssh、scp、sftp 客户端）、openssh-server（sshd 服务端）。它们彼此之间有版本配套要求，最好一起升级，否则可能会出现ssh是新的、sshd是旧的，两边密钥交换算法不匹配之类的问题。

更关键的是动态库依赖。新版 OpenSSH 编译时会链接系统里的 openssl-libs，依赖其提供libcrypto.so和libssl.so；还会依赖zlib做压缩，依赖pam做账号认证，部分新版本还引入了libfido2用于 U2F/FIDO 硬件密钥。如果只把三个 openssh 主包装上去，系统里的 openssl-libs 版本低于编译要求，服务会在启动时报类似error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file的错。这个错开机时才会暴露，等远程连不上就晚了。

所以一份靠谱的离线包，目录里绝不只放 openssh 主包，还会带上匹配版本的openssl-libs、zlib、pam等。你可以用下面的命令在升级前先看清依赖关系：

cd /root/offline_upgrade/rpm_packages rpm -qpR openssh-server-8*.x86_64.rpm

输出里会列出一串Requires，例如libcrypto.so.64()、libssl.so、pam >= 1.1.8、zlib。它告诉你新 OpenSSH 对底层库的“最低版本要求”。如果本地系统已有的包满足这些要求，就不需要额外升级依赖；如果不满足，脚本会把openssl-libs、zlib一并替换。注意：依赖包不是越新越好，而是“满足要求且不破坏其他组件”的版本。openssl-libs 一旦跨大版本替换，影响面会波及 curl、nginx、数据库客户端等一堆程序，因此离线包里的依赖包版本选择要克制。

2.3 升级前必须做的三件事：备份、自启、逃生通道

我拆过的升级脚本里，第一步永远不是安装，而是备份。备份范围包括：

• /etc/ssh整个目录：里面有sshd_config、ssh_config、主机密钥ssh_host_*_key，以及authorized_keys；
• 当前已安装的相关包版本清单；
• sshd -T输出的实际生效配置。

主机密钥尤其重要。如果升级过程中把/etc/ssh/ssh_host_rsa_key重新生成，所有老客户端的 known_hosts 都会报警，甚至因为StrictHostKeyChecking=yes直接拒绝连接。所以脚本里必须保留原有主机密钥，不能顺手删掉。下面这段环境检查与备份脚本，是升级前的标准动作：

set -euo pipefail BACKUP_DIR=/opt/ssh_upgrade_backup mkdir -p "$BACKUP_DIR"/etc # 保留整个 /etc/ssh，保留权限属性 cp -a /etc/ssh "$BACKUP_DIR"/etc/ # 记录升级前相关包版本，回滚时对照用 rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' \ | grep -Ei '^(openssh|openssl-libs|zlib|pam)' \ | tee "$BACKUP_DIR"/rpm-list.txt # 查看 sshd 是否开机自启 systemctl is-enabled sshd || chkconfig --list sshd # 导出当前有效配置，升级后 diff sshd -T > "$BACKUP_DIR"/sshd-config-effective.txt echo "backup done: $BACKUP_DIR"

解释几个参数：cp -a比cp -r更安全，它会保留文件权限、属主和时间戳；rpm -qa --qf是自定义输出格式，把包名、版本、架构打全，后面如果要对账，一份全量清单能省很多事；sshd -T表示只读取配置并输出最终生效值，不会真正启动服务，导出这份文件后，升级完就可以用diff快速看出哪些行为被改变了。

最后是逃生通道。生产环境升级 sshd，永远不要把“当前这条 SSH 连接”当成唯一救命绳。做任何操作前，先确认机器有带外管理控制台可用（比如远程管理卡、物理串口、本地显示器）。如果没有，至少用tmux或screen包一层会话，防止网络抖动把脚本和 sshd 重启之间的窗口卡掉。我吃过这个亏：当时图省事，直接在登录 shell 里执行升级脚本，脚本跑到systemctl restart sshd，当前连接瞬间被掐断，然后 sshd 起不来，最后只能跑到机房处理。

3. 离线安装包怎么选：版本配比、架构识别与本地依赖校验

3.1 先确认架构：x86_64 与 aarch64 不能混用

下载离线 rpms 前，第一件事是看机器架构。国产服务器操作系统的部署面很广，x86_64 是常见形态，ARM 平台（aarch64）也越来越多。同名版本号的 rpm，x86_64 和 aarch64 是两个不同的二进制文件，不能互相安装。noarch包不区分架构，但 openssh 这类带编译产物的包几乎总是按架构分发。

uname -m

输出x86_64就下载 x86_64 的包，输出aarch64就下载 aarch64 的包。还有一个小技巧，用系统自带的 rpm 数据库验证当前架构：

rpm -qa --qf '%{NAME} %{ARCH}\n' | grep '^openssh' || true

如果机器上已经装过 openssh，这条命令会输出类似openssh-server x86_64。这里的架构在升级时也要保持一致，否则文件会装到错误的位置，出现“明明安装了，但 sshd 起不来”的怪现象。

3.2 离线包目录应该长什么样

一个逻辑清晰的离线包压缩包，解压后通常是这样的目录结构：

offline_upgrade/ ├── upgrade_openssh_offline.sh ├── rpm_packages/ │ ├── openssh-8.x-x.x86_64.rpm │ ├── openssh-clients-8.x-x.x86_64.rpm │ ├── openssh-server-8.x-x.x86_64.rpm │ ├── openssl-libs-1.1.1q-x.x86_64.rpm │ ├── zlib-1.2.11-x.x86_64.rpm │ └── pam-1.3.1-x.x86_64.rpm ├── backup/ └── README.md

这里有三个细节值得注意。第一，目录里不应该有src.rpm源码包，那不能直接用rpm -Uvh安装，混在目录里还会让批量安装报错。第二，backup/目录在第一次执行前是空的，脚本会往这里写备份；如果你把解压后的包放在只读文件系统上，脚本要能切换到其他可写路径，所以脚本的参数里必须有--backup-dir。第三，README.md里通常会写明这批 rpm 是在哪个系统版本上编的，这个信息很关键，决定依赖包是否配套。不同小版本的系统，glibc 版本不同，如果二进制包是在更高版本 glibc 上编译的，装到老系统里会直接报GLIBC_2.28 not found，这种包就不能用。

3.3 本地依赖解析：在没有 yum 源的情况下怎么算依赖

内网机器没有外网源时，不能依赖 yum 自动拉依赖，只能靠rpm自带的依赖检查。在正式执行前，用--test跑一遍“预演安装”是最稳的做法：

cd /root/offline_upgrade/rpm_packages rpm -Uvh --test *.rpm

注意通配符*.rpm要包含目录里的所有包，让 rpm 把整个包集合放在一个事务里联合解析。如果你只测单个 openssh-server，rpm 会告诉你缺少一堆库；但这些库可能就在同一个目录的其他包中。批量解析的意义就在这里：依赖是在“包集合内部”互相满足的。如果--test没有报错，说明这批包从依赖角度是自洽的，可以往下走。

如果--test报缺某个包，可以先单独看缺什么：

rpm -qpR openssh-server-8*.x86_64.rpm | grep -i 'libcrypto\|libssl\|pam\|zlib'

再对应检查本地是否已经有满足要求的版本：

rpm -q --whatprovides 'libcrypto.so.64()(64bit)' || true

rpm -q --whatprovides是查“哪个已安装包提供了这个符号”的正规姿势。如果结果是openssl-libs-1.1.1q，说明依赖已经满足；如果结果为空，说明需要把对应的 openssl-libs 包加入安装列表。

3.4 版本配比：不是越新越安全

选离线包版本时，我一般不会追求社区最新版，而是看两个约束。第一是“系统世代的兼容性”，比如目标系统是 RHEL 8 世代的内核和 glibc，就优先选为这个世代打包维护的 OpenSSH 8.x 修补版本；非要上 OpenSSH 9.x 通常问题不大，但要注意编译期依赖可能变高。第二是“安全扫描要求”，扫描工具通常检查主版本和补丁级别，挑选带有 CVE 修复标记的后缀版本即可。

升级前可以检查当前 sshd 二进制到底链接了哪个库，这决定你需不需要换依赖包：

ldd /usr/sbin/sshd | grep -E 'libcrypto|libssl|libz|libpam'

如果输出里已经显示/lib64/libcrypto.so.1.1，而离线包里新 sshd 要求libcrypto.so.64，那就必须把 openssl-libs 也换了。换完之后用ldconfig -p | grep crypto确认新的动态库已经被系统缓存，否则重启后依然找不到库。这个细节很容易被忽略：rpm 装完了，但动态库缓存没刷新，sshd 起不来。

4. 一键脚本拆解：备份、替换、重启与日志，一屏看清

4.1 脚本入口与运行方式

拿到这套资源后，不需要手工一条条执行 rpm 命令。入口是upgrade_openssh_offline.sh，支持通过命令行参数控制行为。我常用的运行方式：

sudo ./upgrade_openssh_offline.sh \ --rpm-dir ./rpm_packages \ --backup-dir /opt/ssh_backup \ --restart 1 \ --keep-config 1

参数含义如下：

--restart默认是 1，但我建议第一次在白天窗口执行时改成0，等确认sshd -t校验通过了再手动重启。--keep-config默认保留旧配置，这样你升级后行为不会突然变化；如果设置成0，脚本会采用新 rpm 自带的默认配置文件，审计脚本通常不允许这种操作。

4.2 关键函数：先备份、再装依赖、最后替换主包

脚本主流程并不复杂，核心是两轮安装。拆开看：

upgrade_ssh() { local rpm_dir="$1" # 第一轮：先安装底层依赖包 rpm -Uvh --replacepkgs \ "$rpm_dir"/zlib-*.x86_64.rpm \ "$rpm_dir"/openssl-libs-*.x86_64.rpm \ "$rpm_dir"/pam-*.x86_64.rpm 2>>"$LOG_FILE" # 第二轮：同一事务安装 openssh 主包 rpm -Uvh --replacepkgs \ "$rpm_dir"/openssh-*.x86_64.rpm \ "$rpm_dir"/openssh-clients-*.x86_64.rpm \ "$rpm_dir"/openssh-server-*.x86_64.rpm 2>>"$LOG_FILE" # 刷新服务配置并设置自启 systemctl daemon-reload systemctl enable sshd # 先校验配置，再决定是否重启 if ! sshd -t; then echo "sshd config invalid, restore and retry" | tee -a "$LOG_FILE" restore_sshd_config sshd -t && systemctl restart sshd || exit 1 fi if [ "$RESTART_SSH" -eq 1 ]; then systemctl restart sshd fi }

为什么要分两轮而不是一次rpm -Uvh *.rpm全部装完？主要是降低风险。先装 zlib、openssl-libs、pam，可以保证主包安装时动态库已经就位；如果一次全装，rpm 虽然也能联合解析，但万一主包先于依赖包写出二进制文件，后续刷新缓存时可能会短暂处于不一致状态。分轮更符合“先底后顶”的习惯。

--replacepkgs参数表示“如果检测到同名同版本包已安装，也更新一次”。离线场景下，如果脚本被重复执行，加上这个参数不容易报错。注意整个安装过程没有--nodeps，这是故意的。--nodeps能绕过依赖检测，但它只会把不满足依赖的包硬装上去，运行时缺库的问题一个都躲不掉。不要依赖这个参数，除非你非常清楚自己在干什么。

4.3 保留配置与密钥的逻辑

新版 openssh-server 的 rpm 在安装时到底会不会覆盖sshd_config，这是很多新手迷惑的点。rpm 的行为规则是：如果目标配置文件被修改过，rpm 不会直接覆盖，而是生成一个.rpmnew文件；如果目标文件与你之前安装的包完全一致（没有修改），则会直接替换。很多系统上的sshd_config早就被改过，所以升级后你会看到/etc/ssh/sshd_config.rpmnew。但这仍然不可控，脚本里做了一个双保险：

preserve_sshd_config() { local backup_dir="$1" if [ "${KEEP_CONFIG:-1}" -eq 1 ] && [ -f /etc/ssh/sshd_config ]; then cp -a /etc/ssh/sshd_config "$backup_dir"/sshd_config.pre_upgrade # 如果新包产生了 .rpmnew，留一份模板用于 diff if [ -f /etc/ssh/sshd_config.rpmnew ]; then mv /etc/ssh/sshd_config.rpmnew "$backup_dir"/sshd_config.rpmnew.default fi # 强制把旧配置放回去 cp -a "$backup_dir"/sshd_config.pre_upgrade /etc/ssh/sshd_config fi }

这段代码在安装完成后立刻执行。它先把当前配置备份到临时文件，然后把新包生成的.rpmnew挪到备份目录，最后把旧配置复制回去。这样做的好处是，升级前后sshd_config完全一致，不会突然出现PermitRootLogin被改掉、PasswordAuthentication变成 no 之类的意外。如果你想看新版本默认参数长什么样，可以直接看备份目录里的sshd_config.rpmnew.default，用它和当前配置做diff，而不是直接采用。

主机密钥的处理也在这附近：脚本默认不重新生成密钥，除非你显式传一个--force-hostkey。因为主机密钥是识别服务器身份的凭据，一旦变了，所有客户端的 known_hosts 会全部失配。对生产服务器来说，保留旧主机密钥是必须的。

4.4 日志与失败兜底

整个脚本统一把输出写到/var/log/openssh_offline_upgrade.log，同时打印到终端。建议执行时用这样的方式：

sudo ./upgrade_openssh_offline.sh > /tmp/openssh_upgrade_console.log 2>&1

然后另开一个终端窗口跟踪日志：

tail -f /var/log/openssh_offline_upgrade.log

脚本的失败兜底主要集中在sshd -t校验环节。上面代码里已经展示：如果配置校验失败，立即从备份恢复配置并尝试重启；如果恢复后仍失败，脚本退出并不再破坏现场。这样至少给你留下一个可以手动排查的环境，而不是把 sshd 置于既没有配置、也起不来的状态。

提示：执行期间不要同时跑yum或dnf事务，rpm 数据库的锁会被占用，脚本会在安装步骤卡住，等很久之后报“数据库被锁定”。

5. 避坑：离线升级 OpenSSH 最容易翻车的 5 个场景

5.1 libcrypto.so 找不到：只换了主包，没换依赖包

现象：升级完成后执行systemctl start sshd，报错error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file，或者日志里说/usr/sbin/sshd: No such file or directory。

原因：新版 OpenSSH 二进制要求更高版本的 openssl-libs，而系统当前库版本偏低。你把 openssh-server 装上了，但 openssl-libs 没跟着升级；rpm 安装时因为用了--nodeps，或者因为包的构建要求恰好低于系统当前版本，所以没被检查出来。

解决：把配套的openssl-libsrpm 包放进包目录，和主包一起重装。装完执行ldconfig刷新动态库缓存，再用ldd /usr/sbin/sshd | grep -i ssl确认链接到的库文件存在。如果离线包里没有配套 openssl-libs，宁可放弃这个 OpenSSH 版本，也不要自己从网上随便下一个高版本 openssl 来硬配，那会把更多服务带崩。

5.2 远程窗口卡死：升级过程中强制重启了 sshd

现象：脚本执行到一半，当前 SSH 终端直接断开，再连也连不上；带外管理里看到 sshd 进程变成退出状态，或者一直在 restart 循环。

原因：脚本把systemctl restart sshd放在安装结束后，但没有考虑“当前会话正运行在 sshd 进程之上”。重启的一瞬间，正在服务的 sshd 进程被终止，当前连接自然被切断。如果新 sshd 因为配置或库问题起不来，你就等于把自己锁在门外。

解决：升级前先用tmux或screen挂一个持久会话，在里面执行脚本；脚本执行时加上--restart 0，先完成安装和校验；确认sshd -t通过后，再手动重启。手动重启后不要马上关当前窗口，等一个新终端能正常连进来再收工。另外，保证带外控制台或本地控制台可用，是最后一道后悔药。

5.3 PAM 认证失败：密码对也进不来

现象：升级后密码正确但登录被拒，/var/log/secure或/var/log/messages里出现pam_unix(sshd:auth): authentication failure，或者PAM unable to dlopen(/etc/pam.d/sshd)。

原因：新版 OpenSSH 对 PAM 模块路径或 pam 版本要求有变化。常见有两种情况：一是系统 pam 包太老，不包含新版 sshd 需要的函数；二是 rpm 安装时把/etc/pam.d/sshd覆盖成了新版本自带模板，而新模板里引用了不存在的模块。

解决：先看系统 pam 包版本和离线包里 pam 包的版本是否匹配：

rpm -q pam cat /etc/pam.d/sshd

如果 pam 太老，把配套的 pam rpm 包也装进去；如果 pam 文件被覆盖，从备份目录恢复/etc/pam.d/sshd。恢复后执行authconfig --updateall或者重启systemd-logind刷新会话服务，再测试登录。PAM 的问题是所有 sshd 升级里最玄的一类，遇到时不要死磕 OpenSSH，先对比 pam 版本，往往一眼就找到答案。

5.4 root 登录被拒：默认配置把 PermitRootLogin 改了

现象：升级完成，普通用户能连，root 登录被拒绝，日志里写Disconnected from user root或Permission denied。

原因：新版本的默认sshd_config模板可能把PermitRootLogin设成prohibit-password或no。如果脚本没有保留旧配置，或者安装过程中/etc/ssh/sshd_config.rpmnew被直接改名覆盖了原配置，root 登录行为就会被改变。

解决：检查实际生效值：

grep -E '^(#|)PermitRootLogin' /etc/ssh/sshd_config sshd -T | grep -i permitrootlogin

如果确实被改掉，把/etc/ssh/sshd_config恢复成升级前版本。如果原系统里就没有显式配置这项，旧版本默认是允许的，新版本默认禁止了，这时需要显式添加：

echo "PermitRootLogin yes" >> /etc/ssh/sshd_config sshd -t && systemctl restart sshd

不要为了图省事直接chmod或者切到sftp，先把行为差异对上再说。

5.5 依赖误报：并不是缺包，而是安装顺序和通配符问题

现象：执行rpm -Uvh openssh-server-*.rpm时报Failed dependencies: libcrypto.so.64()(64bit) is needed，但你明明看到目录里有 openssl-libs 包。

原因：这是一个很经典的误报。rpm 命令只解析你传入的包，如果你只传了 openssh-server，它不会自动去同目录里找 openssl-libs；只有把所有包一次性放进同一个事务时，rpm 才会在事务内部做联合依赖解析。逐包安装，或者只装主包，都会报这种“看似缺包”的错误。

解决：把目录下的全部 rpm 包一次传给 rpm：

cd /root/offline_upgrade/rpm_packages rpm -Uvh --replacepkgs --test *.rpm

如果--test通过，再真实安装。也可以用脚本里的分两轮安装方式，但第一轮必须先把所有依赖包装好。判断到底是缺包还是误报，最直接的办法是执行rpm -qpR openssh-server-8*.rpm | grep libcrypto，拿到符号名后用rpm -q --whatprovides检查系统是否已有。不要看到依赖错误就去搜包，先确认你手里的包集合是否完整。

6. 升级后的验证与回滚技巧：别急着收工

6.1 验证三板斧：配置校验、新连接实测、日志复核

升级完成不代表可以收工。我给自己定过流程，每次升级 OpenSSH 后必须走完三步。第一步是配置文件与二进制校验：

sshd -t ssh -V 2>&1 rpm -q openssh openssh-server openssh-clients openssl-libs

三步里sshd -t检查配置语法，如果这里报错，说明配置里有新版本不认识的参数。第二步是连接实测，不要在当前会话里直接退出，而是新开一个终端测试登录、执行命令、传文件。第三步是查看日志：

systemctl status sshd --no-pager journalctl -u sshd --since "10 minutes ago" | tail -50

日志里重点看有没有PAM、fatal、error字样。另外一个容易被忽略的习惯是，用sshd -T导出生效配置并和升级前备份的sshd-config-effective.txt做 diff：

diff /opt/ssh_backup/sshd-config-effective.txt <(sshd -T)

有差异不代表有问题，但你必须知道差异在哪里，尤其是认证、端口、root 登录这类高危项。

6.2 回滚：旧 rpm 包就是后悔药

升级验证不通过，或者过了两天发现不兼容，回滚比继续修补更省心。前提是你在升级前保存了旧 rpm 包。这套资源的备份目录设计里会保留旧包清单，但旧包本身需要你预先留存。回滚命令：

cd /opt/ssh_backup/rpm_packages rpm -Uvh --oldpackage openssh-7*.x86_64.rpm \ openssh-clients-7*.x86_64.rpm \ openssh-server-7*.x86_64.rpm

--oldpackage参数允许 rpm 从高版本降到低版本。如果备份目录里连配置文件也存了，恢复配置：

cp -a /opt/ssh_backup/etc/ssh/sshd_config /etc/ssh/sshd_config systemctl restart sshd

回滚后同样要执行一遍验证三板斧。记住回滚不等于“装回去就行”，还要确认主机密钥没变，如果变了，直接用备份覆盖/etc/ssh/ssh_host_*_key并重启 sshd。

我在一次升级里吃过教训：升级后ssh -V显示新版本，觉得大功告成，顺手把旧 rpm 包和配置备份删了。结果第二天业务反馈 sftp 传文件名编码风格变了，连数据库备份脚本都开始报错。想回滚却发现旧包已删除，只能在局域网其他机器上翻镜像，折腾了大半天才找到同一小版本的包。从那以后，我每次升级都会把旧 rpm 包、旧配置、主机密钥统一打包保留至少一个月，并且强制走完sshd -t新连接实测和日志复核这三步才宣布完成。希望这套流程和资源能帮你在离线环境里把 OpenSSH 升级得干净利落。

本文还有配套的精品资源，点击获取