企业官网建设流程全解析

1. 升级前的环境巡检与方案确认

1.1 为什么要升到 OpenSSH 9.8p1

OpenSSH 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 升级前必须完成的备份与保底方案

升级之前，先花十分钟确认环境状态，这个时间花得绝对值。我的检查顺序是：

1. 确认系统版本和当前 OpenSSH、OpenSSL 版本。
2. 确认有没有装 gcc、make、perl、pam-devel 等编译必需组件。
3. 确认是不是多用户环境、有没有其他服务依赖系统自带的 sshd。
4. 如果有条件，先开一个 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-devel

Debian/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 install

shared这个参数务必保留，它表示生成动态库（.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 local

ldconfig跑完后，如果看到/usr/local/openssl/lib/libcrypto.so.1.1出现在列表里，说明库文件已经被系统认到了。

2.3 库文件路径与版本链接的坑

这一步是整篇教程里最容易翻车的地方，我重点讲。

系统里其实存在多个 OpenSSL 版本：一个是老系统自带的/usr/lib64/libcrypto.so.10（CentOS 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.8p1

OpenSSH 是分“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 -V

3.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/sshd

PrivilegeSeparation这个机制是用来隔离权限的，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] Description=OpenSSH server daemon Wants=sshd-keygen.service After=sshd-keygen.service [Service] Type=notify EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config ExecStart=/usr/local/openssh/sbin/sshd -D $OPTIONS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartPreventExitStatus=255 [Install] WantedBy=multi-user.target EOF

注意-D参数，它让 sshd 以前台守护进程方式运行，这是 systemd 管理服务时的标准姿势。如果你不带-D，systemd 会认为服务起不来，然后疯狂重启。

写完后，先让 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已经安装。没有的话重新装上，然后重新编译 OpenSSH：

yum 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.2（30000020 的十六进制对应 3.0.2），但运行时加载到的是 OpenSSL 3.5.0（30500060 对应 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 常见问题速查表

我整理了升级过程中最容易遇到的几类问题，按症状、原因、解决方式列成一张表，方便你排错时快速定位。

这张表我基本每次升级都会用到，尤其是帮同事排查的时候，对照着看很快就能定位到方向。

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 是个更新节奏比较快的项目，安全问题也多，所以升级完不是一劳永逸。我现在的维护习惯包括：

1. 每个月定时看一眼 OpenSSH Portable 发布页 ，确认自己用的版本是否还是最新。
2. 关注/var/log/secure里的 SSH 登录日志，没事多翻翻，看看有没有异常扫描或爆破行为。
3. 定期测试新版发布后的升级路径，先在测试环境跑一遍，确认没问题再上生产。
4. 重要服务器禁用密码登录、只开密钥登录后，一定要把私钥的备份放在离线位置，防止密钥丢失后进不了机器。

另外还有个细节：升级完 OpenSSH、OpenSSL 后，建议顺手把服务器上的openssl version、ssh -V的结果记到运维文档里，方便后面安全扫描或审计时快速回应。别小看这个记录，我在答辩审计的时候就被问到过“你们现在跑的是什么版本”，翻出文档直接回复，省了不少事。

写在最后的一些实践提醒

最后再分享几个我在多次升级OpenSSH过程中养成的操作习惯，希望能帮你少踩几个坑。

第一，升级前先开至少两个已登录的 SSH 会话，并且保持在/root或有权修改目录的位置，不要只留一条连接。万一升级过程中 sshd 重启失败，你还能用另一个会话抢救。如果条件允许，用 tmux 开个持久会话，即使网络闪断重连后还能恢复现场。

第二，编译过程不要图省事直接make install，一定要记住你 configure 时用了什么参数。把 configure 命令存成脚本或者写在文档里，后面升级、排查、重建都能用上。

第三，升级完不要马上重启服务器。先确认 sshd 服务正常、能正常登录，再考虑重启。重启会加载整个系统环境，如果 OpenSSL 的库路径有问题，重启后不光 sshd 可能起不来，其他依赖系统库的服务也可能受影响。

第四，如果你管理的是一批同版本系统，升级方案完全可以在测试环境提前跑一遍，把每一步的输出、报错、解决方案记录下来。我后来给内网几十台机器批量升级时，就是靠这套记录，每台机器不到15分钟就能全部搞定。

OpenSSH 升级这件事，说难不难，说简单也不是复制粘贴几行命令就完事的。只要你理解了“先底层后上层”、“先备份再动手”、“先验证再收尾”这几个原则，以后升级任何核心组件都能心里有底。