SSH 是运维日常里绕不开的东西登录、传文件、跑批量脚本全靠它。但很多机房里的机器还停留在系统自带的老版本 OpenSSH 上安全扫描一跑就是一堆告警甲方或者内部合规那边催着升级。我最近刚在一批 CentOS 7.9 的机器上把 OpenSSH 从系统自带的 7.4p1 升到了 9.6p1整个过程踩了不少坑也总结出一套比较稳的做法。这篇就把完整的升级流程、每一步背后的原因、以及那些文档里不会写的注意事项摊开讲清楚适合有一定 Linux 基础、需要给老系统做 OpenSSH 升级的运维同学参考。升级 OpenSSH 这件事说难不难说简单也绝对不简单——它牵扯到 PAM、SELinux、systemd 服务单元、密钥权限、以及最要命的升级过程中 SSH 连接断了怎么办。下面按我实际操作的顺序一步步拆。1. 动手之前为什么升级 OpenSSH 不能像装个软件那样随意很多人第一反应是yum update openssh结果发现源里根本没有 9.6p1 这个版本CentOS 7.9 官方源最高也就到 7.4p1 的补丁版本。想上 9.6p1只能自己编译。而一旦走上编译这条路就意味着你要亲手接管这个系统最核心的远程访问服务任何一步出错都可能导致机器失联。所以在敲第一条命令之前得先把几个关键认知建立起来。1.1 升级 OpenSSH 到底在升级什么OpenSSH 不是一个孤零零的二进制文件它是一整套组件sshd守护进程、ssh客户端、scp、sftp、ssh-keygen、ssh-agent等等。编译安装时这些都会被替换。但系统里还有一堆东西跟它耦合PAM 认证模块、systemd 的sshd.service单元、/etc/pam.d/sshd配置、SELinux 策略、以及sshd_config这个配置文件本身。升级的本质是用新版本的二进制替换旧的同时保证这些周边依赖仍然能正常工作。我见过有人只替换了/usr/sbin/sshd一个文件结果新版本对 PAM 的调用方式和旧配置不兼容直接导致所有用户无法登录。所以正确的思路是把 OpenSSH 当成一个需要整体迁移的服务来对待而不是替换一个可执行文件。编译时的--with-pam、--with-selinux、--with-ssl-dir这些参数决定了新版本能不能和系统现有的认证、安全机制对接上这些参数一个都不能少。1.2 为什么必须保留一条退路这是整个升级过程中最重要的一条原则在你确认新版本稳定运行之前绝对不能让自己失去对机器的控制权。SSH 是远程登录的唯一通道大多数情况下一旦新 sshd 起不来、或者配置有误导致无法认证你就只能去机房接显示器或者提工单让机房人员帮忙——这在云环境或者托管机房里可能意味着几小时的业务中断。所以我的做法是升级全程保持至少一个已登录的 SSH 会话不关闭同时开一个telnet或者带外管理IPMI、云控制台的 VNC作为第二通道。更稳妥的是先在测试机上完整跑一遍确认没问题再上生产。另外升级前一定要备份/etc/ssh整个目录和旧的二进制文件这样万一新版本有问题能在几分钟内回滚。后面我会专门讲回滚的具体操作。1.3 版本选择与依赖确认9.6p1 依赖 OpenSSLCentOS 7.9 自带的是 OpenSSL 1.0.2k。OpenSSH 9.6p1 对 OpenSSL 的最低要求是 1.0.1所以系统自带的版本是够用的不需要额外升级 OpenSSL——这一点很重要因为升级 OpenSSL 的风险比升级 OpenSSH 还大能不动就不动。编译前先确认一下openssl version # 输出应为 OpenSSL 1.0.2k-fips 之类另外确认zlib和pam-devel这些开发包是否已安装编译时需要rpm -qa | grep -E zlib-devel|pam-devel|openssl-devel缺哪个补哪个用yum install -y zlib-devel pam-devel openssl-devel即可。这里有个细节CentOS 7.9 的openssl-devel提供的是 1.0.2k 的头文件编译 OpenSSH 9.6p1 时能正常链接但如果你的环境里装过其他版本的 OpenSSL比如自己编译过 1.1.1就可能出现头文件和库版本不一致的链接错误这时候要用--with-ssl-dir明确指定路径。2. 编译安装的完整链路从源码到可用的 sshd这一节是实操的核心。我把整个编译安装拆成准备目录、配置参数、编译、安装、处理配置文件几个阶段每个阶段都说明为什么这么做。2.1 备份把能回滚的东西先固定下来在动任何东西之前先做备份。这不是走流程而是真的会在关键时刻救命# 备份配置目录 cp -r /etc/ssh /etc/ssh.bak.$(date %F) # 备份旧二进制rpm 安装的路径 cp /usr/sbin/sshd /usr/sbin/sshd.bak cp /usr/bin/ssh /usr/bin/ssh.bak # 记录当前版本方便回滚后核对 ssh -V 21 | tee /root/ssh_version_before.txt/etc/ssh.bak.日期这个命名方式我比较推荐因为升级后如果发现配置有问题直接diff -r /etc/ssh /etc/ssh.bak.xxx就能看出新版本改了哪些默认配置。另外如果你是用 rpm 装的系统自带版本还可以用rpm -qf /usr/sbin/sshd确认它属于哪个包回滚时用rpm -Uvh --force重装对应 rpm 包即可比手动拷二进制更干净。2.2 编译参数每一个 --with 都是在给新版本接线下载源码包后解压进入目录执行./configure。这一步的参数决定了新 sshd 具备哪些能力我用的配置是这样的./configure \ --prefix/usr \ --sysconfdir/etc/ssh \ --with-pam \ --with-zlib \ --with-ssl-dir/usr \ --with-md5-passwords \ --with-privsep-path/var/empty/sshd \ --without-openssl-header-check逐个解释一下为什么这么配--prefix/usr让新版本安装到系统标准路径覆盖旧的/usr/bin/ssh、/usr/sbin/sshd这样 systemd 的sshd.service不用改路径就能启动新版本。--sysconfdir/etc/ssh配置文件仍然读/etc/ssh/sshd_config保持和系统一致。--with-pam必须加。CentOS 的登录认证走 PAM不加这个参数编译出来的 sshd 不认 PAM会导致密码登录全部失败。--with-zlib启用压缩传输不加的话 scp 大文件会慢一些。--with-ssl-dir/usr明确指定 OpenSSL 路径避免链接到错误的库。--with-md5-passwords兼容一些老系统用 MD5 存储的密码哈希虽然现在用得少但加上没坏处。--with-privsep-path/var/empty/sshd指定权限分离的 chroot 目录这个目录必须存在且属主正确否则 sshd 启动会报错。--without-openssl-header-check跳过 OpenSSL 头文件版本检查因为 CentOS 7.9 的 OpenSSL 版本号格式有时会触发误报加上这个参数能避免编译中断。提示--with-privsep-path指定的目录要提前建好mkdir -p /var/empty/sshd chmod 711 /var/empty/sshd属主保持 root。这个细节很多人忽略结果 sshd 启动时报 Privilege separation user sshd does not exist 或者目录权限错误。2.3 编译与安装注意 make install 会覆盖什么配置完成后执行make make install。编译过程一般几分钟取决于机器性能。这里要特别提醒make install会直接覆盖/usr/bin/ssh、/usr/sbin/sshd等文件但不会自动处理配置文件。也就是说你原来的/etc/ssh/sshd_config还在新版本启动时会读它。这就带来一个兼容性问题9.6p1 对一些配置项的默认值和 7.4p1 不同某些旧配置项可能已经废弃或者语义变了。安装完成后先别急着重启 sshd用新二进制检查一下配置文件的语法/usr/sbin/sshd -t如果输出为空说明配置语法没问题如果有报错根据提示改sshd_config。常见的报错包括UsePrivilegeSeparation这个配置项在 9.x 里已经彻底移除如果旧配置里有这行会报 Bad configuration option直接注释掉即可。还有Protocol 2这种老配置新版本也不认了一并清理。2.4 处理 sshd_config 的兼容性改动9.6p1 相比 7.4p1配置文件层面有几个需要注意的变化我整理成表格方便对照配置项7.4p1 行为9.6p1 行为处理建议UsePrivilegeSeparation可配置 yes/no/sandbox已移除强制启用注释掉该行Protocol可配 1/2已移除仅支持 2注释掉该行RSAAuthentication可配置已移除注释掉该行PubkeyAcceptedKeyTypes支持改名为PubkeyAcceptedAlgorithms按需改名ChallengeResponseAuthentication支持改名为KbdInteractiveAuthentication按需改名PermitRootLogin默认 yes默认 prohibit-password显式配置避免意外这里重点说PermitRootLogin。7.4p1 默认允许 root 用密码登录而 9.6p1 默认是prohibit-password也就是 root 只能用密钥登录。如果你的运维习惯是 root 密码登录升级后会发现登不进去还以为是升级失败。所以升级前一定要在sshd_config里显式写清楚PermitRootLogin yes或者PermitRootLogin prohibit-password别依赖默认值。另外PubkeyAcceptedKeyTypes改名这件事如果你的配置里显式指定了算法列表比如为了兼容老客户端升级后要改成PubkeyAcceptedAlgorithms否则新版本会忽略这行导致某些密钥类型认证失败。这个坑我在一台对接老跳板机的机器上踩过现象是密钥明明配了却一直提示认证失败排查了半天才发现是配置项名字变了。3. 服务接管与重启最危险的那几分钟编译安装完成、配置也改好了接下来就是重启 sshd 让新版本生效。这一步是整个升级过程中风险最高的环节因为一旦新 sshd 起不来你的现有连接虽然不会立刻断已建立的会话通常还能维持但新连接就进不来了。所以这一节重点讲怎么安全地完成切换。3.1 先确认 systemd 单元指向的是新二进制CentOS 7.9 的sshd.service单元文件里ExecStart通常是/usr/sbin/sshd -D $OPTIONS。因为我们把新版本装到了/usr前缀路径没变所以单元文件不用改。但保险起见还是确认一下systemctl cat sshd | grep ExecStart如果显示的是/usr/sbin/sshd那就没问题。有些环境里 sshd 是通过/etc/rc.d/init.d/sshd这种老式脚本管理的那就需要确认脚本里调用的路径。确认无误后先做一次配置语法检查用新二进制再重启/usr/sbin/sshd -t systemctl restart sshd3.2 重启后立刻验证的三件事重启命令敲下去之后不要关掉当前会话立刻在另一个终端或者当前终端新开一个窗口做三件事验证新连接能建立ssh -p 22 用户名本机IP确认能正常登录。验证版本号ssh -V应该显示OpenSSH_9.6p1。验证认证方式分别测试密码登录和密钥登录如果你两种都用确认 PAM 认证正常。我习惯用ssh -vvv看详细握手过程确认协商的算法、认证方式都符合预期。如果新连接失败但旧会话还在那就还有救——直接在旧会话里回滚把备份的二进制拷回去重启服务。这就是为什么前面强调保留一条退路。3.3 一个容易被忽略的点sshd 的 host key 权限新版本 sshd 对 host key 文件的权限检查比旧版本严格。如果/etc/ssh/ssh_host_*_key的权限过于宽松比如 644新版本会拒绝启动并报 bad permissions。正确的权限是chmod 600 /etc/ssh/ssh_host_*_key chmod 644 /etc/ssh/ssh_host_*_key.pub这个坑很隐蔽因为旧版本可能容忍 644升级后突然起不来日志里就一行 permissions 报错不仔细看容易懵。升级前顺手把权限修正一遍能省不少事。4. 升级后的收尾与那些升级完才发现的问题新版本跑起来、能正常登录不代表事情就结束了。9.6p1 在算法策略、默认行为上有不少变化这些变化可能在你升级后几天才暴露出来比如某个自动化脚本突然连不上了、某个老客户端认证失败了。这一节把常见的后续问题和收尾动作讲清楚。4.1 算法策略收紧带来的兼容性问题OpenSSH 从 8.x 开始逐步废弃了一批老算法到 9.6p1像ssh-rsaSHA-1 签名、diffie-hellman-group1-sha1这些都已经默认禁用。如果你的环境里还有老设备、老客户端比如一些网络设备、老版本的自动化工具依赖这些算法升级后它们会连不上报 no matching key exchange method 或 no matching host key type。解决办法是在sshd_config里显式放开需要的算法但要权衡安全性和兼容性# 仅在确有老客户端需求时添加并尽量缩小范围 HostKeyAlgorithms ssh-rsa PubkeyAcceptedAlgorithms ssh-rsa KexAlgorithms diffie-hellman-group14-sha1我的建议是先不加等真的出现兼容性问题再加并且加完记录在案。因为每放开一个老算法就多一分安全风险能推动客户端升级的尽量推动升级而不是在服务端无脑放开。4.2 密钥登录的算法协商细节9.6p1 对密钥类型的选择更严格。如果你用的是 RSA 密钥且密钥是用老方式生成的比如 1024 位新版本可能拒绝使用。检查一下现有密钥的位数ssh-keygen -l -f ~/.ssh/id_rsa如果显示 1024 位建议重新生成 2048 位或 4096 位的密钥。另外9.6p1 默认优先使用 Ed25519 密钥如果客户端支持迁移到 Ed25519 是更好的选择性能和安全性都更优。迁移时注意新密钥要提前分发到所有需要登录的机器上确认能用之后再删旧密钥别一上来就把旧的删了。4.3 日志与监控的调整升级后 sshd 的日志格式和内容可能有细微变化如果你有基于日志的监控告警比如监控登录失败次数需要确认解析规则还适用。9.6p1 在日志里会记录更多算法协商的细节某些正则可能需要调整。我一般会在升级后观察一两天日志确认没有异常的大量认证失败或者连接拒绝再把这台机器从观察名单里移出去。另外systemctl status sshd的输出里新版本启动时会打印版本号可以据此快速确认运行的是不是新版本。如果发现重启后版本号还是旧的多半是 systemd 缓存或者路径问题用systemctl daemon-reload刷新一下再重启。4.4 回滚预案真出问题了怎么快速退回去尽管前面做了各种准备还是要有一套明确的回滚流程。回滚的核心就是把备份的旧二进制和配置恢复回去# 停服务 systemctl stop sshd # 恢复旧二进制 cp /usr/sbin/sshd.bak /usr/sbin/sshd cp /usr/bin/ssh.bak /usr/bin/ssh # 恢复旧配置如果改过 cp -r /etc/ssh.bak.xxxx/* /etc/ssh/ # 启动服务 systemctl start sshd # 验证 ssh -V回滚的关键是快所以备份文件要放在固定、好找的位置回滚命令最好提前写成脚本放在手边。我通常会在升级前就把回滚脚本写好升级时如果 5 分钟内新连接还建立不起来直接执行回滚不纠结。5. 一些值得提前知道的实操心得做了这么多台机器的升级有些经验是文档里不会写、但实际很影响效率的单独拎出来说说。第一批量升级时不要并行全量推。我一般先挑一台非核心机器做小白鼠完整跑一遍升级、验证、观察一天确认没问题后再分批推。批量操作时用配置管理工具比如 Ansible跑但每批之间留出验证窗口别一口气全推完。第二升级前确认有没有其他服务依赖旧版 SSH 的特定行为。比如某些备份脚本、监控采集器可能硬编码了 SSH 的某些参数或算法升级后行为变化会导致它们失败。提前 grep 一下相关脚本里的 ssh 调用心里有数。第三注意/etc/ssh下 moduli 文件的处理。9.6p1 自带新的 moduli 文件make install时如果覆盖了旧的某些依赖特定 DH 组的客户端可能受影响。一般不用管但如果遇到 DH 协商失败可以检查这个文件。第四SELinux 环境要额外确认。如果系统开了 SELinux enforcing新编译的 sshd 二进制可能没有正确的安全上下文导致启动失败。用restorecon -Rv /usr/sbin/sshd /usr/bin/ssh恢复上下文或者临时setenforce 0验证是不是 SELinux 的问题。生产环境不建议长期关 SELinux恢复上下文才是正解。第五记录升级前后的版本和配置差异。我会在每台机器上留一个升级记录文件写清楚升级时间、版本变化、改了哪些配置、遇到过什么问题。下次再升级或者排查问题时这份记录能省大量时间。这套流程我在多台 CentOS 7.9 上跑下来整体比较稳关键是每一步都想清楚如果这里出问题我怎么退回去。OpenSSH 升级本身不复杂复杂的是对风险的把控——把退路留好把兼容性想全剩下的就是按部就班执行。
