痛点拆解：绿色退出码同样救不了「你连的可能不是那台 Mac」
痛点 1：把「能连上」当成「连对了」。流水线里 rsync、sftp -b、scp 只要拿到用户私钥就能跑通；若主机密钥策略松散，攻击面在 DNS 污染、BGP 劫持、错误跳板或临时 VIP 漂移时会被放大。构建日志只显示传输字节，不会告诉你中间是否多了一跳。
痛点 2：每次 Job 都重新 TOFU。GitHub 托管 Runner 文件系统多为临时态，团队习惯在 step 里动态 ssh-keyscan。这等于每一趟流水线都在不可控时刻重新「首次信任」，与内网运维在固定工作站上手工确认一次完全不同。
痛点 3：多主机、多别名矩阵缺文档。生产直连、预发经 ProxyJump、CI 专用上传账号各自对应不同 Host 行；指纹未与别名表绑定会导致「换了个 DNS CNAME 就默默换了密钥」。
痛点 4：与用户侧 SSH CA 方案混谈。SSH 用户证书解决的是「谁被允许登录」；known_hosts 解决的是「终端以为自己在和谁说话」。只上 CA 不固定主机指纹，会在恶意网关场景下被绕过；并发 Job 还需与 MaxSessions 同册，否则 MITM 与「会话打满」日志会混在一起。
威胁模型：为什么 2026 年仍要把主机密钥写进变更管理
企业侧常把「构建产物上传」视为高敏通道。主机密钥验证是 SSH 栈里把会话绑定到具体机器的关键机制；放弃它等于把信任交给 DNS 与路由。StrictHostKeyChecking=accept-new 在交互机上尚可，在临时 Runner 上仍近 TOFU；应在流水线外复核指纹再把只读片段注入 Job。
UserKnownHostsFile 隔离 CI 与本机 known_hosts，便于审计「谁批准了哪条指纹」。多跳 ProxyJump 须逐跳列 Host 行与指纹来源，避免只校验末跳。
可量化基线：用六条指标结束「感觉 SSH 很玄学」
记录 ssh -V 与 host key 相关发行说明；日志打印不含密钥材料的 Host 别名与 UserKnownHostsFile 路径，便于 Runbook 对照。
第三，把「主机密钥验证失败」单独计数，不与磁盘满、权限拒绝合并统计。第四，指纹轮换与系统重装、镜像重建绑定同一工单模板；并与 SHA256 产物清单、OIDC 凭据纳入同一发布评审，避免「用户身份很现代、主机身份很随意」。
决策矩阵：StrictHostKeyChecking、accept-new、scan-on-the-fly 与固定片段
| 策略 | 适用 | 收益 | 风险 |
|---|---|---|---|
StrictHostKeyChecking=no | 仅限封闭实验网（仍不推荐） | 最少摩擦 | 主动 MITM 友好；合规几乎不可能通过 |
Job 内 ssh-keyscan | tee | 早期原型 | 写得快 | 把信任交给当次网络；与临时 Runner 叠加风险最大 |
accept-new | 低敏内网、强网络边界 | 拒绝已记录主机的突变 | 对 CI「每次都是新文件」场景收益有限 |
固定片段 + UserKnownHostsFile + yes | 生产上传、远程 Mac 托管、跨公网 | 可审计、可轮换、可复现 | 需维护 Secrets 与变更流程 |
| 证书或 KMS 侧主机证明（若基础设施提供） | 大规模机器池 | 自动化程度高 | 依赖云平台能力；仍需理解 SSH 客户端校验路径 |
读完仍犹豫时对照 跳板矩阵：多跳时逐跳写 host key 策略，勿只写末行 rsync。
实操步骤：从 Secrets 到 rsync 的最小闭环
# 0) 受控环境采集（不要在 Runner 上首次扫描生产指纹）
# ssh-keyscan -p 22 -H remote-mac.example.com > ci_known_hosts.fragment
# ssh-keygen -lf ci_known_hosts.fragment
# 1) 将 fragment 全文写入 GitHub Secret：SSH_KNOWN_HOSTS
# 2) Workflow 片段：写入独立文件并强制校验
# mkdir -p ~/.ssh && chmod 700 ~/.ssh
# printf '%s\n' "${{ secrets.SSH_KNOWN_HOSTS }}" > ~/.ssh/ci_known_hosts
# chmod 644 ~/.ssh/ci_known_hosts
# export RSYNC_RSH="ssh -o StrictHostKeyChecking=yes -o UserKnownHostsFile=$HOME/.ssh/ci_known_hosts"
# 3) 与跳板同用时为每跳追加 Host 行（示例为双跳）
# cat >> ~/.ssh/ci_known_hosts <<'EOF'
# bastion.example.com ssh-ed25519 AAAA...
# remote-mac.internal ssh-ed25519 BBBB...
# EOF
# 4) 上传后跑 SHA256 清单（与完整性文对齐）
# rsync -av ./dist/ user@remote-mac:/Volumes/builds/app/dist/
# ssh user@remote-mac 'shasum -a 256 -c manifest.sha256'
# 5) 主机密钥轮换：并行双指纹窗口 + 工单编号写进 commit message
建议把 ssh 选项封装为 composite action，减少复制粘贴。
强相关 CTA：先主机身份，再用户身份，再工具语义，再完整性
推荐阅读顺序：本文 → OIDC 与专用上传账号 → SSH CA 用户证书 → scp/SFTP 迁移 → SHA256 闸门 → 原子发布 → 首页了解托管资源池。
顺序若颠倒，会出现「用户证书很完美但连到了错误机器」或「主机密钥很严但 scp 通配符仍随机失败」的假对立；联合评审表应覆盖别名、指纹、Secrets、轮换 RACI 与并发预算。
FAQ 与为什么考虑 SFTPMAC 托管远程 Mac
指纹存在 Secrets 里算泄露吗？
主机公钥指纹是公开信息；仍需防止私钥与用户证书私钥与之混放一个 Secret。拆分命名与最小可见范围（environment / org）。
远程 Mac 重装后流水线全红？
正常，说明校验生效；按工单更新 Secrets，可短时双指纹降停机。
总结：在 2026 年的供应链与合规语境下，主机密钥验证应从「开发者本机习惯」提升为「流水线配置项」，与 OIDC、专用账号、完整性闸门同册管理。
局限：自建远程 Mac 需要你自己维护镜像、补丁、指纹库与 on-call；若希望把稳定在线的 Apple 原生构建入口与可运营的 SFTP/rsync 面打包交付，减少 DIY 主机密钥与并发排障的隐性成本，SFTPMAC 托管远程 Mac 让团队把精力放在产物与发布，而不是反复修补 Runner 捷径。
把 known_hosts、跳板与上传工具写进同一张运维表，托管环境更容易做到变更可审计与指纹可轮换。