企业官网建设流程全解析

简介：面向统信UOS（UEL20）aarch64架构的运维与系统管理人员，这份自制OpenSSH 9.6p1 rpm安装包提供了一套完整的远程连接组件升级方案，帮助将低版本OpenSSH统一升级至9.6p1，有效应对安全审计与等保合规中对SSH版本的要求。压缩包共4个文件，主要包括openssh、openssh-clients、openssh-server三个aarch64架构的rpm包，以及一个用于自动执行升级的upgrade_openssh.sh脚本，整体体积仅1.5MB，非常适合在内网或离线环境中快速分发与安装。资源已有1286人学习，适用于需批量维护统信UEL20系统、替换老旧SSH服务的IT运维场景。利用自带脚本可减少手动敲击命令的出错率，并兼顾服务端、客户端的一致性升级，帮助管理员高效完成OpenSSH安全加固，保障远程运维通道的稳定性与可用性。rpm包经过自制适配，可直接在UEL20-aarch64环境使用，免去源码编译的繁复操作。

1. 所有 sshd 升级的理由在这，但 aarch64 的坑不在编译而在于交付格式

在某公司的内网机房里，一批基于 aarch64 架构的统信UOS服务器还在跑 OpenSSH 7.4 老版本，内部的漏扫和审计报告一直在报 sshd 的 CVE-2023-48795（Terrapin 攻击）风险。直接上网下二进制不是不行，但内网环境没有外网源，还得过软件分发审计，所以最常见的做法是把 OpenSSH 9.6p1 在本地打成 rpm 安装包，再推送到目标机器。这个过程看着是“编译 + 打包”，真正磨人的却是依赖版本、配置文件兼容性和 sshd 重启时机。我会把自制 rpm 的完整流程走一遍，并给出可直接照抄的踩坑记录和验证命令。

2. 动手前先理清：UOS aarch64 上的依赖约束与构建环境准备

2.1 为什么不能直接用网上的通用包：架构、glibc 和 OpenSSL 三座山

先别急着找包，这一步想清楚，后面能省半天时间。我接手这类升级任务时，第一反应永远是先看目标机器的架构和系统版本，而不是先下载。在一台 aarch64 的 UOS 服务器上，rpm 包的架构标签必须对应 aarch64，你在仓库里看到的很多现成 OpenSSH 包，要么是 x86_64，要么是面向别的发行版编译出来的产物，直接拿过来装，几乎都会在依赖检查阶段被拦下来。

依赖上的问题通常出在两个地方：glibc 和 OpenSSL。OpenSSH 本身不直接依赖 glibc 的核心符号，但它需要 zlib、OpenSSL 和 PAM 这些动态库。比如某些基于新发行版制作的 OpenSSH 9.6p1 包，会链接到 libcrypto.so.3，这是 OpenSSL 3.x 的库文件；而手头这套 UOS aarch64 系统自带的是 OpenSSL 1.1.1，库名叫 libcrypto.so.1.1。把前者拿过来装，rpm 会直接报需要 libcrypto.so.3，就算强制安装，sshd 也起不来。

所以常见做法是：在与目标机器同架构的 UOS 系统上，用系统的编译器、系统头文件、系统自带的 OpenSSL 版本，把 OpenSSH 9.6p1 从源码构建成 rpm。这个过程虽然要多花十几分钟，但换回来的是依赖可控、部署可重复，内网分发也说得清楚，以后审计的时候拿得出构建记录。

还有一点容易被忽略：OpenSSL 版本不是越高越好。如果你在构建机上用了某个新版本的 OpenSSL 头文件做编译，出来的 sshd 在旧版本 UOS 上运行时，可能因为缺少新符号而失败。因此构建机操作系统尽量与目标机保持一致，连小版本也别差太多，我是直接拿一台同样 UOS 版本的 aarch64 服务器来当构建机的。

2.2 准备构建机：干净环境与最小依赖

有了思路，接下来就是搭构建环境。我一般直接在同架构的 UOS 服务器上构建，而不是在本地笔记本或 x86 的虚拟机上，这样能把架构差异堵死在源头。强烈建议创建独立用户来构建，不要用 root，rpmbuild 在打包阶段会处理文件属主，root 用户在 %install 阶段容易写出属主混乱的包，后面装到生产环境会有权限问题。

先准备好 rpmbuild 目录结构：

useradd -m -s /bin/bash builder su - builder -- rpmdev-setuptree

rpmdev-setuptree 会生成 ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} 这些标准目录。如果你的系统没装 rpmdevtools，可以手动创建这五个目录，效果一样，只是少了些默认宏文件。后面构建时，源码包要放进 SOURCES，spec 文件放进 SPECS，构建日志和中间文件都会落在 BUILD 和 BUILDROOT 下。

接下来安装构建依赖。内网环境没有外网源，我一般用系统自带的 ISO 或内网镜像源。这里的命令以能用 yum 的 UOS 环境为例，包名在你本机可能略有差异，按实际源来调整：

sudo yum install -y gcc make rpm-build rpmdevtools openssl-devel zlib-devel pam-devel

openssl-devel 版本必须大于等于 1.1.1，因为 OpenSSH 9.6 构建时会检测 OpenSSL 版本，低于这个值会直接拒绝编译；zlib-devel 和 pam-devel 分别对应压缩库和 PAM 认证支持，缺了任何一个，configure 都会在特性检测阶段自动关掉对应功能。如果你把 openssl-devel 装错了，构建过程中可能出现 libcrypto 的某个头文件找不到，或者链接时符号版本不匹配，这类错误我后面在避坑章节还会提到。

环境里还应留一点磁盘空间，OpenSSH 源码编译过程中 BUILD 目录会占 300MB 左右，对现代服务器来说不是问题，但如果你习惯把 /tmp 挂成 noexec，后面 configure 脚本生成的一些临时可执行文件跑不动，会报一些很诡异的错。我在构建前还会执行一次df -h /home/builder，确认空间充足再动手。

3. 自制 OpenSSH 9.6p1 的 rpm：spec 编写与构建参数

3.1 spec 文件怎么设计：几个关键段落直接决定升级包的成败

spec 是这个打包流程里最核心的文件，很多第一次自己打包的同事，习惯性地把网上某个 spec 抄下来改个版本号就去构建，结果出来的 rpm 要么覆盖了系统配置文件，要么升级后 sshd 起不来。我这里不准备照搬任何发行版的 spec，只把几个决定生死的段落单独拿出来讲。

第一个关键点是配置文件处理方式。OpenSSH 升级包和全新安装包最大的区别在于，生产环境里 /etc/ssh/sshd_config 可能已经被运维手工调过多次，包含自定义的端口、AllowUsers、AuthorizedKeysCommand 等设置。如果 spec 里把 sshd_config 写成普通文件，rpm -Uvh 会用打包时带入的文件直接覆盖掉你的定制，升级完行为大变。正确做法是标记成 %config(noreplace)，这样 rpm 遇到已有文件被改动过时，会把新版本另存为 sshd_config.rpmnew，而不是覆盖，保留你的手工配置。

第二个关键点是 libexec 路径。OpenSSH 的 sftp-server 属于子系统，sshd_config 里默认的 Subsystem 行指向一个具体路径。在很多现成 spec 里，sftp-server 被安装在 /usr/libexec/openssh/sftp-server，而你自己做包时如果没有显式指定，configure 默认可能把它放到别的 libexec 路径下，导致升级后 sftp/scp 不可用。这个坑在 5.3 里还会展开说。

第三个关键点是特权分离目录和 sshd 用户。OpenSSH 9.6 默认启用 privilege separation，运行时需要 /run/sshd 目录和 sshd 用户。系统原有的包会通过自带的脚本创建这些，但自制 rpm 的 spec 中如果不写，安装上去的 sshd 首次启动必然报 “Missing privilege separation directory: /run/sshd”。

下面是我在这个需求上整理出的一个可用的 spec 骨架，它根据内网交付要求做了收敛，你直接改一下 Source0 的文件名就能用：

Name: openssh Version: 9.6p1 Release: 1 Summary: OpenSSH 9.6p1 for UOS aarch64 (rpm rebuild) License: BSD URL: https://www.openssh.com/ Source0: openssh-9.6p1.tar.gz BuildRequires: gcc, make, rpm-build BuildRequires: openssl-devel >= 1.1.1, zlib-devel, pam-devel %description OpenSSH 9.6p1 升级包。该版本修复 CVE-2023-48795 (Terrapin)， 并收紧了部分默认算法策略。本包面向 UOS aarch64 内网环境重新构建。 %prep %setup -q -n %{name}-%{version} %build %configure \ --prefix=/usr \ --sysconfdir=/etc/ssh \ --with-pam \ --with-privsep-path=/run/sshd \ --with-privsep-user=sshd \ --libexecdir=%{_libexecdir}/openssh make %{?_smp_mflags} %install rm -rf %{buildroot} make install DESTDIR=%{buildroot} install -d %{buildroot}/run/sshd %pre # 升级前备份现有配置，方便出问题时恢复 if [ -f /etc/ssh/sshd_config ]; then cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.rpmsave cp -a /etc/ssh/ssh_config /etc/ssh/ssh_config.rpmsave fi %post # 主机密钥缺失时自动生成 if [ ! -f /etc/ssh/ssh_host_ed25519_key ]; then ssh-keygen -A fi # 确保 sshd 用户与特权分离目录存在 if ! getent passwd sshd >/dev/null; then useradd -r -s /usr/sbin/nologin -d /var/empty/sshd sshd fi mkdir -p /run/sshd chmod 0755 /run/sshd systemctl daemon-reload %files %defattr(-,root,root) %dir /etc/ssh %config(noreplace) /etc/ssh/sshd_config %config(noreplace) /etc/ssh/ssh_config /usr/sbin/sshd /usr/bin/ssh /usr/bin/scp /usr/bin/sftp /usr/bin/ssh-keygen /usr/bin/ssh-copy-id /usr/libexec/openssh/* /usr/share/man/man1/ssh.1.gz /usr/share/man/man1/scp.1.gz /usr/share/man/man5/sshd_config.5.gz /usr/share/man/man8/sshd.8.gz %changelog * 2024-06-01 某开发者 <dev@example.com> - 初始构建对齐 9.6p1

这段 spec 里有几个需要解释的地方。%configure要显式传--libexecdir=%{_libexecdir}/openssh，否则 sftp-server 的路径可能与 UOS 现有 sshd_config 中的 Subsystem 行不一致。%files中把 /usr/libexec/openssh/* 作为一个整体打包，是确保 sftp-server 等组件随主包一起分发的最简单方式，不用逐个列文件名。

%pre中的备份逻辑是我额外加的，虽然%config(noreplace)已经避免了覆盖，但保留一份 rpmsave 能让你在升级出问题时，用 diff 快速比较出现状和新包默认配置的差异，排查起来方便很多。%post里要做两件事：主机密钥生成和特权分离目录创建。很多自制包翻车就翻在这里，没有生成 ssh_host_* 系列密钥的 rpm，装完第一次启动会报 “Could not load host key”。

另外注意，spec 中没有写入任何需要联网下载的依赖，构建源只有 openssh-9.6p1.tar.gz 这一个文件，这在离线环境下是可复现的。构建前把 tar 包放到 ~/rpmbuild/SOURCES，spec 放到 ~/rpmbuild/SPECS，然后开始构建。

3.2 在 aarch64 上执行 rpmbuild 并核对产物

构建命令本身不复杂：

su - builder cd ~/rpmbuild/SPECS rpmbuild -ba openssh.spec

-ba的意思是同时生成二进制 rpm 和源码 rpm，构建完成会在 RPMS/aarch64 和 SRPMS 两个目录下留下产物。第一次跑的时候先看输出中的 configure 检测结果，重点确认几个关键特性被开启，用 grep 从 config.log 里捞信息最直接：

grep -E "PAM|OpenSSL|zlib|sftp-server" ~/rpmbuild/BUILD/openssh-9.6p1/config.log

如果发现 OpenSSL 支持被自动关闭，或者 PAM 支持没开，说明构建机上的 devel 包不全，补装后把 ~/rpmbuild/BUILD 和 BUILDROOT 删掉重新构建。构建完成后，核对产物文件用这两个命令：

rpm -qpl ~/rpmbuild/RPMS/aarch64/openssh-9.6p1-1.aarch64.rpm rpm -qpR ~/rpmbuild/RPMS/aarch64/openssh-9.6p1-1.aarch64.rpm

-qpl 列出包内的文件清单，重点确认 /usr/libexec/openssh/sftp-server、/usr/sbin/sshd 都在；-qpR 列出依赖，确认依赖项都指向系统已提供的版本。这里我见过不少翻车案例，包里的依赖表出现 libcrypto.so.3，拿回 UOS 上根本装不进去，问题就出在构建机上装了过新的 OpenSSL 头文件，这种情况只能回到构建环境重新编译。

到这里，rpm 包已经产出。还有一步我建议做：内网软件分发一般要求包来源可信，有条件的话用内网自己的 GPG key 签个名。签名的命令是rpmsign --addsign openssh-9.6p1-1.aarch64.rpm，签名后目标机器上可以用rpm -K校验包的完整性和来源。如果环境里没有现成的签名体系，这一步可以跳过，但至少要知道有这条路。

4. 在 UOS 上安装与升级：操作顺序与回滚保护

4.1 升级前要做的三件事：备份、会话、控制台

包做好了，别急着抄起 rpm 命令就装，升级 sshd 和升级普通软件不一样，它直接影响你唯一的远程通路。我给自己定了个习惯，先做三件事再动手。

第一，备份配置。把整个 /etc/ssh 目录连同权限一起备份下来，用 cp -a 比 tar 更方便后续比对：

cp -a /etc/ssh /etc/ssh.bak.$(date +%Y%m%d%H%M)

第二，确认当前 sshd 由哪个 systemd 单元管理，知道重启时哪些连接会断。用下面一组命令看状态：

systemctl status sshd --no-pager -l ss -lntp | grep ':22 ' systemctl list-units | grep sshd

看到 sshd.service 负责监听时，重启服务的操作会终止服务单元内派生的所有 sshd 子进程，意味着正在使用的多个 ssh 会话会同时断开。看到 sshd.socket 处于 active 状态时，情况更复杂，systemd 直接监听 22 端口，连接进来才拉起 sshd 实例，这种模式下重启 sshd.service 后，已建立的会话同样会被终止。所以升级动作必须放在计划窗口内，并提前准备好控制台或带外管理通道。

第三，为当前会话留一个“后悔药”：在服务器上开一个 tmux，把升级命令放里面跑，这样即便 ssh 客户端闪断，tmux 里的进程也不会被中断，重连后还能看到执行结果，继续操作。tmux 不存在的话，用 nohup 加日志重定向也能达到类似效果。

tmux new -s upgrade_ssh

这三步做完，升级流程本身只是走个过场，真正的问题大多出在重启后连接不回来，所以备份和备用通道这两项不能省。

4.2 用 rpm 做升级：先试装，再替换，后重启

正式的升级命令我在生产上是分三步执行的。先跑一次rpm -Uvh --test，它不装包，只检查依赖、冲突和脚本是否能正常执行，这个动作能拦截掉 90% 的低级错误：

rpm -Uvh --test openssh-9.6p1-1.aarch64.rpm

没有报错后，再执行正式安装：

rpm -Uvh openssh-9.6p1-1.aarch64.rpm

这里用 -U 而不是 -i，是为了让旧版本的 openssh 被正确替换。执行过程中如果看到 sshd_config.rpmnew 被生成，说明现网 sshd_config 和包内默认配置有差异，这是预期行为，稍后处理。升级完成后，新二进制已经在 /usr/sbin/sshd 下，但运行中的 sshd 进程还是旧代码，此时先校验配置，再重启：

sshd -t systemctl restart sshd

sshd -t不输出任何内容时说明配置语法没问题。systemctl restart sshd这个动作会终止现有的所有 sshd 派生会话，导致正在连接的终端断线，所以前面准备的 tmux 和控制台在这里就派上了用场。断线后你只需要从控制台或带外通道重新登录即可，如果一切正常，就完成了新旧进程的切换。

如果重启后服务起不来，最坏情况是连不进来。这时回到控制台执行journalctl -u sshd -n 50看失败原因，也可以直接停掉新包，把备份的旧配置恢复回去再启动。这里有个小细节要提前知道：systemctl restart sshd失败时，systemd 会把服务标记为 failed，但不影响你手动运行/usr/sbin/sshd -D -p 2222这种临时端口来救场，至少能保证管理通路不断。

4.3 配置文件 diff 与基线化：让下次升级不翻车

升级后头一件要处理的是 sshd_config.rpmnew。这个文件是 rpm 在检测到现网配置和包内默认配置不同后生成的，它包含 9.6p1 的默认值，但不应该直接覆盖。正确姿势是先 diff，再逐项决定是否合并：

diff -u /etc/ssh/sshd_config /etc/ssh/sshd_config.rpmnew

重点看三个地方：Subsystem sftp 的路径是否还指向老路径，Ciphers/MACs/KexAlgorithms 有没有被 9.6 默认值影响，以及你手工加的参数（AllowUsers、PasswordAuthentication 等）是否真的还在原文件里。如果发现 Subsystem 行指向 /usr/libexec/openssh/sftp-server，而不是 /usr/libexec/sftp-server，需要改配置里的路径，否则 sftp 客户端会报 subsystem request failed。

合并完成后重启一次 sshd，再确认服务正常：

sshd -t && systemctl restart sshd

到这里升级主体工作结束，但还差最后一步：把 sshd_config 的新基线记录下来。我会把 diff 的结果和最终生效的 sshd_config 快照归档到配置管理目录，这样下一个版本升级时，可以直接拿这份快照做基线，告诉后来的人：生产环境改过这些，官方默认值里没有。这一步看着麻烦，但能避免半年后再升级时对着 rpmsave、rpmnew 和当前配置三方比对无从下手。

5. OpenSSH 9.6p1 升级避坑：从构建到上线的 6 个常见问题与排查办法

这一章我重点讲坑，都是升级过程中真实会撞上的，每一条按现象、原因、解决来写，可以直接对照排查。

5.1 configure 阶段直接退出，日志里只有 C compiler cannot create executables

现象：执行 rpmbuild 后，构建在 configure 检测阶段就中断，config.log 末尾出现configure: error: C compiler cannot create executables，看起来像是编译器坏了。

原因：最常见的是构建机把 /tmp 挂成了 noexec，或者构建用户没有临时目录写权限。configure 在检测时会生成临时可执行文件再运行，/tmp 无法执行就会报这个错。另一个可能是 gcc 和头文件不匹配，比如装了新版 gcc 但缺 glibc-devel。

解决：先确认挂载选项，执行mount | grep /tmp，有 noexec 就换用别的临时目录，比如export TMPDIR=/home/builder/tmp，并保证该目录可写且可执行。再补一次依赖检查，yum list installed | grep glibc-devel，缺啥装啥。重新构建前把 ~/rpmbuild/BUILD 和 ~/rpmbuild/BUILDROOT 清掉，避免旧产物干扰。

5.2 新 sshd 第一次启动就报 Missing privilege separation directory: /run/sshd

现象：rpm 安装成功，执行systemctl start sshd，进程立即退出，journalctl 日志里写着Missing privilege separation directory: /run/sshd。

原因：自制 spec 的 %post 脚本里没有创建 /run/sshd，也没有创建 sshd 系统用户。OpenSSH 9.6 默认采用 privilege separation，进程启动会检查 /run/sshd 这个目录是否存在，目录不存在就直接退出，而不是自动创建。

解决：在我给的 spec 中，%post 里已经包含了 mkdir -p /run/sshd 和 useradd 的逻辑，如果你用的是简化版 spec，手动补上这两步即可。注意 /run 是 tmpfs，重启后会清空，所以必须在每次启动时通过 systemd 的单元依赖或 %post 来确保存在。另一个简单有效的习惯是安装后先用sshd -t做检查，再做 systemctl start，能更早地发现问题。

5.3 sftp/scp 连接后报 subsystem request failed

现象：升级完成后 ssh 登录正常，但 sftp 连接后立即断开，服务端日志出现subsystem request failed: subsystem not found或starting program /usr/libexec/sftp-server failed。

原因：升级包的 libexec 路径和当前 sshd_config 里的 Subsystem 行不一致。比如新包的 sftp-server 被安装到 /usr/libexec/openssh/sftp-server，而 sshd_config 里还写着 /usr/libexec/sftp-server，旧路径下没有文件，当然启动不了。

解决：用rpm -qpl确认新包 sftp-server 的实际路径，然后把 /etc/ssh/sshd_config 里的 Subsystem 行改成对应路径。改完执行sshd -t && systemctl restart sshd。这类问题之所以频发，是因为很多 spec 在 %configure 里省略了 --libexecdir 参数，导致路径漂移。

5.4 密钥登录突然失效：userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms

现象：升级后，密码登录正常，但自动化系统用旧 RSA 密钥连不进来，日志显示userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms。

原因：OpenSSH 9.6 延续了 8.8 以来对 SHA-1 签名算法的收紧策略，默认不再接受 ssh-rsa（SHA-1）签名，只接受 rsa-sha2-256/512 或 ed25519。旧客户端或旧配置里用了 ssh-rsa，就会被显式拒绝。

解决：最彻底的办法是把登录密钥换成 ed25519，这是新环境的正确姿势。如果短期内改不了客户端，可以在 sshd_config 里加一行PubkeyAcceptedAlgorithms +ssh-rsa临时兼容，但这意味着把 SHA-1 签名重新打开，风险得自己评估。修改后同样要sshd -t && systemctl restart sshd。因为这是默认行为变化，升级前最好在变更文档里注明，避免业务侧告警后一脸茫然。

5.5 升级后 22 端口还是旧 sshd：sshd.socket 激活导致的新旧进程混杂

现象：rpm 升级和 systemctl restart sshd 都执行了，但ss -lntp | grep :22显示监听 22 的进程路径还是旧的，用 ssh -V 看到的版本也是旧的。

原因：系统启用了 sshd.socket 单元的 socket 激活机制。systemd 直接监听 22 端口，连接到达时才拉起 sshd 实例。只重启 sshd.service 不会重建 socket 相关的监听链路，导致你重启了服务，但真正代答的进程还是由旧 socket 单元拉起的旧二进制。

解决：先停掉 socket 单元，改成由 sshd 服务自己监听。执行顺序是systemctl stop sshd.socket、systemctl disable sshd.socket、systemctl restart sshd.service、systemctl enable sshd.service。改完再用ss -lntp | grep :22确认监听路径是 /usr/sbin/sshd。这个坑在 Debian 系衍生的 UOS 上比较常见，因为默认安装就可能带 socket 单元。

6. 升级后的验证与收尾：用 ssh -Q 和连接日志确认 9.6p1 生效

6.1 升级后的验收清单

升级完不是看一眼版本号就完事，我按以下顺序做验收，这几条基本覆盖了实际使用中会碰到的场景。先看版本和实际生效的配置：

ssh -V sshd -T | grep -E "^version|^pubkeyacceptedalgorithms|^ciphers|^macs"

ssh -V 要看到 OpenSSH_9.6p1，sshd -T 输出的是进程实际生效的配置，注意不是 sshd_config 文件本身。接着看算法族：

ssh -Q cipher ssh -Q kex ssh -Q mac

这三个命令分别输出当前二进制支持的加密算法、密钥交换算法和 MAC 算法。然后在本机测试一次完整的 kex 握手：

ssh -vv localhost uptime

-vv 输出里重点看 KEX 相关行，比如kex: algorithm: sntrup761x25519-sha512@openssh.com、kex: host key algorithm: ssh-ed25519，看到这些就说明新版本支持的密钥交换和主机密钥算法已经实际生效。最后从远程用真实客户端连一次，检查登录记录，确认一切正常。

6.2 把验证清单固化到基线，下次不再从头排查

每次版本升级都手动敲这些命令，肯定不是长久之计。我一般会写一个简单的巡检脚本，放到跳板机上，批量跑目标服务器，输出统一结果。只要几行命令就能覆盖内网几十台机器：

for h in host-01 host-02 host-03; do ssh -o BatchMode=yes "$h" \ 'echo "== $HOSTNAME =="; ssh -V 2>&1; sshd -T 2>/dev/null | grep -E "^version|^macs" | head -3; systemctl is-active sshd' done

这套脚本不需要额外安装 agent，只要管理账号的密钥没被默认策略拦掉就行。输出里的 version 行如果出现 9.6p1，sshd 服务 active，就认为升级达标。如果哪台机器没有输出 ssh -V，重点检查是不是密钥登录被新版本默认策略拦了，回到 5.4 去处理。

这次升级做完后，我印象最深的教训是“先看 sshd.socket，再谈重启”，socket 激活这种机制日常不显眼，升级时却能让你对着旧版本的进程发愣半天。另一个习惯也保留了下来：所有自制 rpm 的 spec 一旦验证通过，就放进配置管理的基线目录，并附上当时的构建日志，下次再打 9.7、9.8 的包，直接用 diff 看 spec 变更点，不用从头理解一遍打包逻辑。

以上这套流程不一定每个环境都能原样照搬，但思路是通用的：依赖可控、配置保留、重启可回退、验证可重复。希望帮到你。

本文还有配套的精品资源，点击获取