痛點拆解：離開代碼 0 仍可能連錯機器
痛點 1：把「連得上」當成「連對了」。工作流程中 rsync、sftp -b、scp 只要具備使用者私鑰即可執行；若主機金鑰策略鬆散，DNS 污染、BGP 劫持、跳板誤設或暫時性 VIP 漂移都會放大風險。建置日誌只顯示傳輸位元組，無法揭露是否多了一跳中間人。
痛點 2：每個 Job 都重新 TOFU。GitHub 託管 Runner 檔案系統多為暫存，團隊常在步驟內動態 ssh-keyscan，等於每一趟流水線於不可控時刻重做「首次信任」，與內部維運在固定工作站手動確認一次完全不同。
痛點 3：多主機、多別名缺文件。正式區直連、預發佈經 ProxyJump、CI 專用上傳帳號對應不同 Host 行；指紋未與別名表綁定會出現「換了 DNS CNAME 卻悄悄換了金鑰」。
痛點 4：與 SSH CA 混談。SSH 使用者憑證回答「誰可登入」；known_hosts 回答「終端機以為在和誰通話」。僅上 CA 而不固定主機指紋，在惡意閘道情境仍可能被繞過；並發 Job 亦須與 MaxSessions 同冊管理，否則 MITM 與「連線額滿」日誌會混在一起。
威脅模型：為何仍要把主機金鑰納入變更管理
企業常將「建置產物上傳」視為高敏通道。主機金鑰驗證是 SSH 堆疊中將工作階段綁到具體機器的關鍵；放棄它等於把信任交給 DNS 與路由。StrictHostKeyChecking=accept-new 在互動式開發機尚可，在暫存 Runner 仍接近 TOFU；宜在流水線外覆核指紋後再把唯讀片段注入 Job。
UserKnownHostsFile 隔離 CI 與本機 known_hosts，利於稽核「誰核可了哪條指紋」。多跳 ProxyJump 應逐跳列出 Host 行與指紋來源，避免只驗證最末跳。
可量化基線
記錄 ssh -V 與主機金鑰相關版本說明；日誌列印不含金鑰材質的 Host 別名與 UserKnownHostsFile 路徑以利 Runbook 對照。
將「主機金鑰驗證失敗」獨立計數，勿與磁碟滿、權限拒絕合併。指紋輪換與系統重裝、映像重建綁定同一工單；並與 SHA256 產物清單、OIDC 憑證納入同一發佈審查，避免「使用者身分很現代、主機身分很隨意」。
決策矩陣
| 策略 | 適用 | 效益 | 風險 |
|---|---|---|---|
StrictHostKeyChecking=no | 封閉實驗網（仍不宜） | 摩擦最低 | 利於 MITM；合規難過 |
Job 內 ssh-keyscan | 早期原型 | 撰寫快 | 信任當次網路；與暫存 Runner 疊加風險最大 |
accept-new | 低敏內網 | 拒絕已記錄主機的突變 | 對「每次新檔案」的 CI 幫助有限 |
固定片段＋UserKnownHostsFile＋yes | 正式上傳、遠端 Mac 託管 | 可稽核、可輪換 | 需維護 Secrets 與流程 |
| 雲平台主機證明（若有） | 大量機器池 | 自動化高 | 依賴供應商能力 |
對照 跳板矩陣：多跳時逐跳撰寫 host key 策略，勿只寫最末行 rsync。
實作步驟
# 離線採集（勿在 Runner 首次掃描正式指紋）
# ssh-keyscan -p 22 -H remote-mac.example.com > ci_known_hosts.fragment
# GitHub Secret：SSH_KNOWN_HOSTS
# mkdir -p ~/.ssh && chmod 700 ~/.ssh
# printf '%s\n' "${{ secrets.SSH_KNOWN_HOSTS }}" > ~/.ssh/ci_known_hosts
# export RSYNC_RSH="ssh -o StrictHostKeyChecking=yes -o UserKnownHostsFile=$HOME/.ssh/ci_known_hosts"
# rsync -av ./dist/ user@remote-mac:/Volumes/builds/app/dist/
建議封裝為 composite action 以降低複製貼上誤差。
閱讀順序
本文 → OIDC 與上傳帳號 → SSH CA → scp／SFTP → SHA256 → 原子發佈 → 首頁。
聯合審查表應涵蓋別名、指紋、Secrets、輪換 RACI 與並發預算，避免「憑證完美但連錯機器」的假對立。
FAQ 與 SFTPMAC
指紋放 Secrets 算外洩嗎？
主機公鑰指紋屬公開資訊；仍應避免與使用者私鑰混於同一 Secret，並限制可見範圍。
重裝後流水線全紅？
正常，代表驗證有效；依工單更新 Secrets，可短暫並存雙指紋降低停機。
總結：主機金鑰驗證應升格為流水線設定，與 OIDC、專用帳號、完整性閘門並列。
限制：自建遠端 Mac 需自行維護映像、修補、指紋庫與 on-call；若希望穩定的 Apple 原生建置入口與可營運的 SFTP／rsync 面，SFTPMAC 託管遠端 Mac 讓團隊專注產物與發佈。
將 known_hosts、跳板與上傳工具寫入同一維運表，託管環境更易做到稽核與輪換。