企业官网建设流程全解析

1. 项目概述：为什么非得用rpm包升级OpenSSH到9.3？

最近在给一批生产环境的CentOS 7.9和Rocky Linux 8.6服务器做安全加固，核心诉求很明确：把系统默认的OpenSSH 7.4p1（CentOS 7）或8.0p1（RHEL 8系）一口气干掉，换成带完整CVE-2023-38408修复、支持FIDO/U2F密钥认证、启用现代加密套件（如chacha20-poly1305@openssh.com）的OpenSSH 9.3p1。不是源码编译，不是第三方仓库，就是原生rpm包——这是某金融行业客户审计清单里白纸黑字写的硬性要求：“必须使用经签名验证的二进制包，禁止任何未经批准的构建行为”。

你可能会问：直接yum update openssh不行吗？行，但行不通。主流发行版的官方仓库至今没上9.3，CentOS Stream 9最新才到9.2p1，Rocky 8.8默认还是8.7p1。等上游打包？不如自己动手。而rpm包升级这条路，表面看是“换几个文件”，实则是一场对系统底层依赖、服务生命周期、SELinux策略、PAM模块兼容性的全面压力测试。我试过三次全量回滚，两次ssh会话静默中断，一次sshd启动失败导致只能靠IPMI硬重启——这些坑，我都踩过了，也记下来了。

这个方案适合谁？第一类是政企、金融、能源行业的运维工程师，手头管着上百台物理机/虚拟机，安全合规是红线，不能动内核、不能换发行版、不能引入非标仓库；第二类是信创环境下的适配工程师，需要在麒麟V10、统信UOS等国产系统上，用符合等保2.0三级要求的方式完成SSH组件升级；第三类是想彻底搞懂Linux服务更新机制的中级系统管理员——因为rpm升级OpenSSH，本质上是在和systemd、libcrypto、glibc、PAM这四大系统基石掰手腕。

2. 整体设计思路与关键决策依据

2.1 为什么死磕rpm包，而不是源码编译或EPEL？

很多人第一反应是“编译最可控”。但实际落地时，源码编译在生产环境有三座大山：可审计性差、可回滚性弱、依赖污染重。审计方要的是GPG签名验证过的二进制包哈希值，不是你本地./configure时敲的参数；回滚时，make uninstall根本没法还原被覆盖的/etc/ssh/sshd_config备份、/usr/libexec/openssh/sftp-server的SELinux上下文、甚至/var/empty/sshd目录的权限位；更别说编译时链接的OpenSSL版本若和系统不一致，后续curl、wget、systemd-resolved全可能跟着出问题。

EPEL？它确实提供了较新版本，但EPEL 8目前最高只到9.0p1，且其包未针对RHEL/CentOS的SELinux策略做深度适配——我们实测发现EPEL的openssh-server在启用UsePrivilegeSeparation yes时，/var/empty/sshd目录的unconfined_u:object_r:var_empty_t:s0上下文会导致子进程无法创建socket，日志里全是setgroups() failed: Operation not permitted。这不是bug，是策略冲突。

rpm包升级的核心逻辑就一条：复刻官方构建流程，但替换源码和spec文件，生成完全兼容原发行版ABI的二进制包。我们用的是OpenBSD官方发布的openssh-9.3p1.tar.gz，配合RHEL 8.6的openssh.spec（来自src.rpm），仅修改三处：%define version 9.3p1、%define release 1%{?dist}、以及%patch段落里移除所有针对旧版OpenSSL的兼容补丁。整个过程不碰系统头文件、不改glibc版本号、不重建共享库符号表——就像给汽车换发动机，但连螺丝型号、扭矩参数、油路接口都严格按原厂图纸来。

2.2 为什么选9.3p1，而不是更新的9.4或9.5？

OpenSSH 9.4刚发布时，我们第一时间拉了代码看变更日志。发现两个致命点：一是它强制要求OpenSSL 3.0.7+，而RHEL 8.6默认是3.0.1，升级OpenSSL本身又是一场灾难（libssl.so.3ABI不兼容会导致dnf、podman、cockpit全挂）；二是新增的KexAlgorithms +diffie-hellman-group18-sha512在部分老旧网络设备（如某品牌防火墙的SSH管理端口）上握手直接超时，客户业务系统无法接受这种不确定性。

9.3p1是平衡点：它修复了2023年最危险的CVE-2023-38408（远程代码执行漏洞，CVSS 9.8分），支持FIDO2密钥登录（sk-ecdsa-sha2-nistp256@openssh.com），默认禁用ssh-rsa签名算法（SHA-1已不安全），同时保留对diffie-hellman-group14-sha256的完美兼容。我们拿9.3p1在客户真实网络里跑了两周压测，200+台服务器零故障，SSH连接成功率99.999%，这才是稳。

2.3 构建环境为何必须隔离？容器化构建是否可行？

答案是：必须用干净的chroot或容器，且容器镜像必须和目标系统完全一致。我们曾在一个装了Ansible、Docker、Python 3.11的开发机上直接rpmbuild，结果生成的rpm包安装后，sshd -t报错/lib64/libcrypto.so.1.1: version OPENSSL_1_1_1b not found。查了半天，发现是构建机上的openssl-devel包版本（1.1.1w）比目标系统（1.1.1k）高，rpmbuild自动链接了高版本符号。

解决方案是用mock工具——它是Fedora/RHEL官方推荐的隔离构建环境。命令就一行：

mock -r rocky-8-x86_64 --init mock -r rocky-8-x86_64 --install @buildsys-build openssl-devel pam-devel systemd-devel mock -r rocky-8-x86_64 --copyin openssh-9.3p1.tar.gz /builddir/build/SOURCES/ mock -r rocky-8-x86_64 --copyin openssh.spec /builddir/build/SPECS/ mock -r rocky-8-x86_64 --rebuild /builddir/build/SPECS/openssh.spec

mock会拉取纯净的Rocky 8.6 rootfs，装指定的构建依赖，然后在完全隔离的环境中跑rpmbuild。生成的rpm包，ldd /usr/sbin/sshd | grep ssl显示的永远是libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f...)，和系统原生路径严丝合缝。这比Docker手动维护基础镜像靠谱十倍——毕竟mock的配置文件/etc/mock/rocky-8-x86_64.cfg里，root = rocky-8-x86_64这行指向的是官方YUM仓库的精确快照。

3. 核心细节解析与实操要点

3.1 rpm包结构拆解：哪些文件动不得，哪些必须改？

一个标准的OpenSSH rpm包（以openssh-server-9.3p1-1.el8.x86_64.rpm为例）解压后，核心文件树如下：

/usr/sbin/sshd # 主守护进程，静态链接？不，动态链接！重点检查ldd输出 /usr/libexec/openssh/sftp-server # SFTP子系统，SELinux上下文必须为sshd_exec_t /etc/ssh/sshd_config # 配置文件，rpm升级默认不覆盖，但需预处理 /etc/pam.d/sshd # PAM配置，必须和系统pam版本匹配 /var/empty/sshd # chroot空目录，权限必须711，属主root:root /usr/share/man/man5/sshd_config.5 # 手册页，纯文档，无风险

其中三个文件是“高压线”：

• /usr/sbin/sshd：它动态链接libcrypto.so.1.1、libz.so.1、libpam.so.0。用readelf -d /usr/sbin/sshd | grep NEEDED确认依赖列表，必须和rpm -qf /lib64/libcrypto.so.1.1返回的包版本一致。我们曾因疏忽，在构建时多装了一个openssl11-devel，导致sshd链接了libcrypto.so.1.1.1，安装后所有SSH连接立即断开，journalctl -u sshd里只有Failed to load module "pam_keyinit.so"——其实是libpam加载libcrypto失败的连锁反应。

• /usr/libexec/openssh/sftp-server：这个文件在RHEL 8系默认SELinux策略下，必须是system_u:object_r:sshd_exec_t:s0类型。如果用cp手动复制，类型会变成unconfined_u:object_r:lib_t:s0，sshd启动时拒绝执行。正确做法是restorecon -v /usr/libexec/openssh/sftp-server，或在spec文件里加%files段：

  %attr(0755,root,root) %ghost %config(noreplace) /etc/ssh/sshd_config %attr(0755,root,root) %dir /var/empty/sshd %attr(0711,root,root) /var/empty/sshd %attr(0755,root,root) %file /usr/libexec/openssh/sftp-server %verify(not md5 mtime size) %attr(0755,root,root) /usr/libexec/openssh/sftp-server

• /etc/ssh/sshd_config：rpm升级默认策略是%config(noreplace)，即新包里的配置文件不会覆盖已修改的旧文件。但9.3p1引入了CASignatureAlgorithms、HostKeyAlgorithms等新指令，旧配置里没有。我们的解法是：在spec文件%post脚本里加一段逻辑：

  if ! grep -q "^CASignatureAlgorithms" /etc/ssh/sshd_config; then echo "CASignatureAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521" >> /etc/ssh/sshd_config echo "HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256" >> /etc/ssh/sshd_config systemctl reload sshd fi

  这样既不破坏用户原有配置，又能平滑启用新特性。

3.2 SELinux策略适配：绕不开的“隐形墙”

在RHEL/CentOS系，SELinux是默认开启的。OpenSSH 9.3p1的sshd进程运行在system_u:system_r:sshd_t:s0-s0:c0.c1023域，它需要访问的资源都有严格标签。最常踩的坑是/var/log/secure写入失败——日志里报avc: denied { write } for pid=1234 comm="sshd" name="secure" dev="dm-0" ino=123456 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=0。

原因很简单：9.3p1默认启用了UsePAM yes，而PAM模块pam_faillock.so尝试写/var/log/faillog时，触发了sshd_t域对faillog_t类型的访问限制。解决方法不是关SELinux（审计通不过），而是打自定义策略模块：

# 先抓拒绝日志 ausearch -m avc -ts recent | audit2why # 生成策略 ausearch -m avc -ts recent | audit2allow -M mysshd # 安装策略 semodule -i mysshd.pp

但更稳妥的做法，是在构建rpm前，把mysshd.te策略文件集成进spec：

%package server Summary: An open source implementation of the SSH protocol License: BSD %if %{with selinux} Requires(post): policycoreutils-python-utils %endif %post server %if %{with selinux} if [ -f /usr/share/selinux/packages/mysshd.pp ]; then semodule -i /usr/share/selinux/packages/mysshd.pp fi %endif

这样，rpm安装时自动加载策略，无需运维手动操作。我们实测，这套策略让9.3p1在Enforcing模式下稳定运行3个月，零SELinux告警。

3.3 PAM模块兼容性：别让登录变“黑洞”

OpenSSH 9.3p1对PAM的调用更严格。旧版/etc/pam.d/sshd里常见的auth [default=ignore] pam_succeed_if.so user ingroup nopasswdlogin在9.3p1下会直接跳过密码验证，导致所有用户免密登录——这是严重安全漏洞。

根源在于9.3p1的auth栈执行顺序变了。它现在要求pam_faillock.so必须在pam_unix.so之前，否则faillock无法记录失败次数。正确的/etc/pam.d/sshd头部应为：

#%PAM-1.0 auth [default=die] pam_faillock.so preauth silent deny=3 unlock_time=600 auth [default=die] pam_faillock.so authfail deny=3 unlock_time=600 auth [success=ok default=ignore] pam_unix.so try_first_pass auth [default=bad success=ok] pam_faillock.so authsucc

我们在rpm的%post脚本里加了校验逻辑：

if ! grep -q "pam_faillock\.so.*preauth" /etc/pam.d/sshd; then sed -i '/^auth.*pam_unix\.so/ i\auth [default=die] pam_faillock.so preauth silent deny=3 unlock_time=600' /etc/pam.d/sshd sed -i '/^auth.*pam_unix\.so/ a\auth [default=die] pam_faillock.so authfail deny=3 unlock_time=600' /etc/pam.d/sshd fi

提示：pam_faillock模块在RHEL 8.6中默认已安装，但它的数据库/var/run/faillock/目录权限必须是drwx------. root root system_u:object_r:faillog_t:s0。我们用%post脚本确保：mkdir -p /var/run/faillock && chown root:root /var/run/faillock && chmod 700 /var/run/faillock && restorecon -v /var/run/faillock。

4. 实操过程与核心环节实现

4.1 构建环境准备：mock配置与依赖安装

第一步，安装mock并初始化构建环境。注意：mock必须用系统自带版本，不要pip install mock——那是Python测试框架，不是RPM构建工具。

# Rocky Linux 8.6 dnf install -y epel-release dnf install -y mock # 将当前用户加入mock组，否则需sudo usermod -a -G mock $USER # 重新登录使组生效 newgrp mock

mock配置文件位于/etc/mock/rocky-8-x86_64.cfg。我们修改两处关键参数：

• chroot_setup_cmd = install @buildsys-build openssl-devel pam-devel systemd-devel gcc make rpm-build
• plugin_conf = { 'ccache_enable': False, 'selinux_enable': True }（必须开SELinux，否则构建出的包缺少策略标签）

初始化环境：

mock -r rocky-8-x86_64 --init # 安装构建依赖（注意：这里装的是构建时依赖，不是运行时依赖） mock -r rocky-8-x86_64 --install @buildsys-build openssl-devel pam-devel systemd-devel gcc make rpm-build # 检查是否成功 mock -r rocky-8-x86_64 --shell 'rpm -q openssl-devel pam-devel'

注意：openssl-devel版本必须和目标系统一致。用rpm -q --qf '%{VERSION}-%{RELEASE}\n' openssl-devel查目标机版本，然后在mock里装同版本。我们遇到过一次，mock里装了openssl11-devel-1.1.1w-2.el8，而目标机是1.1.1k-5.el8，结果sshd链接失败。解决方案是：从目标机rpm -q --dump openssl-devel | grep -E "(source|build)"拿到源码包URL，用mock下载并安装。

4.2 spec文件定制：从RHEL源码包提取并改造

去Red Hat Package Database（https://pkgs.devel.redhat.com/cgit/rpms/openssh/）下载RHEL 8.6的openssh-8.7p1-1.el8.src.rpm。解包：

rpm2cpio openssh-8.7p1-1.el8.src.rpm | cpio -idmv # 得到 openssh-8.7p1.tar.gz 和 openssh.spec

用openssh-9.3p1.tar.gz替换原tar包，并修改openssh.spec：

• 第7行：Version: 9.3p1
• 第8行：Release: 1%{?dist}（保持%{?dist}，确保生成el8后缀）
• 第32行：Source0: openssh-9.3p1.tar.gz
• 删除第120行附近的%patch1001 -p1（这是RHEL 8.6的私有补丁，9.3p1已内置）
• 在%build段末尾加：

  # 强制使用系统OpenSSL，不自带 ./configure \ --sysconfdir=/etc/ssh \ --localstatedir=/var \ --with-pam \ --with-selinux \ --with-privsep-path=/var/empty/sshd \ --with-ssl-dir=/usr \ --with-zlib=/usr \ --with-ldflags="-Wl,-z,relro -Wl,-z,now"

最关键的是%files段，必须精确匹配RHEL 8.6的文件列表。我们用rpm -qlp openssh-server-8.7p1-1.el8.x86_64.rpm > old-files.txt导出旧包文件，再用rpm -qlp openssh-server-9.3p1-1.el8.x86_64.rpm > new-files.txt（先用mock构建一个测试包）对比，确保/usr/libexec/openssh/sftp-server、/usr/lib/systemd/system/sshd.service等路径完全一致。

4.3 构建与签名：GPG密钥的正确姿势

构建命令：

mock -r rocky-8-x86_64 --rebuild /path/to/openssh.spec

构建成功后，rpm包在/var/lib/mock/rocky-8-x86_64/result/目录下。此时必须签名，否则dnf install会报GPG key verification failed。

生成GPG密钥（仅首次）：

gpg --full-generate-key # 选RSA，4096位，永不过期，邮箱填运维组邮箱 # 记住passphrase，后面要用

导出公钥供客户验证：

gpg --export -a "运维组" > RPM-GPG-KEY-openssh93

签名rpm包：

rpm --addsign openssh-9.3p1-1.el8.x86_64.rpm # 输入GPG passphrase

注意：rpm --addsign必须用和构建环境相同的GPG密钥环。我们把密钥环放在/root/.gnupg，并在mock配置里加：config_opts['environment']['GNUPGHOME'] = '/root/.gnupg'，确保mock内也能调用。

4.4 部署与验证：滚动升级的黄金四步法

我们绝不一次性全量升级。采用“1台测试→5台灰度→50台分批→全量”的四步法，每步都带验证脚本。

Step 1：单机测试（1台）

# 备份原包 rpm -q openssh-server > /root/openssh-backup.txt # 安装新包（--force强制覆盖，--nodeps跳过依赖检查——但实际不建议跳） dnf install --force --nogpgcheck openssh-9.3p1-1.el8.x86_64.rpm # 验证 sshd -t && echo "配置语法OK" systemctl restart sshd && echo "服务重启OK" ssh -o ConnectTimeout=5 -o BatchMode=yes localhost 'echo OK' && echo "本地连接OK"

Step 2：灰度部署（5台）
用Ansible批量执行，但加--limit控制范围：

- name: Upgrade OpenSSH to 9.3p1 hosts: ssh-servers become: true tasks: - name: Install RPM dnf: name: "/tmp/openssh-9.3p1-1.el8.x86_64.rpm" state: present disable_gpg_check: no # 必须开GPG检查 - name: Verify SSH connection command: ssh -o ConnectTimeout=5 -o BatchMode=yes {{ inventory_hostname }} 'echo OK' register: ssh_test ignore_errors: yes - name: Fail if SSH broken fail: msg: "SSH connection failed on {{ inventory_hostname }}" when: ssh_test.failed

Step 3：分批升级（50台）
用dnf的--assumeyes和--setopt=install_weak_deps=False避免意外安装弱依赖：

for host in $(cat server-list-50.txt); do scp openssh-9.3p1-1.el8.x86_64.rpm $host:/tmp/ ssh $host "dnf install -y --setopt=install_weak_deps=False /tmp/openssh-9.3p1-1.el8.x86_64.rpm" ssh $host "sshd -t && systemctl restart sshd" done

Step 4：全量与审计
升级完成后，用脚本生成审计报告：

#!/bin/bash echo "=== OpenSSH 9.3p1 Audit Report ===" echo "Date: $(date)" echo "Total servers: $(wc -l < server-list-all.txt)" echo "Version check:" for h in $(cat server-list-all.txt); do ver=$(ssh $h "rpm -q openssh-server | cut -d- -f3") echo "$h: $ver" done | grep -v "9.3p1" echo "SELinux status:" for h in $(cat server-list-all.txt); do se=$(ssh $h "getenforce") echo "$h: $se" done | grep -v "Enforcing"

5. 常见问题与排查技巧实录

5.1 问题速查表：从现象到根因的秒级定位

5.2 独家避坑技巧：那些文档里不会写的细节

• 技巧1：sshd -T的隐藏参数
  sshd -T能输出当前生效的全部配置，但它默认只读/etc/ssh/sshd_config。如果你在/etc/ssh/sshd_config.d/下放了碎片化配置（如10-custom.conf），sshd -T会忽略！正确命令是：sshd -T -f /etc/ssh/sshd_config -o Include=/etc/ssh/sshd_config.d/*.conf。我们把这个命令封装成/usr/local/bin/sshd-debug，每次改配置必跑。

• 技巧2：systemd服务文件的静默陷阱
  RHEL 8.6的/usr/lib/systemd/system/sshd.service里有一行ExecStartPre=/usr/sbin/sshd -t，它会在sshd启动前做语法检查。但9.3p1的sshd -t会检查/etc/ssh/sshd_config.d/下的所有文件，如果某个碎片配置语法错误，整个服务启动失败。我们的解法是：在%post脚本里加sshd -t -f /etc/ssh/sshd_config || { echo "Config error!"; exit 1; }，提前拦截。

• 技巧3：/var/empty/sshd目录的“幽灵权限”
  这个目录必须是711权限，但rpm -V openssh-server检查时，它总显示.......UG. c /var/empty/sshd（G位异常）。这是因为rpm校验时认为/var/empty/sshd应该属于root:root，但实际chown root:root /var/empty/sshd后，ls -l显示drwx--x--x.，G位是x不是-。解决方案是：在spec文件%files段加%attr(0711,root,root) /var/empty/sshd，并确保%post脚本里有chmod 711 /var/empty/sshd。

• 技巧4：回滚的“后悔药”
  如果升级后出问题，最快回滚不是dnf downgrade（它可能删掉依赖），而是：

  # 1. 停服务 systemctl stop sshd # 2. 强制重装旧包（从本地缓存） dnf reinstall --force --nogpgcheck $(rpm -q openssh-server --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm' \| sed 's/9.3p1/8.7p1/') # 3. 恢复配置备份（rpm会自动备份为sshd_config.rpmsave） mv /etc/ssh/sshd_config.rpmsave /etc/ssh/sshd_config # 4. 启动 systemctl start sshd

  我们把这四行写成/usr/local/bin/ssh-rollback.sh，放在所有服务器上，30秒内恢复。

5.3 性能与安全验证：不只是“能用”，还要“好用”

升级不是终点，验证才是。我们用三类工具交叉验证：

• 安全扫描：用ssh-audit.py（https://github.com/jtesta/ssh-audit）扫9.3p1：

  python3 ssh-audit.py target-server # 关键看： # - KexAlgorithms: 必须包含`curve25519-sha256`，禁用`diffie-hellman-group1-sha1` # - ServerHostKeyAlgorithms: 必须包含`ecdsa-sha2-nistp256`，禁用`ssh-rsa` # - EncryptionAlgorithms: 必须包含`chacha20-poly1305@openssh.com`

• 性能压测：用parallel-ssh并发100个连接：

  seq 1 100 \| parallel -j 20 ssh -o ConnectTimeout=3 -o BatchMode=yes target-server 'echo OK' # 监控`sshd`进程CPU：`top -p $(pgrep -f "sshd:" \| head -1)`，9.3p1在100并发下CPU峰值<35%，比8.7p1低12%（因Chacha20硬件加速）

• 协议兼容性：用老设备实测。我们拿了三台设备：Windows 7自带OpenSSH（7.7p1）、某品牌路由器（SSH 2.0）、Java 8的JSch库（1.53）。结果：Windows 7和路由器握手成功，JSch需升级到1.55+。这说明9.3p1的降级兼容做得足够好。

最后分享一个小技巧：在/etc/ssh/sshd_config末尾加一行# OpenSSH 9.3p1 deployed on $(date +%F)，这样未来审计时，一眼就能看出哪台服务器升级了，时间戳也清晰。运维的终极浪漫，就是让每一行配置都带着温度和时间印记。