处理这次漏洞，最容易漏的是第二步：软件包安装完成，正在接受连接的旧进程不一定已经替换。下面以 alpine + openrc、由系统软件包提供的 sshd 为例。维护前保留当前会话，确认有云控制台或其他可用管理入口。自定义服务按实际管理方式操作。
先按系统分支对照包版本
| Alpine 分支 | 首个修复 openssh 包版本 |
|---|---|
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
版本表来自 Alpine 官方公告。较旧分支收到本次回移补丁，并不等于恢复常规维护。若镜像源仍未同步，先确认仓库分支和候选包，不要为了版本号混用 edge 与稳定源。
升级、检查、重启，分三步执行
# 先看系统分支和候选包（管理员执行） cat /etc/alpine-release apk update apk policy openssh-server openssh-server-pam apk info -v | grep '^openssh' # 按官方建议更新当前分支的软件包；此命令也会更新其他包 apk upgrade -U -a
如果生产变更只允许更新 OpenSSH，先在测试环境按实际安装的软件包名验证定向升级和依赖结果。升级完成后确认包已达到相应分支修复版本，再检查配置并重启：
apk info -v | grep '^openssh' sshd -t && rc-service sshd restart rc-service sshd status
另开窗口用平时使用的密钥从真实入口登录，验证需要的管理权限以及自动化依赖，再关闭旧会话。若服务无法启动，先通过原会话或控制台检查配置和日志；不要把已知易受攻击的旧版本重新暴露到公网。
暂不能升级时，如何关闭密码认证
先验证现有账号的密钥登录，并备份配置。在实际生效的配置中设定 PasswordAuthentication no，核对包含文件和适用的 Match 规则，不要只在文件末尾追加一行。执行 sshd -t，确认成功后重启，使用 sshd -T 或带连接条件的查询确认有效值。随后测试密钥可用，并检查自动化是否依赖密码登录。安排后续补丁升级。
升级前先定位实际运行的 sshd
从监听端口追到服务实例，再从实例追到软件包。例：某台机器同时安装系统 OpenSSH 和自编译 sshd，22 端口由前者监听，2222 端口由后者监听。升级 apk 包只能覆盖前者，两个端口必须分别验收。若主机通过端口映射提供 SSH，还要查映射后的目标进程。
# 在服务端以管理员身份检查；精简镜像可能未安装 ss cat /etc/os-release ps -ef | grep '[s]shd' ss -ltnp apk info -v | grep '^openssh' # 已确认真实监听进程 PID 时，将 1234 替换为该 PID readlink /proc/1234/exe # 对照 Alpine 3.24 分支的示例：比较完整包版本（实际版本自行替换） apk version -t 10.3_p1-r2 10.3_p1-r2
版本比较结果为 表示低于修复线，= 为达到该修复线，> 为更高。这个比较只在同一可信仓库、同一分支和同一包的语境下有意义；自编译、定制镜像和其他发行版要找自己的补丁记录。
把恢复入口准备好，再改线上认证
- 保持原管理会话，并实际进入云控制台或带外终端，确认它可以在 SSH 中断时使用。记录端口、管理网来源、堡垒机路径、配置路径和服务名。
- 备份主配置、被 Include 引入的文件、服务启动参数及权限。不要覆盖既有备份，不要把主机私钥复制到共享目录。
- 对每条关键接入链路验证现有公钥登录：运维账号、跳板机、备份任务、CI 部署和仅 SFTP 的账户。密码依赖还未迁移时，可先收紧入口或优先安装补丁。
定向升级示例：只在匹配的安装方式下使用
若包清单确认使用 openssh-server，可先模拟定向变更；PAM 版用实际安装的包名。检查候选版本和依赖，不在这次操作中顺带切换 PAM 变体或仓库分支。
apk upgrade --simulate openssh-server # 确认候选包含修复且依赖变更符合预期，再执行 apk upgrade openssh-server # 启动参数没有自定义配置路径时 sshd -t && rc-service sshd restart rc-service sshd status
如果服务启动使用自定义 -f，语法和有效配置检查也要使用该路径；如果由容器或自定义 supervisor 托管，按实际管理方式替换监听进程，不能只重启宿主机上的服务。供应商回移补丁与上游 10.6p2 是不同交付方式。
按账号和来源验证认证策略
# 按实际运维账号、客户端来源和服务端监听地址替换示例值 sshd -T -C 'user=ops,host=jump.example,addr=192.0.2.10,laddr=192.0.2.20,lport=22' | grep -E '^(passwordauthentication|pubkeyauthentication|kbdinteractiveauthentication|authenticationmethods|permitrootlogin) ' # 从另一个客户端窗口强制走公钥，替换账号、地址及端口 ssh -o BatchMode=yes -o PreferredAuthentications=publickey -p 22 ops@192.0.2.20
如果临时禁用密码认证，预期有效配置显示 passwordauthentication no，并且新公钥会话可以建立。对存在 Match 的配置，至少分别抽查运维网与非运维网、普通账号与受特殊规则约束的账号。KbdInteractiveAuthentication 是另一项设置；若组织要求完全禁用交互式口令，应单独核对，避免误伤依赖 PAM 的多因素认证。
三个常见失败：怎么恢复
-
服务没有启动：保留原会话，通过控制台查看服务状态和日志；用真实启动配置重跑
sshd -t，检查不存在的主机密钥、配置错误及端口占用。 -
服务在线但新会话被拒：检查跳板机、防火墙及安全组，再检查用户名、密钥、
AuthorizedKeysFile和文件权限。以服务端日志为准，不把放宽权限当作第一步。 -
仍可用密码登录：检查是否连错监听端口、连到旧节点，或被包含文件和
Match改写。若必须回退到允许密码的旧配置，先限制网络暴露，避免重新开放受影响路径。
验收记录：资产与端口、补丁依据、升级前后完整包号、服务替换时间、真实入口的新连接结果、自动化与 SFTP 验证、暂时例外及到期时间。配置查询参数见 sshd 手册。
