一份季度安全扫描报告甩过来主机列表里八成以上的 CentOS7 机器都被标了个红框OpenSSH 版本过低。这个结果并不意外——CentOS7 自带的 OpenSSH 长期停留在 7.4p1 这个基线而ssh -V的输出又恰恰是漏扫工具判断风险的唯一依据。于是运维同学就被夹在中间业务侧说别动能连就行安全侧说必须升级不然不签字而你手里只有一台不知道能不能重启的生产机。这篇就把 CentOS7 上升级 OpenSSH、修复安全漏洞的完整链路摊开讲从选路、编译、备份、割接验证一直聊到批量落地和踩坑排查适合手上还掌管着 CentOS7 资产、需要一次性把这件旧账清掉的朋友。1. 先搞清楚 CentOS7 上的 OpenSSH 到底旧在哪很多人对这件事的判断停留在版本号低这个层面其实真正需要说服自己和安全同学的是三件事旧在什么地方、这些地方对应什么风险、以及为什么常规的yum update解决不了这个问题。把这三件事想清楚后面选路线和做割接方案时就不会反复摇摆。1.1 为什么yum update openssh补不齐这些漏洞Red Hat 的维护策略是版本号不动补丁往回打所以 CentOS7 上你yum update完之后ssh -V依然显示OpenSSH_7.4p1, OpenSSL 1.0.2k-fips。这不代表它没打补丁恰恰相反绝大多数高危漏洞 Red Hat 都做了 backport 处理代码层面可能已经修好了。问题在于漏扫工具判断风险的方式是读版本号字符串而不是反编译你的二进制。只要 banner 里还是 7.4p1报告上就是一行红字整改复测就是过不去。这就是 CentOS7 OpenSSH 升级这件事最拧巴的地方技术上是为了合规而升级而不是为了安全而升级。想明白这一点你就知道为什么不能简单地跟安全同学解释我们已经打了补丁——这条路通常走不通还是老老实实把版本号顶上去更省事。还有一层现实因素CentOS7 已经走完了自己的生命周期官方仓库的补丁流也已经停了。继续留在 7.4p1 上意味着未来新出的漏洞不会再有官方 backport只能自己扛。这时候把 OpenSSH 升到一个较新的主线版本反而是长期成本更低的选择。1.2 用一张表把版本号和实际危害对上号说服别人之前先说服自己。下面这些漏洞是漏扫报告里最常出现的项目也是升级的实际收益所在漏洞编号影响版本危害类型通俗解释CVE-2016-10708低于 7.5拒绝服务客户端构造畸形报文可让 sshd 空指针崩溃CVE-2018-15473低于 7.7信息泄露通过认证响应差异枚举系统上存在哪些账号CVE-2019-6111低于 7.9文件覆盖scp 客户端下载时服务端可覆写客户端本地任意路径CVE-2020-15778低于 8.4命令注入scp 的参数拼接问题可被利用作为命令执行跳板CVE-2021-416176.2 至 8.7权限提升AuthorizedKeysCommand 等场景下继承多余的用户组权限CVE-2023-38408低于 9.3p2远程代码执行ssh-agent 转发加 PKCS#11 的组合利用CVE-2023-48795多个版本中间人降级即 Terrapin 攻击前缀截断影响部分加密算法CVE-2024-63878.5p1 至 9.7p1远程代码执行即 regreSSHion信号处理竞态glibc 平台受影响这里有个细节值得单独拎出来CentOS7 的 7.4p1 反而不受 regreSSHion 影响因为那个漏洞的引入版本是 8.5p1。所以如果安全同学拿 regreSSHion 来要求你升级 7.4p1你可以理直气壮地说明这个版本不在影响区间内。但前面那几项 7.4p1 是实打实受影响的尤其是 CVE-2018-15473 和 CVE-2020-15778几乎每份扫描报告都会点出来。1.3 动手之前必须确认的四件事升级 OpenSSH 有个天然的风险你正在动的那扇门恰好就是你自己进屋的那扇门。所以在敲第一条命令之前先把下面四件事确认清楚能省掉 90% 的半夜救火。有没有带外管理通道物理机的 IPMI、虚拟机的 VNC 控制台、云主机的 VNC 或串口登录至少要有一种。只有 SSH 一条路可走的主机坚决不做在线升级先想办法把带外通道打通。有没有 root 直连依赖新版本PermitRootLogin的默认值早就从yes变成了prohibit-password如果有自动化脚本在用 root 密码直连升级后会被直接拒掉。有没有依赖 scp 和 rsync 的业务OpenSSH 9.0 之后 scp 默认走 SFTP 协议行为有细微差异备份脚本、设备配置采集脚本要提前测。有没有第三方组件绑定了 SSH 版本老版本 Ansible、Jenkins 插件、Java 侧的 JSch、Python 侧的 Paramiko这些库对主机密钥算法和密钥交换算法有各自的兼容矩阵新服务端可能会让它们连不上。2. 三条升级路线的取舍以及我为什么最后选了源码编译加打包在 CentOS7 上升级 OpenSSH摆在你面前的路其实只有三条换系统、等官方、自己编。换系统涉及业务迁移周期以季度计官方补丁已经停了所以实际上就是自己编区别只在于编完往哪儿装、要不要做成包。2.1 三种落地方式的横向对比方案安装位置优点缺点适用场景源码编译到 /usr/local/usr/local/bin、/usr/local/sbin不动系统原有文件回滚简单PATH 里两套二进制容易混systemd 单元要手改路径运维同学容易连到旧客户端单台临时验证源码编译覆盖 /usr/usr/bin、/usr/sbin路径与原 RPM 一致配置文件、PAM、systemd 全都不用改覆盖了包管理器的文件rpm -V会报一堆校验失败后续yum update可能把旧版本覆盖回来生产环境主流做法覆盖 /usr 并自建 RPM同上一行有版本记录、可批量分发、可版本锁定、可回滚前期要多花半小时写打包脚本三台以上、或者需要长期维护的机房我一开始也是走的/usr/local方案觉得不动系统文件最安全。结果第一次割接就翻车了运维同事登录上去执行scp用的还是/usr/bin/scp那个旧客户端CVE-2020-15778 依旧存在等于白升。而且 CentOS7 的sshd.service里ExecStart写的是/usr/sbin/sshd你装到/usr/local/sbin之后还得改 unit 文件改完又得systemctl daemon-reload多出来的每一步都是潜在的失误点。2.2 覆盖 /usr 的核心顾虑其实有解覆盖系统文件这件事听起来吓人但拆开看顾虑只有两个。第一个顾虑是包管理器冲突。这个问题用一个exclude就能解决在/etc/yum.conf里加上excludeopenssh*从此yum update再也不会碰 SSH 相关的包。如果你们用的是内网 yum 源也可以在源配置里排除效果一样。第二个顾虑是回滚。回滚其实比想象中简单只要在make install之前把关键二进制改个名字留一份cp -a /usr/sbin/sshd /usr/sbin/sshd.bak-7.4p1 cp -a /usr/bin/ssh /usr/bin/ssh.bak-7.4p1 cp -a /usr/bin/scp /usr/bin/scp.bak-7.4p1出问题的时候把文件名换回来systemctl restart sshd一分钟内恢复。真正的风险不在于覆盖本身而在于你没有留下这条退路就动手了。2.3 时间窗口与备份清单如果条件允许我强烈建议在虚拟机层面先打一个快照。快照的价值在于它能覆盖配置文件改错了但你没发现这类软性故障而文件级备份只能救二进制。除了快照下面这些文件必须在动手前归档到一个单独的目录里我习惯放在/root/ssh-upgrade-backup-$(date %F)备份对象路径为什么必须备份服务端主配置/etc/ssh/sshd_config里面通常累积了多年的定制重写成本极高客户端配置/etc/ssh/ssh_config部分场景下被改过 Ciphers 或 KexAlgorithms主机密钥/etc/ssh/ssh_host_*丢了会导致所有客户端的 known_hosts 报指纹不匹配告警刷屏PAM 配置/etc/pam.d/sshd涉及双因素、账号锁定策略改错直接登不上环境变量文件/etc/sysconfig/sshd有些场景在这里设置了 CRYPTO_POLICY旧二进制/usr/sbin/sshd 等回滚用的最后一道保险主机密钥这一项特别容易被忽略。很多同学的思路是密钥重新生成不就行了但在有几十上百台客户端的场景里主机密钥一换所有客户端的known_hosts校验全部失败各种自动化脚本会集体报错。所以主机密钥一定要原样保留只是注意一下权限私钥600公钥644属主都是 root。3. 编译环境的准备几个特别容易漏掉的依赖和参数源码编译 OpenSSH 本身的难度不高但 CentOS7 这个环境比较特殊——它同时存在系统 OpenSSL 太老和系统已停更装包依赖本地源两个问题。这一节把依赖和参数讲透能帮你少走两三个小时的弯路。3.1 依赖包清单与离线环境的坑在线环境直接装就行yum install -y gcc make perl \ zlib-devel pam-devel libselinux-devel \ openssl-devel krb5-devel \ wget tar这里每一项都不是凑数的。zlib-devel缺失会导致 configure 阶段报zlib.h not found虽然理论上不加--with-zlib也能编但那样就没有压缩传输长距离链路上性能会明显下降。pam-devel缺失的话加--with-pam会在编译中途失败报错位置离真正的原因很远容易误导你往别的方向查。libselinux-devel是 CentOS7 上最容易漏的一个。CentOS7 默认开启 SELinux如果不带--with-selinux编译sshd 进程拿不到正确的安全上下文在 Enforcing 模式下会直接起不来日志里是Permission denied或者cannot execute binary file这类语焉不详的报错。离线环境的坑要单独说如果是内网机器先把本地 yum 源配好用 ISO 挂载最省事否则gcc都装不上。但即便配了本地源openssl-devel的版本也是固定的 1.0.2k这一点在下一小节展开。3.2 OpenSSL 这关怎么过别动系统的 libsslCentOS7 的openssl-devel是 1.0.2k这个版本能不能编 OpenSSH 9.x实测是可以的OpenSSH 的openbsd-compat目录里有兼容层会把EVP_MD_CTX_new这类 1.1.0 才引入的接口映射到老 API 上。所以最省事的做法就是直接--with-ssl-dir/usr用系统的 OpenSSL。但有一个代价你要接受Ed25519 相关特性会受限。OpenSSL 1.0.2 本身不提供 Ed25519如果想让服务端真正用上ssh-ed25519主机密钥和对应的签名算法需要 OpenSSL 1.1.1 及以上。这里有个绝对要避开的操作不要试图升级系统的 openssl 包。CentOS7 上大量基础组件curl、wget、yum 自己、Python 的 ssl 模块都链接在libssl.so.10上你把系统 OpenSSL 换掉轻则 yum 不能用重则系统起不来。正确的做法是编一个独立的 OpenSSL 到/opt/openssl11然后让 OpenSSH 单独指向它./configure --with-ssl-dir/opt/openssl11 ...编完之后在/etc/ld.so.conf.d/下加一行/opt/openssl11/lib执行ldconfig再把新 sshd 用ldd检查一遍确认链接的是/opt/openssl11/lib下的库而不是libssl.so.10。这一步如果忘了sshd 启动时会报找不到库或者静默地链接到旧库上等于白折腾。到底要不要上这套方案我的建议是如果安全基线里明确要求 ed25519 算法那就编如果只是为了让版本号过扫描用系统 OpenSSL 就够了把复杂度留在可控范围内。3.3 configure 参数逐条解释./configure \ --prefix/usr \ --sysconfdir/etc/ssh \ --with-pam \ --with-zlib \ --with-selinux \ --with-ssl-dir/usr \ --with-privsep-path/var/empty/sshd \ --with-md5-passwords \ --with-default-path/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin--prefix/usr决定了二进制装到/usr/bin和/usr/sbin与原 RPM 一致这样 systemd 单元、脚本里的硬编码路径全都不用改。--sysconfdir/etc/ssh让配置文件落到既有位置避免出现/usr/etc/ssh这种诡异目录。--with-privsep-path/var/empty/sshd是针对性选择。上游默认是/var/empty但 CentOS7 的既有约定是/var/empty/sshd。保持路径一致SELinux 的文件上下文标签不用重新定义省去一堆麻烦。代价是你需要手动创建这个目录并设置权限后面排查那一节会讲。--with-md5-passwords在纯新环境里其实可以不加但 CentOS7 上很多老密码哈希是可选的保留它能避免一小部分账号的登录异常。--with-default-path控制的是会话建立后用户拿到的 PATH如果你们有脚本依赖/usr/local/bin里的东西这行不改的话会莫名其妙地 command not found。4. 正式动手备份、编译、安装的完整链路到这一步假设你已经有了快照、有了带外通道、备份目录也建好了。下面这条链路我在几十台机器上跑过顺序不要随意调整每一步都有它的意图。4.1 从备份到编译# 1. 建立备份目录 BK/root/ssh-upgrade-backup-$(date %F) mkdir -p $BK # 2. 备份配置与二进制 cp -a /etc/ssh/sshd_config $BK/ cp -a /etc/ssh/ssh_config $BK/ 2/dev/null || true cp -a /etc/ssh/ssh_host_* $BK/ cp -a /etc/pam.d/sshd $BK/pam_sshd cp -a /usr/sbin/sshd $BK/sshd.bin-$(/usr/sbin/sshd -V 21 | head -1 | tr -d || echo old) ls -l $BK主机密钥的备份我习惯用cp -a保留权限因为后面如果要从备份恢复权限不对手动改回来很费事。# 3. 准备编译目录并下载源码 mkdir -p /usr/local/src cd /usr/local/src # 离线环境的话把 tar.gz 上传到这里即可 tar -xzf openssh-9.8p1.tar.gz cd openssh-9.8p1 # 4. 创建 privsep 目录路径与 configure 参数一致 mkdir -p /var/empty/sshd chown root:root /var/empty/sshd chmod 711 /var/empty/sshd # 5. configure 与编译 ./configure --prefix/usr --sysconfdir/etc/ssh \ --with-pam --with-zlib --with-selinux --with-ssl-dir/usr \ --with-privsep-path/var/empty/sshd --with-md5-passwords \ --with-default-path/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin make -j$(nproc)make -j用满 CPU 核数编译OpenSSH 本身不大一般两三分钟内就能编完。如果make阶段报出no acceptable C compiler found in $PATH那是 gcc 没装上如果报 undefined reference 一堆 OpenSSL 符号八成是openssl-devel没装或者版本对不上。4.2 安装与二进制替换# 6. 再次确认备份在然后覆盖安装 make install # 7. 检查新版本 /usr/sbin/sshd -t -f /etc/ssh/sshd_config echo config OK ssh -Vsshd -t是整套流程里最重要的一行命令。它只做配置语法和密钥文件检查不启动服务如果这里是 OK 的说明配置迁移那一步没有漏。千万不要跳过这一步直接 restart一旦配置里有新版本不再支持的选项sshd 会直接退出而此时你原来的会话还在等你断开重连就再也连不上了。make install会覆盖/usr/bin/ssh、/usr/bin/scp、/usr/bin/sftp、/usr/bin/ssh-keygen、/usr/sbin/sshd同时把新的sftp-server装到/usr/libexec/sftp-server。这里就引出了下一个必须处理的细节。4.3 配置文件迁移删掉那些已经不存在的选项CentOS7 原装的sshd_config里有一批选项在新版本里已经被彻底移除它们不会被忽略而是会让 sshd 直接拒绝启动报Bad configuration option。常见的几项已移除/失效选项处理方式Protocol 2直接注释或删除新版本只支持 SSH2UsePrivilegeSeparation新版始终开启权限分离该选项已移除ServerKeyBits与 SSH1 相关早已无意义KeyRegenerationInterval同上SSH1 时代的产物RhostsRSAAuthentication已移除相关功能由 HostbasedAuthentication 承担RSAAuthentication已移除密钥认证统一走 PubkeyAuthenticationPubkeyAcceptedKeyTypes新名称是 PubkeyAcceptedAlgorithms老名字部分版本仍兼容但建议改除了删掉旧选项还有一行必须改# 原来可能是 Subsystem sftp /usr/libexec/openssh/sftp-server # 改成新装的位置 Subsystem sftp /usr/libexec/sftp-server这一行如果不动sshd会调用旧 RPM 留在/usr/libexec/openssh/下的老sftp-server二进制等于 SFTP 通道的漏洞修复被你原地绕过去了。这是个非常隐蔽的坑因为它不会有任何报错功能完全正常只是修复没生效。改完之后可以用sshd -T | grep -i subsystem确认实际生效的值。顺带说一个割接期的小技巧在sshd_config里临时加一行Port 2222这样 22 和新端口同时监听验证阶段可以用新端口连确认没问题后再把这一行删掉重启。多一条退路心里踏实很多。4.4 用 systemd 接管与最终校验CentOS7 原装的/usr/lib/systemd/system/sshd.service内容大致是ExecStart/usr/sbin/sshd -D $OPTIONS因为我们把新二进制装到了/usr/sbin/sshd所以这个 unit 不需要改。但如果你之前手动改过 unit 里的路径记得改回来并执行systemctl daemon-reload。# 8. 重载并重启务必在第二条会话中操作 systemctl daemon-reload systemctl restart sshd systemctl status sshd # 9. 检查监听端口 ss -lntp | grep sshd # 10. 手工校验服务端 banner timeout 2 bash -c exec 3/dev/tcp/127.0.0.1/22; head -1 3最后那条命令输出的是SSH-2.0-OpenSSH_9.8这样的字符串。这个 banner 是漏扫工具真正读取的内容所以它才是整改是否生效的最终判据而不是ssh -V。看到 banner 变了这件事才算做成了一半。5. 割接验证不把门锁死的操作纪律前面所有工作都是为了这一刻。割接的原则只有一条在你能够确认新服务完全正常之前不要破坏当前这条可用的连接。5.1 永远开两条连接具体做法是先用会话 A 登录目标机做完systemctl restart sshd。此时会话 A 通常不会被踢掉因为 sshd 收到重启信号后已经建立的子进程会继续存活到会话结束。但会话 A 里能执行命令不代表新连接能建立这两个是完全独立的事情。所以真正有意义的验证是在会话 B 里做的从另一台机器或者同机的另一个窗口发起一次全新的连接。如果会话 B 能正常建立说明新 sshd 工作正常可以放心关闭会话 A。如果会话 B 连不上会话 A 还在你有充足的时间去看日志、改配置、甚至回滚。5.2 一份可以照着执行的验证清单验证项命令或方法期望结果版本号ssh -V显示新版本不再是 7.4p1服务端 banner主动连接 22 端口读取首行SSH-2.0-OpenSSH_9.x监听状态ss -lntp | grep sshd22 端口处于 LISTEN密钥登录用已有私钥ssh -i key userhost免密登录成功密码登录新开会话用密码登录成功且 PAM 相关策略生效SFTP 通道sftp userhost上传下载各一次操作正常sshd -T里的 subsystem 指向新路径scp 传输scp双向各传一个中等大小文件成功且速度无明显退化算法协商ssh -vvv查看协商日志使用 sha2 系列签名未回落到 ssh-rsa主机密钥指纹客户端首次连接查看指纹与升级前一致未变日志journalctl -u sshd -n 100无 error 级别的异常记录这张表里最容易被跳过的是主机密钥指纹和算法协商这两项。前者关系到所有客户端会不会集体报指纹告警后者关系到你的客户端到底用的是安全算法还是被迫回落到了 SHA-1。两边都确认一下才算真正完成。5.3 老客户端会不会连不上这是升级后最集中的问题来源因为服务端变新了客户端没变。常见的几个现象和对策no matching key exchange method found服务端默认的密钥交换算法集合里去掉了客户端支持的旧算法比如diffie-hellman-group1-sha1。如果对面是网络设备或者很老的嵌入式系统短期可以在服务端加回KexAlgorithms diffie-hellman-group14-sha1但一定要配合访问控制只对必要的来源放行不要全网开放。no matching host key type found服务端只有 ed25519 和 rsa 密钥而客户端只认ssh-rsa。这种情况通常出在几年前的 Java 应用或老版本 Ansible 上。no mutual signature algorithm客户端用 RSA 私钥认证但服务端已经不允许ssh-rsaSHA-1签名。正确的做法是把客户端升级到支持rsa-sha2-256的版本迫不得已时才在服务端临时加PubkeyAcceptedAlgorithms ssh-rsa并在整改计划里标注这项待清理。DSA 密钥完全失效如果你手上还有ssh-dss类型的密钥新版默认已经不再接受。这时候不要再想办法恢复兼容直接用ssh-keygen -t ed25519或ssh-keygen -t rsa -b 3072重新生成顺手把这块技术债清掉。5.4 万一要回滚按这个顺序来回滚的目标是用最短时间恢复可用状态所以不要在现场研究配置按下面的顺序机械执行systemctl stop sshd cp -a $BK/sshd.bin-* /usr/sbin/sshd cp -a $BK/sshd_config /etc/ssh/sshd_config cp -a $BK/ssh_host_* /etc/ssh/ # 如果密钥被改过才需要 systemctl start sshd ss -lntp | grep sshd回滚之后第一件事不是分析原因而是确认业务侧已经恢复正常。原因分析可以放到事后把现场日志journalctl -u sshd和当时的sshd_config一起归档再慢慢比对。我踩过一次坑现场急着排错结果重启了两次把 journal 冲掉了最后只能靠猜教训挺深的。6. 从单台到整个机房自建 RPM 与灰度落地单台机器成功了剩下的就是规模问题。如果资产不超过三台手工做完全没问题一旦到了十几台以上就必须解决怎么保证每台的配置和二进制完全一致这个问题。6.1 用 fpm 快速产出 RPM 包自己写 spec 文件当然可以但更省事的办法是用 fpm 把编译好的文件直接打成包。先把新版本的二进制集中到一个临时目录模拟安装树的布局mkdir -p /tmp/sshpayload/usr/{bin,sbin,libexec} cd /usr/local/src/openssh-9.8p1 cp ssh ssh-add ssh-agent ssh-keygen ssh-keyscan scp sftp /tmp/sshpayload/usr/bin/ cp sshd /tmp/sshpayload/usr/sbin/ cp sftp-server ssh-keysign /tmp/sshpayload/usr/libexec/然后打包注意关掉自动依赖计算否则 fpm 生成的依赖关系可能和你环境里的包名对不上fpm -s dir -t rpm -n openssh-custom -v 9.8p1 --iteration 1.el7 \ --rpm-autoreqprov false \ --rpm-os linux \ --description OpenSSH 9.8p1 built for CentOS7 \ -C /tmp/sshpayload \ usr/bin usr/sbin usr/libexec打出来的包在分发时有个好处rpm -q openssh-custom能直接查到版本几十台机器到底哪台升了哪台没升一条命令就能盘出来。这比在一堆机器上挨个执行ssh -V靠谱得多。一个必须注意的细节这个自定义包不要用--replacefiles去硬盖原生的openssh包两个包的文件路径重叠会在安装时报冲突。正确做法是先写好excludeopenssh*然后用rpm -Uvh --replacefiles单独装自定义包或者干脆在装机模板里就把原生 openssh 排除掉。我见过因为文件冲突导致 rpm 数据库半损坏的情况修起来挺痛苦的。6.2 用 Ansible 做灰度别一次全推批量执行的核心不是快而是可控。我的做法是把机器按业务重要性分成三批每批之间隔一段时间观察- hosts: ssh_wave1 serial: 5 max_fail_percentage: 0 tasks: - name: 备份关键文件 shell: | BK/root/ssh-bk-{{ ansible_date_time.date }} mkdir -p $BK cp -a /etc/ssh/sshd_config $BK/ cp -a /etc/ssh/ssh_host_* $BK/ - name: 分发 RPM copy: srcopenssh-custom-9.8p1-1.el7.x86_64.rpm dest/tmp/ - name: 安装 yum: name/tmp/openssh-custom-9.8p1-1.el7.x86_64.rpm statepresent notify: restart sshd handlers: - name: restart sshd service: namesshd staterestartedserial: 5是关键它保证每次只动五台max_fail_percentage: 0保证一旦有机器失败就立即停下整个批次。这套组合能在问题扩大之前就把你拦住。还有一个实操细节批量任务里绝对不要用--forks开太大并发。SSH 服务重启的瞬间控制端和目标端之间的连接会经历一次震荡并发过高时控制端本身就容易出问题反而制造出一批假故障。6.3 别忘了把 yum 源锁死批量升级完最容易出的事故是某个同学后来手工执行了一次yum update然后发现 SSH 版本又掉回 7.4p1 了。这个问题的根因在于原生openssh包可能还留在系统里或者某个依赖把它又拉了回来。防护措施有两层。第一层是/etc/yum.conf里加excludeopenssh* openssh-custom第二层是把自定义包和原生包的关系理清——如果原生包还在rpm -q openssh会显示它rpm -V openssh会因为文件被覆盖而报一堆失败。这时候可以选择rpm -e --nodeps openssh卸掉原生包前提是自定义包已经把文件都提供齐了让 rpm 数据库干净一些。这一步有风险做之前务必确认自定义包里包含了原生的全部关键文件否则卸载会连带删掉文件。7. 升级完成之后才暴露的问题算法收敛与遗留配置很多同学以为版本号变了就万事大吉实际上真正的麻烦往往在升级后的两三天里陆续冒出来因为这时候业务侧才开始用各种边角场景来试探这台机器。7.1 从sshd -T开始做一次配置体检新版本有一套自己的默认值所以你原来的配置文件里没写的东西实际生效的是新默认值。用sshd -T把所有有效配置 dump 出来看一遍sshd -T | sort /tmp/sshd-effective-new.txt然后重点检查这几项permitrootlogin现在是prohibit-passwordpubkeyacceptedalgorithms里已经没有ssh-rsa和ssh-dssciphers和macs的列表也比以前窄了。这些变化是好事但你要知道它们变了才能提前应对业务侧的报错。7.2 密码登录还是要收敛掉趁这次升级我一般会顺手把密码登录关掉。理由很直接CentOS7 上跑的那些机器账号密码往往是多年前设置的弱口令而且密码登录本身就是暴力破解的主要入口。关掉之后外部攻击面会明显收窄。操作上不建议一步到位先用两阶段过渡第一阶段在sshd_config里保留PasswordAuthentication yes但加上Match段对特定来源限制第二阶段确认所有自动化流程都改用密钥之后再全局改成no。改之前先把所有自动化脚本里的登录方式盘一遍尤其是那些在 crontab 里跑的备份脚本它们失败的时候是静默的等到需要恢复备份才发现连不上就晚了。7.3 日志、审计与登录失败的处理升级后journalctl -u sshd的输出格式会有些变化如果你们有日志采集规则是基于旧格式做正则匹配的可能需要同步调整。我遇到过一次日志平台突然告警SSH 日志量下降查了半天发现是日志里字段顺序变了采集规则没匹配上实际服务一直是好的。另外登录失败频次统计这类脚本要注意新版本对认证失败的记录粒度更细一次失败的尝试可能产生多条日志。如果你的脚本是按行数做阈值判断的阈值需要重新评估否则会误报。8. 排查链路实录几个真实踩过的报错这一节不讲理论只讲我实际遇到过的报错长什么样、我是怎么一步步缩小范围找到原因的。这些报错的共同特点是出错信息本身很有误导性真正的根因往往在别的地方。8.1Bad configuration option导致 sshd 起不来现象是systemctl restart sshd之后status显示failed日志里是一行Bad configuration option: UsePrivilegeSeparation。这个报错很直白直接把它注释掉就行。但真正有意思的是它的连带效应sshd因为配置错误直接退出此时如果你是从 SSH 会话里执行的重启那个会话虽然还在但一旦断开就无法重连而 systemd 在几秒钟内可能已经重试了若干次并把服务标记为 failed。排查链路是这样的先看journalctl -u sshd -n 50找到具体是哪一行报的错然后grep -n定位配置文件行号逐条处理完再sshd -t校验。这个过程可能会反复几轮因为旧配置里往往不止一个已移除的选项。所以我现在的习惯是在make install之后、systemctl restart之前先用sshd -t -f /etc/ssh/sshd_config把错误全清掉把生效前的校验和生效动作彻底分开。8.2 privsep 目录权限不对引发的模糊报错现象是重启后 sshd 启动即退出日志里是Privilege separation user sshd does not exist或者Missing privilege separation directory: /var/empty/sshd。有意思的是这个报错并不是权限问题而是目录压根没建。根因在于源码编译的 OpenSSH 不像 RPM 那样有%post脚本帮你自动创建 privsep 目录。CentOS7 的 RPM 在安装时会通过脚本创建/var/empty/sshd并设置好属主和权限而make install不会做这件事。所以你在configure里指定了--with-privsep-path/var/empty/sshd之后必须自己手工建目录。正确的权限是root:root加711。这个组合的意图是其他用户需要能穿过这个目录去访问里面的东西但不能列出目录内容也不能在里面创建文件。如果你设成755sshd 启动时会警告目录权限过于宽松并拒绝运行设成700某些情况下又会因为无法进入而报错。8.3 PAM 相关密码验证过了但账号还是被拒现象是密钥登录一切正常密码登录输对了密码还是被拒日志里是Failed password或者干脆没有任何相关记录。这种时候问题通常不在 sshd 本身而在 PAM 链路。排查思路是从sshd_config里的UsePAM选项开始。新版本编译时如果带了--with-pamUsePAM yes才有效如果编译时没带这个参数而配置里写了UsePAM yessshd 会报错或者静默忽略导致密码认证走的是内部实现而不是 PAM你精心配的双因素策略、账号锁定策略全部失效。还有一个细节是/etc/pam.d/sshd里引用的模块路径。CentOS7 上常见的写法是auth include password-auth这种相对引用在新版里依然有效。但如果你的配置里写了绝对路径指向某个第三方模块那个模块可能因为 ABI 变化而加载失败。8.4 SELinux 与文件上下文现象是sshd -t通过直接执行/usr/sbin/sshd -D也能跑但通过 systemd 启动就失败日志里是Permission denied或者cannot execute。这种直接跑可以systemd 跑不行的差异八成是 SELinux 的问题。原因是make install新写入的二进制文件其 SELinux 上下文是继承父目录的不一定是sshd_exec_t。修复方式很直接restorecon -Rv /usr/sbin/sshd /usr/bin/ssh /usr/libexec/sftp-server restorecon -Rv /etc/ssh ls -Z /usr/sbin/sshd # 确认上下文是 sshd_exec_t如果ls -Z显示的是default_t或者usr_t那就说明上下文确实不对restorecon之后重新启动服务即可。这个坑在图形化安装的 CentOS7 上更常见因为那种环境通常开着 Enforcing 模式。8.5no hostkeys available -- exiting现象是 sshd 完全不启动日志里就一句话no hostkeys available -- exiting。这个报错的原因是服务端现有的主机密钥里没有任何一种被新版本接受。老机器上如果只有ssh_host_dsa_key或者只有ssh_host_rsa_key但新版本要求 RSA 密钥长度至少 1024 位更严格的情况是 2048 位以上就会触发这个错误。处理方式是生成新的主机密钥同时保留已有的 RSA 密钥ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ssh-keygen -t rsa -b 3072 -f /etc/ssh/ssh_host_rsa_key_new -N 生成完记得把权限设对私钥600公钥644。至于要不要替换掉原有的 RSA 密钥取决于客户端兼容性——ssh_host_rsa_key是给老客户端用的最后一道兼容底线如果确认环境里全是新客户端换成 3072 位更安全如果有老设备保留原来的也行反正 RSA 只是能用而不是最好。9. 一些零散但很关键的经验主机密钥的备份我一般会额外存两份一份在本地备份目录一份推到内网的配置管理仓库里。因为升级过程中如果手滑把/etc/ssh/ssh_host_*删了本地备份也跟着被覆盖的情况虽然概率低但一旦发生就是全量客户端告警的级别多一份异地备份的成本几乎为零。编译时间点的选择也有讲究。如果同一批机器要批量升级建议先在一台与生产环境配置最接近的机器上完整走一遍把./configure的输出、make的警告、sshd -t的结果全部存档。这套样板记录在后续排查时价值极高因为你能一眼看出某台机器的编译输出和样板有什么不同而不同点往往就是问题的所在。最后一个是关于时间窗口的判断。升级 OpenSSH 这件事本身只需要几分钟但验证和观察期需要按小时算。我的习惯是升级完成后至少观察一个完整业务周期比如覆盖一次日终批处理确认没有静默失败的任务再宣布这件事结束。曾经有一次就是升级完当天一切正常第二天凌晨的备份任务因为 scp 行为变化失败了幸好有观察期兜住。至于版本选择我的建议是不要盲目追最新。选一个已经有较长时间公开使用、社区反馈稳定的版本比如 9.8p1 这个修复了 regreSSHion 的分界线版本比追 10.x 的最新小版本要稳妥得多。新版本出来头一两个月往往还会有细节问题被陆续发现生产环境没必要去当第一批吃螃蟹的人。