CentOS 7升级OpenSSH 9.5实战：rpm包批量部署与回滚指南

最近要把一批老旧的 CentOS 7 服务器做安全加固，第一件事就是处理 OpenSSH 版本太旧的问题。这批机器上默认还是 OpenSSH 7.4，跑了六七年，期间爆出的 CVE 一个接一个，尤其是远程未授权访问和算法弱点相关的漏洞，安全扫描根本过不了。因为线上机器多、不能一台台搞特殊化，我选了 rpm 包升级的方式，统一把 OpenSSH 升到 9.5。这篇文章是这次升级的完整记录，包含方案选型、依赖分析、批量安装步骤、回滚预留，以及我在实际升级中踩过的坑。给同样在 CentOS 7 上升级 OpenSSH 的人做个参考，不管你是只升一台测试机，还是想批量推生产环境，这篇都能直接照抄。

1. 升级前的准备与方案选型

1.1 为什么坚持选 rpm 包而不是源码编译

先说说为什么这次没有用源码编译。第一个原因是 CentOS 7 默认 OpenSSH 7.4p1 用的是系统自带的 OpenSSL 1.0.2k，如果我下载 openssh-9.5 源码包去 ./configure && make && make install，编译过程中很可能链接到系统里新装的 OpenSSL 1.1.1 或 3.x 版本，新旧依赖混在一起，极容易出现 sshd 启动时报错 OpenSSL version mismatch 的情况。第二个原因是源码编译默认会装到 /usr/local 下，和系统自带的 ssh/sshd 命令并存，后续排错时到底调的是哪个版本都分不清，维护成本高。

rpm 包方案最大的优势是：升级包由第三方仓库统一构建，所有依赖关系都写死在 rpm 的 metadata 里，系统里缺什么它会自动提示，而且安装后直接替换 /usr/bin/ssh、/usr/sbin/sshd，行为可预期，更适合批量推送。整个升级过程不需要 gcc、make、openssl-devel 这一堆编译工具链，对生产环境来说也缩小了攻击面。

这里我用了一张表格，把几种主流升级方式做了对比，方便你根据自己环境选型：

结论很明确：多台 CentOS 7 要升级到 OpenSSH 9.5，优先选 rpm 包。量大、可回滚、可自动校验依赖，这几条对生产环境就是决定性的。

1.2 先摸清当前环境再动手

开始操作之前，先把目标机器的系统版本、当前 OpenSSH 版本、系统架构摸清楚。重点看两个东西：

bash复制# 查看系统版本和架构
cat /etc/redhat-release
uname -m

# 查看当前 OpenSSH 版本
ssh -V

我当时执行的结果是这样：

text复制CentOS Linux release 7.9.2009 (Core)
x86_64
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017

确认是 CentOS 7.9、x86_64 架构、自带 OpenSSH 7.4p1。这一步很重要，因为 OpenSSH 9.5 的 rpm 包是按不同系统版本和架构分别构建的，CentOS 7 的包不能拿到 CentOS 8 上装，x86_64 的包也不能装到 aarch64 机器上，下载之前必须先确认这两点。

另外还要确认系统里有没有安装过第三方的 ssh 相关组件，比如 openssh-ldap、openssh-server 的旧版本、pam_ssh_agent_auth 之类的依赖包。如果装了这些扩展包，升级时可能会和 openssh 主包版本冲突，rpm 会报 package openssh-7.4p1-21.el7.x86_64 (which is newer than openssh-9.5p1-1.el7.x86_64) is already installed 这类错误。这类冲突我之前遇到过，后面专门放到常见问题里说。

1.3 搞定 rpm 包的下载和校验

OpenSSH 9.5 的 rpm 包可以直接从系统自带 yum 仓库扩展源、第三方开源镜像站下载。我这里用的是在线下载模式：先把 rpm 包下载到本地，然后通过 scp 传到目标机器，或者直接在目标机器上用 wget 下载。需要下载的包主要有这几个：

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

有的第三方仓库还会额外打出 openssh-askpass 和 openssh-debuginfo，生产环境用不到，可以不下。如果你之前系统里装过 openssh-ldap，那还要补一个对应版本的 openssh-ldap 包，这个比较少见，多数服务器不会装。

下载完之后，习惯性做一次完整性校验，确保下载过程中没有文件损坏：

bash复制# 在 rpm 文件所在目录执行，检查包是否完整
rpm -K *.rpm

正常输出会有 digests signatures OK 字样。这一步别跳过，我遇到过下载工具中途断流导致 rpm 包损坏的情况，直接安装会报 rpm: not an rpm package (or package manifest)，既浪费时间又容易让人误判问题方向。

2. 关键细节：升级前必须做好的风险控制

2.1 升级 OpenSSH 会改动哪些文件

OpenSSH 升级不是简单替换几个二进制文件，rpm 包升级会同时覆盖以下内容：

• /usr/sbin/sshd、/usr/bin/ssh、/usr/bin/scp、/usr/bin/sftp 等可执行文件
• /etc/ssh/sshd_config、/etc/ssh/ssh_config 配置文件（rpm 会保留原配置文件，生成 .rpmsave 备份）
• /usr/lib/systemd/system/sshd.service 服务管理文件
• /etc/pam.d/sshd、/etc/init.d/sshd 等认证相关文件
• /var/empty/sshd 目录权限及相关用户

这意味着升级过程中 sshd 服务会中断，如果你在远程操作，一旦 sshd 启动失败，当前连接可能直接断掉且无法重连。所以远程升级之前必须做两手准备：一是确认有备用登录通道，二是把旧版本 rpm 包留好以便回滚。

2.2 必须准备好备用登录通道

这是本次升级我认为最值得强调的一件事。远程升级 OpenSSH，如果只靠 SSH 连接操作，一旦 sshd 服务重启失败，你就会被锁在机器外面，尤其是云服务器没有带外管理控制台的情况下，会很被动。

我这次提前在两个节点上都配好了 telnet 服务作为备用通道。注意，telnet 本身是明文传输，只在升级期间临时开启，升级完成后立刻关闭并卸载 xinetd 和 telnet-server，不在生产环境长期开放。操作步骤大概是：

bash复制# 安装 telnet 服务
yum install -y telnet-server xinetd

# 启动服务，并设置开机自启（仅供本次升级期间使用）
systemctl start telnet.socket
systemctl start xinetd
systemctl enable xinetd

启动后用 telnet 客户端测试登录一次，确认能用 root 或普通用户登录，再把 SSH 相关操作和 telnet 测试放到两个不同的网络路径上，保证即使 sshd 挂了，也有另一个通道能进系统排查和回滚。

升级全部完成、确认 sshd 服务正常后，第一时间关闭并移除这些临时服务：

bash复制systemctl stop xinetd
systemctl stop telnet.socket
systemctl disable xinetd
yum remove -y telnet-server xinetd

顺便把防火墙里临时放行的 23 端口规则删掉。我一直建议团队把"备份 + 备用通道 + 回滚包"这三件事做成升级前 checklist，缺一不可。

2.3 备份策略：不只是备份配置，连旧 rpm 包一起留好

备份这块，很多人只是把 /etc/ssh 复制一份就完事了，我觉得不够。配置备份只是一部分，真正出问题时，最可靠的回滚方式是拿旧版本的 rpm 包重新降级，所以完整备份要同时覆盖三个层面：

• 配置文件备份：整个 /etc/ssh 目录保留一份，包括 sshd_config、ssh_config、host 密钥
• 旧 rpm 包备份：把当前安装的 openssh 系列 rpm 包导出来保存
• 主机密钥备份：/etc/ssh/ssh_host_* 这些密钥文件是所有连接信任的基础，一定不能丢失

备份命令我写成了一段，直接扔到脚本里执行：

bash复制# 备份配置目录
cp -rp /etc/ssh /etc/ssh.bak.$(date +%Y%m%d%H%M%S)

# 导出当前已安装的 openssh 系列 rpm 包（用于回滚降级）
mkdir -p /root/openssh_backup_rpm
rpm -qa | grep openssh | while read pkg; do
    rpm -ql "$pkg" > /dev/null 2>&1 && \
    yumdownloader "$pkg" --destdir=/root/openssh_backup_rpm
done

yumdownloader 命令需要 yum-utils 工具包，如果没有就先装一下：yum install -y yum-utils。

主机密钥如果丢了，后续重新生成密钥也麻烦。因为客户端 known_hosts 里存的是旧指纹，主机密钥一变，所有客户端的指纹告警都会弹出来，虽然能排查，但会影响线上别的服务调用。所以备份 ssh_host_* 文件这几行命令，请你一定执行。

3. 实操过程：从下载 rpm 包到 sshd 恢复正常

3.1 检查磁盘空间和依赖包

安装前先看一眼磁盘剩余空间，openssh 9.5 的 rpm 包加上依赖，整体占用不大，但 /usr 分区如果已经很满了，还是会有写不进去的风险。我习惯先检查：

bash复制df -h /usr /var /etc

然后检查系统当前已经装好的关键依赖：

bash复制rpm -qa | grep -E '^openssl|^zlib|^pam'

输出大致是：

text复制openssl-1.0.2k-21.el7_9.x86_64
zlib-1.2.7-18.el7.x86_64
pam-1.1.8-23.el7.x86_64

OpenSSH 9.5 的 rpm 包依赖这两组库，CentOS 7 自带的这些版本满足要求，不需要额外升级。如果它的构建方用了更高的 openssl 版本，rpm 安装时会明确报缺库，到时候再按照提示补装依赖即可。

3.2 安装过程：rpm -Uvh 而不是 rpm -ivh

这里有个细节我觉得值得展开说。升级安装建议用 rpm -Uvh，而不是 rpm -ivh。-U 是 upgrade 的意思，安装新包的同时会把旧包替换掉；-i 是 install，如果系统已经有旧版本，会直接报 package already installed 错误。虽然 -i 加上 --replacepkgs 也能强装，但不会正确处理旧包卸载后的配置文件迁移，容易留下 .rpmsave 文件混乱的情况。

安装命令：

bash复制cd /path/to/rpm/dir
rpm -Uvh openssh-9.5p1-1.el7.x86_64.rpm openssh-server-9.5p1-1.el7.x86_64.rpm openssh-clients-9.5p1-1.el7.x86_64.rpm

安装过程中 rpm 会打印每个包的安装进度和依赖检查结果。如果你看到类似 warning: /etc/ssh/sshd_config created as /etc/ssh/sshd_config.rpmsave 的提示，不必慌，这是 rpm 在保留你原有配置的前提下，装入了新的默认配置文件。OpenSSH 9.5 的默认配置比 7.4 多了不少新参数，直接把旧配置覆盖掉可能导致新版本某些特性没生效，所以 rpm 选择了保守策略。

如果这时候你担心配置文件差异较大，可以直接对比两份文件：

bash复制diff /etc/ssh/sshd_config.rpmsave /etc/ssh/sshd_config

按需把旧配置里自己需要的参数手动迁移到新配置中。我一般不会直接 cp 覆盖，而是逐个参数核对，避免新版本不认识的参数导致 sshd 启动失败。

3.3 启动 sshd 并确认关键服务状态

安装完成后，尽量先不要重启 sshd，先做一次配置校验：

bash复制sshd -t

如果配置有问题，会直接输出错误行，比如 Bad configuration options。确保没有报错之后再重启服务：

bash复制systemctl restart sshd
systemctl status sshd

这一步是升级操作中最容易出现问题的节点。我在实际升级中见过不少情况：sshd 启动状态是 active (running)，但端口监听是旧的，或者干脆连不上。所以除了看 systemctl status，还要确认端口在监听：

bash复制ss -tlnp | grep 22

正常输出应该类似：

text复制LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=12345,fd=3))
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=12345,fd=4))

说明新的 sshd 已经开始监听 22 端口。这时候再开一个新终端，尝试建立新的 SSH 会话，重点测试 root 登录、普通用户登录、密钥登录、密码登录这些常见场景。不要急着把旧连接断开，等新会话确认能正常登录后，再关掉旧连接。这样即使新配置有问题，旧连接还能帮你补救。

最后验证版本是否真正切换到了 9.5：

bash复制ssh -V

输出应该是：

text复制OpenSSH_9.5p1, OpenSSL 1.0.2k-fips  26 Jan 2017

到这里，单机升级就完成了。

3.4 新版本配置项检查与参数调整

OpenSSH 9.5 相比 7.4 在默认配置上有一些变化，我特别留意了这几点：

第一个是 PermitRootLogin 默认值的变化。虽然你自己的配置会覆盖默认值，但如果之前用的是纯净初始配置，9.5 的默认策略更严格，默认禁止 root 密码登录。如果你线上业务有 root 直连的需求，需要检查 sshd_config 里是否显式配置了 PermitRootLogin yes。

第二个是废弃了部分旧算法。比如 ssh-rsa 签名算法在 9.5 中默认不再启用，但可以通过配置 PubkeyAcceptedAlgorithms +ssh-rsa 重新打开。如果内部有老客户端还在用 RSA 密钥登录，升级后会出现"no matching key exchange method"这类报错。我们这次升级前专门盘点过客户端兼容性，确认没有老客户端依赖后才推进的。

第三个是 SFTP 子系统配置。新包的 Subsystem 路径默认指向 /usr/libexec/openssh/sftp-server 或 /usr/libexec/sftp-server，升级后路径一般不会变，但如果你有个性化配置，记得核对一下。

我在单机上验证完以上几点后，再把同一套 rpm 包同步到其他机器批量执行。

4. 批量部署和常见问题排查实录

4.1 批量升级：每台都保留独立备份

这次升级因为涉及多台机器，我先在一台测试机上完整跑通了整个流程，确认没问题后，再写成了一个简单的 for 循环脚本用于批量推送。核心思路就是每台机器各自备份、各自执行、各自验证，不搞跨机器共享配置。

脚本大致长这样：

bash复制#!/bin/bash

rpm_dir="/root/openssh95_rpm"
log_file="/root/openssh_upgrade_$(date +%Y%m%d).log"

for ip in $(cat server_list.txt); do
    echo "===== upgrading $ip =====" | tee -a "$log_file"
    
    # 将 rpm 包复制到目标机器
    scp -P 22 $rpm_dir/*.rpm root@$ip:/root/openssh95_rpm/
    
    # 远程执行升级
    ssh -p 22 root@$ip "
        mkdir -p /root/openssh_bak/\$(date +%Y%m%d%H%M%S)
        cp -rp /etc/ssh /root/openssh_bak/\$(date +%Y%m%d%H%M%S)/ssh_config_bak
        rpm -qa | grep openssh > /root/openssh_bak/old_rpm_list.txt
        cd /root/openssh95_rpm
        rpm -Uvh *.rpm
        sshd -t && systemctl restart sshd && sleep 1 && systemctl status sshd | head -3
        ssh -V
    " | tee -a "$log_file"
done

需要注意的是，这段脚本里的备份命令在远程执行时，日期会在同一台机器上展开为同一个值，所以备份目录看起来是共享的，但实际每台机器是独立执行，不存在互相覆盖的问题。如果日期到秒级别都一样，那备份目录文件名重复确实可能覆盖，建议在本地拼接好时间戳变量再传进去，而不是在远程 shell 里重新取时间。我当时为了避免这个问题，是用了一个固定时间戳字符串作为备份目录名，保证每台机器只备份一次。

批量升级过程中，我用 ssh -V 的输出逐台核对版本号，确保所有机器都切到了 9.5。这里挑机器时也注意了批次：先升级非核心业务机器，再升级核心业务机器，Windows 跳板机和堡垒机最后升级。分批推进的好处是万一某个版本有问题，影响面可控。

4.2 问题一：启动 sshd 时报 Bad configuration options

这是我这次升级碰到频率最高的问题。具体报错是这个：

text复制/etc/ssh/sshd_config line 37: Bad configuration options: Ciphers

然后 sshd 启动失败。原因很简单：新版本 OpenSSH 9.5 废弃了部分旧的加密算法和配置项，而我原配置里写的某些参数在 9.5 里已经不再支持。比如 Ciphers 里写了的 aes128-cbc、aes256-cbc，在 9.5 里从默认支持列表中移除了。

处理方法：

bash复制# 先看配置文件里有哪些参数在报错
sshd -t 2>&1 | grep "Bad configuration"

# 编辑 sshd_config，把不支持的配置项注释掉或改为新算法
vi /etc/ssh/sshd_config

我一般是把 Ciphers、MACs、KexAlgorithms 这三段集中检查一遍，删掉老算法，只保留 9.5 支持的算法。如果非要用老算法兼容旧客户端，需要在配置里显式加回，比如：

text复制Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
MACs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256

理论上 ssh -t 测试通过后，再重启 sshd，就不会再报错了。

4.3 问题二：升级后别的机器连不上，提示 no matching key exchange method

我在升级完一批机器后，测试机通过堡垒机去连一台新升级的机器，就报了这个错误：

text复制Unable to negotiate with 192.168.1.100 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256,...

原因是客户端版本太老，不认服务端 9.5 提供的新 KEX 算法。问题不在服务端，而在客户端。如果客户端无法更新，可以在客户端的 ~/.ssh/config 里临时加一行：

text复制Host 192.168.1.100
    KexAlgorithms +diffie-hellman-group14-sha256

这样老客户端也能连新服务端。不过这只是临时方案，最终还是要让客户端升级到新版本。从安全角度讲，服务端不该为了兼容老客户端而降低算法强度。所以我的建议是：升级前先做好资产盘点，明确哪些机器还在用老客户端，提前把它们纳入升级批次的后半段。

4.4 问题三：ssh 能连上但密码登录失败

这个case我印象特别深。升级完重启 sshd 后，密码登录总是报 Permission denied, please try again，但明明密码是对的。一看系统日志：

bash复制journalctl -u sshd | tail -30

发现报了 PAM 相关的错误。原因是新版本的 sshd 对 PAM 的调用方式和旧版本有差异，而 /etc/pam.d/sshd 里的配置还是老版本风格。解决方法是直接对比 rpm 生成的默认 pam 文件和当前 pam 文件。

bash复制# 检查当前 pam 配置
cat /etc/pam.d/sshd

# 如果 pam 配置确实有问题，可以直接从默认配置恢复
# 注意先把当前配置备份
cp /etc/pam.d/sshd /etc/pam.d/sshd.bak.$(date +%Y%m%d)

多数情况下，新版 rpm 包安装时已经自动更新了 /etc/pam.d/sshd，不需要手动改。但我见过某些第三方构建的 rpm 包在升级时没有正确覆盖 pam 配置，导致认证行为异常。如果出现这种情况，可以对比同版本正常机器的 pam 配置，逐行核对差异。

4.5 问题四：sshd 起来了但端口不通

还有一个常见现象：sshd 状态是 active (running)，端口也监听了，但从外部就是连不上。这类问题通常出在防火墙或 selinux 上，不是 sshd 本身的问题。

先看防火墙：

bash复制firewall-cmd --state
firewall-cmd --list-all

确认 22 端口是否在 public 区域的 services 或 ports 列表中。如果之前是通过 systemctl stop firewalld 临时关掉防火墙来测试的，升级完千万别忘了按需放行端口而不是直接停防火墙。生产环境防火墙默认是开启的，我这次就把 22 端口重新加入到了放行规则里：

bash复制firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload

再看 selinux。CentOS 7 默认 selinux 是 enforcing，OpenSSH 升级后如果 sshd 相关文件的安全上下文不对，连接会被拒绝，日志里能看到 AVC avc: denied { name_connect } 这类记录。处理方法是用 restorecon 恢复上下文：

bash复制restorecon -Rv /etc/ssh /usr/sbin/sshd /usr/bin/ssh

如果之前做过自定义策略或修改过 selinux 布尔值，需要额外检查 getsebool -a | grep ssh，确认 ssh 相关布尔值正常。

4.6 问题五：升级后如何快速回滚

尽管做足了准备，还是有可能出现极端情况：比如新版本和某些业务组件不兼容，必须回滚。回滚的逻辑就是反向操作，用之前备份的旧 rpm 包重新降级。

bash复制# 进入备份目录
cd /root/openssh_backup_rpm

# 强制降级回旧版本
rpm -Uvh --oldpackage *.rpm

这里关键的参数是 --oldpackage，不加这个参数 rpm 会认为你要安装的包版本低于当前版本而拒绝执行。执行完降级后，同样用 sshd -t 做配置校验，然后重启 sshd，再用 ssh -V 确认版本回到了 7.4p1。

如果配置文件也被新版本修改过，回滚后需要用之前备份的配置文件覆盖回去。这里顺序很重要：先恢复 rpm 包，再恢复配置文件，最后重启 sshd。如果顺序反了，可能出现配置文件和新版本不匹配导致的老问题。

回滚验证通过后，我再继续排查新版本不兼容的具体原因。

4.7 常见问题速查表

把这次升级中遇到的问题和排查路径整理成了表格，方便你现场对照：

5. 升级完成后的一些额外建议

OpenSSH 升级到 9.5 后，我这边还顺手做了几件事，属于"升级之后不亏还能多赚"的操作。第一是修改 sshd_config 里几个安全相关参数。比如把 PermitRootLogin 改成 prohibit-password，让 root 只能通过密钥登录；把 PasswordAuthentication 改成 no，彻底关掉密码登录，只保留密钥认证；MaxAuthTries 设置成 3，限制单次连接的认证尝试次数。这两个参数在只靠密码认证的机器上要谨慎操作，改错了会直接锁死自己，所以建议先确认手上有密钥、备用通道都可用再动。

第二是顺手清理一下 authorized_keys。升级过程中发现有些机器的 authorized_keys 里堆了不少历史公钥，有些已经离职的同事的 key 还挂在上面，这属于典型的高级持久化风险。我在升级窗口期顺便把每个用户目录下的公钥都核对了一遍，只保留当前在用的。这个操作比升级 OpenSSH 本身更能提升安全性，成本也低。

第三是检查登录日志。升级完成后，我会重点看 /var/log/secure 里有没有异常IP的爆破记录。如果之前 OpenSSH 7.4 一直在公网裸奔，日志里通常已经积累了大量失败的 SSH 登录尝试。升级到 9.5 之后，虽然默认配置已经更安全，但依然建议配合 fail2ban 或防护软件做一层暴力破解拦截。

最后还有个建议：把升级内容和验证结果记录到变更文档里，包括旧版本号、新版本号、涉及的配置文件变更、升级后验证命令和结果。不要小看这一步，后面等这批机器再做安全审计，或者三五年后有人问起"这台机器 OpenSSH 怎么是 9.5"，这份记录能直接回答所有疑问，不用再从头排查。

我在实际操作中的体会是，OpenSSH 升级这件事看起来简单，但真正的风险其实全藏在升级前的准备和升级失败后的恢复上。rpm -Uvh 一行命令几秒钟就执行完，但前面的环境评估、备份、备用通道，以及出问题时回滚的完整预案，才是整个升级过程中真正花时间的地方。把这些准备工作做到位，升级本身反而变成一个很轻松的流程。