1. 升级前的环境巡检与方案确认1.1 为什么要升到 OpenSSH 9.8p1OpenSSH 9.8p1 这个版本说真的只要你管过线上服务器就绕不开它。2024年7月OpenSSH官方放出这个版本核心原因是修复了一个叫 regreSSHion 的高危漏洞CVE-2024-6387。这个漏洞出在 sshd 的信号处理器上属于信号处理器竞态条件攻击者不需要账号密码只要网络能到达你的22端口就有机会在目标机器上执行任意代码。这可不是闹着玩的公网暴露过22端口的机器基本都在风险名单里躺着。我见过不少运维同学看到安全扫描报告里写着“OpenSSH版本过低”就开始焦虑然后随手yum update openssh草草了事。但问题是很多老系统比如 CentOS 7、Ubuntu 18.04的官方源里根本没有 9.8p1就算有也大概率是打了补丁的旧版本版本号看不出实质性变化。所以最稳妥的做法就是源码编译升级把版本彻底拉到一个安全线以上。另外一个现实点的问题是OpenSSH 是远程管理的生命线一旦升级过程中出问题最坏的结果就是远程连不上机器只能跑去机房或者让云厂商的VNC兜底。所以这篇文章不只是教你怎么编译安装更是把我的完整操作流程、备份策略、排错记录全部摊开给你看照着一路敲命令就行。1.2 升级前必须完成的备份与保底方案升级之前先花十分钟确认环境状态这个时间花得绝对值。我的检查顺序是确认系统版本和当前 OpenSSH、OpenSSL 版本。确认有没有装 gcc、make、perl、pam-devel 等编译必需组件。确认是不是多用户环境、有没有其他服务依赖系统自带的 sshd。如果有条件先开一个 telnet 服务做保底通道或者至少保持两个已登录的 SSH 会话别关。先说版本确认命令就三条cat /etc/os-release ssh -V openssl version以我手上一台 CentOS 7.9 为例输出大概是这样的CentOS Linux release 7.9.2009 (Core) OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017 OpenSSL 1.0.2k-fips 26 Jan 2017看到这个输出你就知道问题有多严重了。7.4p1 的 sshd 既有 regreSSHion 漏洞底层的 OpenSSL 也是 1.0.2 老古董一堆已知CVE挂在上面。这种环境下安全扫描不给你标红才奇怪。备份这一步我用的是最朴素的cp -rf方案cp -rf /etc/ssh /etc/ssh.bak.$(date %Y%m%d) cp /usr/sbin/sshd /usr/sbin/sshd.bak.$(date %Y%m%d) cp /usr/bin/ssh /usr/bin/ssh.bak.$(date %Y%m%d) cp /etc/init.d/sshd /etc/init.d/sshd.bak.$(date %Y%m%d) 2/dev/null为什么要连 ssh 客户端、sshd 服务端的二进制一起备份因为升级过程中如果发现新版和业务脚本不兼容比如有些自动化脚本依赖老版本的行为你还能一键切回来。配置文件更不能大意尤其sshd_config里面可能有你或者前任运维调了半天的参数千万别用默认配置直接覆盖。注意升级前先确认有没有正在运行的关键会话。如果这台机器上挂着数据库迁移、日志归档之类的长任务建议等任务跑完再动手或者至少开一个 screen/tmux 窗口兜底。1.3 安装编译依赖包OpenSSH 和 OpenSSL 都是 C 写的编译过程中需要一堆开发库。不同系统的包管理命令不一样但逻辑一样就是把编译工具链和头文件装齐。CentOS/RHEL 系yum install -y gcc gcc-c make perl wget yum install -y zlib-devel pam-devel openssl-develDebian/Ubuntu 系apt update apt install -y build-essential make gcc perl wget apt install -y zlib1g-dev libpam0g-dev libssl-dev这里特别说一下pam-devel一定要装否则编译 OpenSSH 时即使你加了--with-pam参数也有概率编译通过但运行时报 PAM 相关的动态库错误。我后面在排错部分会专门讲这个坑现在先提个醒。另外CentOS 6 这种老系统上可能没有高版本的 make编译 OpenSSL 1.1.1w 需要 make 3.81 以上基本上默认版本就够了。如果你用的是极简安装的容器镜像可能连which、grep都缺先用yum install -y which grep sed补上再说。2. OpenSSL 升级先解决底层依赖2.1 为什么 OpenSSH 升级非要动 OpenSSL很多人不理解我明明是升级 OpenSSH为什么要先去编译 OpenSSL原因很简单OpenSSH 是构建在 OpenSSL 之上的它的加密、密钥交换、证书解析都依赖 OpenSSL 提供的 libcrypto、libssl 动态库。你可以把 OpenSSH 想象成一辆车OpenSSL 就是发动机。你光换个新外壳OpenSSH 源码发动机还是老旧的跑起来要么响警报版本不兼容要么直接歇菜缺少符号。我在升级 OpenSSL 前也纠结过能不能跳过 OpenSSL 直接编 OpenSSH 9.8p1实测下来如果你系统自带的 OpenSSL 版本足够新至少 1.1.1确实可以跳过。但在 CentOS 7、Ubuntu 18.04 这种默认 OpenSSL 1.0.2 或 1.1.0 的系统上OpenSSH 9.8p1 的 configure 阶段就会直接报警告甚至报错退出。所以我的建议是既然都决定源码升级了就顺手把 OpenSSL 也升到 1.1.1 系列的最新版一步到位省得后面又冒出各种奇奇怪怪的“版本 mismatch”问题。2.2 OpenSSL 源码编译安装步骤OpenSSL 1.1.1 是 LTS 版本生命周期到 2023 年 9 月结束不过在实际运维环境里1.1.1w 依然有大量服务器在用稳定性久经考验。如果你想体验新特性也可以上 OpenSSL 3.x但考虑到兼容性和排查成本我推荐 1.1.1w尤其是你第一次做升级操练。下载地址我习惯从官网直接拉cd /usr/local/src wget https://www.openssl.org/source/openssl-1.1.1w.tar.gz tar -xzf openssl-1.1.1w.tar.gz cd openssl-1.1.1w编译配置里--prefix和--openssldir这两个参数很关键。--prefix决定安装目录--openssldir决定证书、配置文件等数据的存放位置。我统一装到/usr/local/openssl这样后续 OpenSSH 编译时--with-ssl-dir直接指向这里即可逻辑清晰卸载也好办直接删目录。./config --prefix/usr/local/openssl --openssldir/usr/local/openssl shared zlib make -j$(nproc) make installshared这个参数务必保留它表示生成动态库.so而不是全部静态链接。zlib是启用压缩支持如果系统里没装 zlib-devel就把这个参数去掉否则编译会报头文件缺失。编译时间看机器性能一般 5 到 15 分钟。如果用了-j$(nproc)并行编译中途报错的话先查是不是内存不足把-j的并发数调低再试比如make -j2。装完之后不要急着高兴还有一步很关键把新的 OpenSSL 库文件路径加入系统的动态链接库缓存里否则后面启动 sshd 会报libcrypto.so.1.1: cannot open shared object file。echo /usr/local/openssl/lib /etc/ld.so.conf.d/openssl-1.1.1w.conf ldconfig ldconfig -p | grep libcrypto | grep localldconfig跑完后如果看到/usr/local/openssl/lib/libcrypto.so.1.1出现在列表里说明库文件已经被系统认到了。2.3 库文件路径与版本链接的坑这一步是整篇教程里最容易翻车的地方我重点讲。系统里其实存在多个 OpenSSL 版本一个是老系统自带的/usr/lib64/libcrypto.so.10CentOS 7 上常见一个是新编译的/usr/local/openssl/lib/libcrypto.so.1.1。如果你只是把库文件加入了 ldconfig 缓存但/usr/bin/openssl这个命令还指向系统老版本就会出现命令版本和库版本不一致的情况。处理办法是替换命令软链接mv /usr/bin/openssl /usr/bin/openssl.bak.$(date %Y%m%d) ln -sf /usr/local/openssl/bin/openssl /usr/bin/openssl然后重新验证openssl version输出应该是OpenSSL 1.1.1w 11 Sep 2023这里有个细节即使/usr/bin/openssl已经指向新版本某些软件在运行时可能还是通过ldconfig加载系统旧 libcrypto。为了不干扰系统上其他依赖老版本 OpenSSL 的程序比如 python、curl我一般不直接替换系统/usr/lib64/libcrypto.so.10的链接而是让新版 OpenSSL 库以独立路径存在。这样 OpenSSH 编译时指定--with-ssl-dir/usr/local/openssl运行时通过 LD_LIBRARY_PATH 或跑在 systemd 的环境里指定库路径不会把整个系统搅乱。如果你后续编译其他软件时遇到下面这种报错别慌这说明你升级 OpenSSL 后某些旧软件还是用旧头文件在编译或者动态库加载顺序乱了libcrypto.so.10: cannot open shared object file解决办法是看具体是哪个软件如果是你自己的程序编译时明确指定-I/usr/local/openssl/include和-L/usr/local/openssl/lib或者设置LD_LIBRARY_PATH/usr/local/openssl/lib:$LD_LIBRARY_PATH。这个坑我踩过太多回了提前讲清楚省得你到时候百度半天。3. OpenSSH 9.8p1 编译安装全过程3.1 下载解压与 configure 参数选择OpenSSL 整完接下来就是主角登场。cd /usr/local/src wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.8p1.tar.gz tar -xzf openssh-9.8p1.tar.gz cd openssh-9.8p1OpenSSH 是分“OpenBSD 原生版”和“Portable 版”的咱们 Linux 上用的一定是 portable 版本也就是文件名里带p1的那个别下错了。configure 参数是重点我用的组合如下./configure --prefix/usr/local/openssh \ --with-ssl-dir/usr/local/openssl \ --with-zlib \ --with-pam \ --with-md5-passwords \ --with-pid-dir/var/run逐项解释--prefix/usr/local/openssh安装目录二进制、配置、man 文档都装这里不污染系统目录。--with-ssl-dir/usr/local/openssl指向刚才编译安装的 OpenSSL这是重中之重否则 configure 会去系统目录找老版本 OpenSSL。--with-zlib压缩支持依赖 zlib-devel。--with-pam启用 PAM 认证很多系统上 root 登录、密码登录都走 PAM不启用的话后面可能无法用系统账户密码登录。--with-md5-passwords兼容一些老系统上 md5 加密的口令。--with-pid-dir/var/run把 sshd 的 pid 文件放在/var/run这个很关键。如果不指定pid 文件会被放到/usr/local/openssh/var/run下systemd 管理时会找不到进程号导致服务状态显示异常。configure 跑完后看日志尾部有没有OpenSSL header version: 101011b这类字样确认它确实找到了新版 OpenSSL。如果这里显示的是老版本说明--with-ssl-dir没生效或者路径写错停下来查一下再继续。接着编译安装make -j$(nproc) make install安装完成后新二进制在/usr/local/openssh下ls -l /usr/local/openssh/sbin/sshd /usr/local/openssh/bin/ssh -V3.2 编译安装与 sshd_config 迁移新版安装好但系统服务还在用旧版配置文件。先把备份的配置复制到新安装目录cp /etc/ssh/sshd_config /usr/local/openssh/etc/如果你之前对 sshd_config 做过各种调优比如改了端口、禁止 root 登录、限定了 AllowUsers这些配置都能直接沿用。复制完先用新的 sshd 做语法检查/usr/local/openssh/sbin/sshd -t -f /usr/local/openssh/etc/sshd_config如果输出一堆debug信息但没有报错说明配置没问题。如果报了missing privilege separation directory之类的错误就补建目录mkdir -p /var/empty/sshdPrivilegeSeparation这个机制是用来隔离权限的sshd 启动后会降权到一个无权限用户默认是sshd用户。如果你系统里没有这个用户需要先创建useradd -r -s /sbin/nologin -d /var/empty/sshd sshd还要确认密钥位置第一次启动时会生成主机密钥但如果你之前保留在/etc/ssh下且 sshd_config 里指定的是默认路径/etc/ssh/ssh_host_*而新安装的 sshd 可能默认找/usr/local/openssh/etc/这个很容易踩坑。我的做法是不迁移主机密钥路径直接让新 sshd 用sshd_config里指定的路径加载。复制完配置后打开文件检查grep -E ^(HostKey|AuthorizedKeysFile|PasswordAuthentication|PermitRootLogin|PidFile) /usr/local/openssh/etc/sshd_config如果HostKey那几行是注释状态sshd 会使用编译默认路径也就是安装目录下的/usr/local/openssh/etc/ssh_host_*首次启动时会自动生成。如果你不想重新生成可以在配置里显式写HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key这样就直接复用旧的主机密钥客户端那边的 known_hosts 指纹也不会变。3.3 systemd 服务文件调整与服务重启现在最关键的一步让 systemd 用新编译的 sshd 来启动服务而不是继续调用老的/usr/sbin/sshd。CentOS 7 上sshd 的 systemd 服务文件在/usr/lib/systemd/system/sshd.service。我建议不直接改系统默认文件而是创建一个新的 unit 文件cat /etc/systemd/system/sshd.service EOF [Unit] DescriptionOpenSSH server daemon Wantssshd-keygen.service Aftersshd-keygen.service [Service] Typenotify EnvironmentFile-/etc/crypto-policies/back-ends/opensshserver.config ExecStart/usr/local/openssh/sbin/sshd -D $OPTIONS ExecReload/bin/kill -HUP $MAINPID KillModeprocess Restarton-failure RestartPreventExitStatus255 [Install] WantedBymulti-user.target EOF注意-D参数它让 sshd 以前台守护进程方式运行这是 systemd 管理服务时的标准姿势。如果你不带-Dsystemd 会认为服务起不来然后疯狂重启。写完后先让 systemd 重载配置systemctl daemon-reload systemctl stop sshd systemctl start sshd systemctl status sshd这里有个操作顺序的建议先开一个新的 SSH 会话保持连接再停旧服务、启新服务。新服务虽然已经编译好但启动的瞬间如果有绑定端口失败、密钥加载异常你至少还有一个活着的会话能操作。确认服务起来后查看监听端口ss -tlnp | grep 22看到sshd监听在 22 端口就成功了一大半。3.4 升级后的版本自检服务起来后一定要做版本自检这是整个升级过程中最爽的一步/usr/local/openssh/sbin/sshd -V手动执行/usr/local/openssh/bin/ssh -V看的是客户端版本执行/usr/local/openssh/sbin/sshd -V看的是服务端版本。两者应该都显示OpenSSH_9.8p1, OpenSSL 1.1.1w 11 Sep 2023注意最后那半句OpenSSL 1.1.1w如果显示的还是系统老版本 OpenSSL说明编译时--with-ssl-dir没有正确生效或者 sshd 运行时加载的是系统库路径下的旧 libssl。验证一下实际加载的库ldd /usr/local/openssh/sbin/sshd | grep ssl输出里应该能看到/usr/local/openssl/lib/libssl.so.1.1如果显示的是/usr/lib64/libssl.so.10那你需要检查/etc/ld.so.conf.d/下有没有正确写入 OpenSSL 的库路径并重新执行ldconfig。还有个小坑有些系统上/usr/bin/ssh和/usr/bin/sshd还在指向老版本而你直接敲ssh -V时调用的是/usr/bin/ssh而不是新编译的那个。解决办法就是做软链接替换mv /usr/bin/ssh /usr/bin/ssh.bak.$(date %Y%m%d) ln -sf /usr/local/openssh/bin/ssh /usr/bin/ssh mv /usr/sbin/sshd /usr/sbin/sshd.bak.$(date %Y%m%d) ln -sf /usr/local/openssh/sbin/sshd /usr/sbin/sshd这样ssh -V和systemctl start sshd就直接用新版了。4. 升级中的常见报错与排查实录4.1 PAM 相关报错升级完 OpenSSH 后再登录如果发现输入正确密码却被拒绝或者/var/log/secure里出现sshd: PAM unable to dlopen(/usr/lib64/security/pam_sss.so): /usr/lib64/security/pam_sss.so: cannot open shared object file这个问题我在 CentOS 7 上踩过原因很典型编译时--with-pam开启了 PAM 支持但系统上缺少对应的 PAM 开发模块或者 sshd 在运行时尝试加载的 PAM 模块路径不完整。排查思路分两步第一步确认pam-devel已经安装。没有的话重新装上然后重新编译 OpenSSHyum install -y pam-devel cd /usr/local/src/openssh-9.8p1 make clean ./configure --prefix/usr/local/openssh --with-ssl-dir/usr/local/openssl --with-zlib --with-pam --with-md5-passwords --with-pid-dir/var/run make make install第二步如果是pam_sss.so这种特定模块缺失看一下/etc/pam.d/sshd里引用了哪些模块把缺失的模块对应的软件包补上比如sssd-client。另外有些系统上/etc/pam.d/sshd会引用pam_selinux.so等模块如果提示找不到可能是 selinux-policy 没装全yum install -y selinux-policy-targeted pam基本能解决。4.2 OpenSSL 版本不匹配mismatch报错这个报错真的非常阴间openssl version mismatch. built against 30000020, you have 30500060翻译一下就是你编译这个程序的时候链接的是 OpenSSL 3.0.230000020 的十六进制对应 3.0.2但运行时加载到的是 OpenSSL 3.5.030500060 对应 3.5.0。这是典型的“编译头文件版本”和“运行库版本”不一致导致的。出现这种情况通常是因为系统里存在多个 OpenSSL 版本编译时头文件和链接库从不同路径取到了不同版本。比如你系统里有/usr/include/openssl老版本头文件又有/usr/local/openssl/include新版本头文件而ldconfig缓存里两个版本的 libcrypto 都有。解决办法是在编译 OpenSSH 时让CPPFLAGS和LDFLAGS明确指向新版 OpenSSL./configure CPPFLAGS-I/usr/local/openssl/include \ LDFLAGS-L/usr/local/openssl/lib -Wl,-rpath,/usr/local/openssl/lib \ --prefix/usr/local/openssh \ --with-ssl-dir/usr/local/openssl \ --with-zlib --with-pam --with-md5-passwords --with-pid-dir/var/run-Wl,-rpath是把库路径写死进二进制里运行时优先加载/usr/local/openssl/lib下的库避免被系统老库截胡。这个方法对解决各种mismatch报错都有效强烈建议加上。4.3 登录异常和客户端 known_hosts 问题升级完成后从你的电脑重新 SSH 登录如果弹出来这行字WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!别紧张这不一定是你服务器被入侵了多数情况下是因为你升级时重新生成了主机密钥或者你用ln -sf替换了 sshd 二进制后sshd 加载了新的密钥文件。解决办法很简单找到你本地~/.ssh/known_hosts里对应 IP 的那一行删掉即可。ssh-keygen -R 你的服务器IP然后重新 SSH会提示确认新指纹输入yes就行。还有个我在实操中遇到的低级错误升级后 SSH 登录卡在password:那里不管怎么输密码都提示错误翻/var/log/secure发现Failed password for root from 192.168.1.100 port 52316 ssh2排查下来问题出在sshd_config里PasswordAuthentication被设成no而旧版 sshd 可能因为某种原因允许了密码登录新版的权限检查更严格于是直接拒绝。解决方案见下一节加固部分你先临时把配置改回来确认登录没问题再收紧策略。4.4 常见问题速查表我整理了升级过程中最容易遇到的几类问题按症状、原因、解决方式列成一张表方便你排错时快速定位。症状可能原因排查/解决方法sshd 启动失败systemctl status 显示 exit-codesshd_config 语法错误、端口被占用、密钥权限不对执行/usr/local/openssh/sbin/sshd -t检查配置ss -tlnp登录后立即断开/var/log/secure 显示 PAM 报错PAM 模块缺失或路径错误安装 pam-devel重新编译安装 OpenSSH检查/etc/pam.d/sshd引用的模块sshd 启动成功但端口没监听systemd 启动的还是旧二进制检查 ExecStart 路径是否指向/usr/local/openssh/sbin/sshdsystemctl daemon-reload后重启ssh -V 显示的还是老版本PATH 里 ssh 指向旧二进制which ssh看路径用ln -sf替换软链接新版 sshd 找不到 libcrypto.so.1.1ldconfig 缓存未更新确认/etc/ld.so.conf.d/下 OpenSSL 库路径存在执行ldconfig客户端提示 REMOTE HOST IDENTIFICATION HAS CHANGED主机密钥变更本地执行ssh-keygen -R 服务器IP后重连升级后某些自动化脚本连不上 SSH旧版允许了某些不安全的算法/密钥类型在 sshd_config 中显式启用兼容算法或更新客户端configure 阶段报 OpenSSL 版本太旧系统老库干扰用--with-ssl-dir/usr/local/openssl指定路径必要时加 CPPFLAGS/LDFLAGS服务显示 active (running) 但无法连接firewalld/SELinux 拦截检查firewall-cmd --list-all是否放行 22 端口临时setenforce 0测试是否是 SELinux 问题这张表我基本每次升级都会用到尤其是帮同事排查的时候对照着看很快就能定位到方向。5. 升级后的安全加固与回滚预案5.1 登录方式加固升级到 OpenSSH 9.8p1 只是第一步真正让服务器安全的是合理配置。我升级完都会顺手做一轮加固避免“版本新了但配置裸奔”的情况。先备份当前配置然后逐个调整关键项cp /usr/local/openssh/etc/sshd_config /usr/local/openssh/etc/sshd_config.bak我用得比较多的硬配置# 只监听指定端口不要用默认22也行但注意防火墙要同步改 Port 22 # 禁止 root 密码登录但不禁止密钥登录 PermitRootLogin prohibit-password # 优先公钥认证关闭密码认证视情况如果团队都用密钥可以开 PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no # 限制登录用户 AllowUsers ops root # 登录空密码用户禁止 PermitEmptyPasswords no # 客户端保活避免长时间空闲被断开 ClientAliveInterval 300 ClientAliveCountMax 2 # 最大尝试次数 MaxAuthTries 3改完配置后养成一个好习惯先开新终端验证登录再关旧终端。因为如果配置写错了新连接的验证能立刻发现问题你还有旧会话可以回滚配置。这是所有远程服务器配置操作的通用保命技巧不只是 sshd。还要检查一下 SSH 密钥的权限chmod 600 /usr/local/openssh/etc/ssh_host_rsa_key* ls -l /usr/local/openssh/etc/ssh_host_*密钥权限太宽松的话sshd 会直接拒绝使用这些密钥启动。5.2 回滚方案升级过程中迟早会碰到“新版本和业务脚本不兼容”“某个老客户端连不上”之类的问题这时候要能快速回滚。我的回滚思路是这样第一步如果只是配置问题把旧配置复制回去重启服务cp /etc/ssh.bak.YYYYMMDD/sshd_config /usr/local/openssh/etc/sshd_config systemctl restart sshd第二步如果新版本 sshd 本身有问题直接利用备份的二进制把 systemd 服务指向旧版systemctl stop sshd cp /usr/sbin/sshd.bak.YYYYMMDD /usr/sbin/sshd systemctl start sshd第三步如果连旧版都启动失败就要通过控制台云平台VNC、物理机显示器登录系统检查/var/log/messages或/var/log/secure里的报错把配置文件逐步改回来。回滚机制平时不起眼但真遇到问题时能救命。我在生产环境升过一次 OpenSSH升级后 OpenSSL 的 lib路径没配好导致 sshd 起不来好在备份的旧版本二进制还在一条命令就切回去了全程没断过远程连接。5.3 后续版本追踪与维护习惯OpenSSH 是个更新节奏比较快的项目安全问题也多所以升级完不是一劳永逸。我现在的维护习惯包括每个月定时看一眼 OpenSSH Portable 发布页 确认自己用的版本是否还是最新。关注/var/log/secure里的 SSH 登录日志没事多翻翻看看有没有异常扫描或爆破行为。定期测试新版发布后的升级路径先在测试环境跑一遍确认没问题再上生产。重要服务器禁用密码登录、只开密钥登录后一定要把私钥的备份放在离线位置防止密钥丢失后进不了机器。另外还有个细节升级完 OpenSSH、OpenSSL 后建议顺手把服务器上的openssl version、ssh -V的结果记到运维文档里方便后面安全扫描或审计时快速回应。别小看这个记录我在答辩审计的时候就被问到过“你们现在跑的是什么版本”翻出文档直接回复省了不少事。写在最后的一些实践提醒最后再分享几个我在多次升级OpenSSH过程中养成的操作习惯希望能帮你少踩几个坑。第一升级前先开至少两个已登录的 SSH 会话并且保持在/root或有权修改目录的位置不要只留一条连接。万一升级过程中 sshd 重启失败你还能用另一个会话抢救。如果条件允许用 tmux 开个持久会话即使网络闪断重连后还能恢复现场。第二编译过程不要图省事直接make install一定要记住你 configure 时用了什么参数。把 configure 命令存成脚本或者写在文档里后面升级、排查、重建都能用上。第三升级完不要马上重启服务器。先确认 sshd 服务正常、能正常登录再考虑重启。重启会加载整个系统环境如果 OpenSSL 的库路径有问题重启后不光 sshd 可能起不来其他依赖系统库的服务也可能受影响。第四如果你管理的是一批同版本系统升级方案完全可以在测试环境提前跑一遍把每一步的输出、报错、解决方案记录下来。我后来给内网几十台机器批量升级时就是靠这套记录每台机器不到15分钟就能全部搞定。OpenSSH 升级这件事说难不难说简单也不是复制粘贴几行命令就完事的。只要你理解了“先底层后上层”、“先备份再动手”、“先验证再收尾”这几个原则以后升级任何核心组件都能心里有底。