同一套环境里，宿主机、业务容器、调试容器和云模板可能分别有自己的 ssh 服务。修好一台正在运行的机器，并不会同步修好下一次扩容使用的镜像。cve-2026-123158 排查应该把“运行实例”和“生成实例的模板”列成两份清单。
云主机：看启动后的配置
Alpine 公告特别提醒，部分较早的官方 tiny-cloud 镜像包含仅密钥使用的 alpine 账号，且该账号可以通过 doas 提权。镜像首次启动时可能不满足攻击条件，但初始化脚本或后续操作改变了账户状态，风险也可能改变。核对镜像版本、启动脚本、有效认证设置及管理入口，不要仅凭“镜像默认如此”判断。Alpine 云镜像说明
先处理正在运行的实例，再更新镜像模板和自动扩容配置；对新镜像启动一台验证机，确认 SSH 软件包、认证方式和管理权限符合预期。逐步替换老节点，记录未完成或必须暂时隔离的机器。
容器：先确定是否真的跑了 sshd
docker ps --format '{{.Names}} {{.Image}} {{.Ports}}'
# CONTAINER 替换成实际容器名
docker top CONTAINER
docker exec CONTAINER apk info -v
Alpine 基础镜像并不等于容器在运行 SSH 服务。不运行 sshd 的容器，不属于该容器内服务端漏洞的触发场景；宿主机和专用调试容器要单独核对。有 SSH 服务的容器，应从含修复包的基础镜像或仓库重新构建，再替换运行实例。不要只修一个容器后继续沿用旧镜像。验收时核对所有副本的镜像摘要及实际运行的软件包，并确认旧副本已经退出。
建立修复清单：从入口一直追到模板
| 对象 | 必须记录 | 修复后证据 |
|---|---|---|
| 云主机、堡垒机 | 实例 ID、IP、端口、系统分支、包号、SSH 来源限制 | 修复包号、新连接结果、实例状态 |
| 容器 | 宿主机、服务名、容器端口、镜像标签与摘要、是否实际运行 sshd | 新容器 ID、镜像摘要、容器内包号 |
| 集群与镜像模板 | 命名空间、工作负载、部署模板版本、镜像构建入口、扩容配置 | 新模板版本、滚动更新状态、所有副本实际镜像 |
优先级可按公网入口、合作方或共享网络、内部管理网排序。不要把“只能经堡垒机进入”等同于完全无风险；同时排查堡垒机自身和它可访问的内部 SSH 实例。若不确定服务来源，将其标记为待核验，避免扫完包清单便自动关闭工单。
云主机：逐批修复，避免同时切断管理面
- 从一台具有控制台救援入口的非关键节点开始。按同分支修复包更新，保留原会话，重启实际监听的 sshd，从正常管理链路测试新登录。
- 先验证备份、发布、远程监控和堡垒机通路，再按环境或可用区逐批推开。失败节点停止扩批、限制 SSH 来源并保留回查信息。
- 用已修复且通过测试的基础镜像生成新模板；核查初始化脚本是否把
PasswordAuthentication打回yes，或者从旧软件仓库装回服务端。 - 启动一台新实例做扩容验收。只有现有节点和新启动节点都通过，才关闭漏洞工单。对可能已失陷的节点，走隔离和重建流程，避免用其系统盘制作基础镜像。
Docker Compose：区分直接拉镜像与自建镜像
以下假设服务名为 ssh-service，请替换为实际服务名；只有确实运行 sshd 的容器才需要按此路径更新。先确认持久卷、挂载的授权密钥、主机密钥管理和业务健康检查，切勿为升级删除数据卷。
# 直接引用镜像：先在配置中指定已核实的修复标签或摘要 docker compose pull ssh-service docker compose up -d --no-deps --force-recreate ssh-service # 自建镜像：先更新 Dockerfile 的基础镜像或可信 apk 软件源 docker compose build --pull ssh-service docker compose up -d --no-deps --force-recreate ssh-service # 只执行与实际部署匹配的一条路径，然后检查 docker compose ps ssh-service docker compose exec -T ssh-service apk info -v docker compose logs --since=15m ssh-service
--pull 不会替你修改锁定的旧镜像摘要；单独执行 pull 或 restart 也不能证明容器已换成修复镜像。若出现主机密钥指纹变化，先从可信控制面验证新指纹，再更新信任记录；不要通过关闭主机密钥检查绕过告警。Docker Compose 官方文档
Kubernetes：先改声明文件，再核对实际副本
将已验证镜像的不可变摘要写入实际部署来源（例如 GitOps 或 Helm 配置），并通过原发布流程部署。不要只进入一个 Pod 运行 apk 更新：替换、重启或扩容后会回到原镜像。下列命令是读取验证示例，名称按实际部署替换。
kubectl -n apps rollout status deployment/ssh-service --timeout=5m kubectl -n apps get pods -l app=ssh-service -o wide kubectl -n apps get pods -l app=ssh-service -o custom-columns='POD:.metadata.name,IMAGE:.status.containerStatuses[*].imageID'
除了 Deployment，继续检查 StatefulSet、DaemonSet、Job、常驻调试容器以及节点宿主机。若新副本没有就绪，检查镜像拉取权限、服务端配置、探针、端口和资源限制；若只能回到有漏洞的旧构建，先保持入口隔离。不要把一次 rollout 成功当作全部节点修复完成。
上线后对账：避免“修了今天，明天又扩出旧版”
对账现有实例数与修复实例数、已替换副本数与预期副本数、模板版本与实际新实例镜像。随机从真实跳板机验证登录，再检查各来源网段的访问限制。若镜像仓库仍保留旧标签，把它标记为禁止用于新部署；将补丁证据和镜像摘要纳入发布记录。
