つらみ：転送成功ログは「正しい相手」ではない証明にならない
デプロイ鍵やOIDCはクライアント側、ホスト鍵はサーバ本人性。バイト数は中間者を暴けない。空ディスクのRunnerで毎回scanは初見信頼の繰り返し。DNS・私設IP・bastion別名が混ざるとCNAMEやLBの裏で鍵だけ入れ替わり緩設定のまま緑が続く。ユーザーCAはホスト検証を代替しない。同一入口への並列では鍵不一致とセッション上限が混ざる。再利用YAMLに検査オフが潜むと後追い火消し。出口差で見える鍵だけずれる場合もあり、事前固定行なら異常が目立つ。チケットでSecretと承認を結び、OS再インストールや復元後は実鍵とSecretを必ず突き合わせる。
脅威モデル：ホスト鍵は変更管理の対象
成果物の価値を踏まえSSHはゲートウェイ級。ホスト鍵はDNSを超えてサーバ素材へ拘束する。対話端末の受け入れ新規もRunner空ディスクでは毎回「新規」に戻る。CI専用の別ファイルで個人の実験エントリを切り離す。bastionはホップごとに表へ。ProxyJumpノートに鍵表を同居。scpとSFTP移行後はホストエラーとパス意味エラーを分類。known_hostsの一行もロックファイル扱いでレビューとロールバックを揃え、ハッシュ表記は統一。DNSビュー分割ならエイリアス分割。公開鍵は秘密ではないがSecretで変更フローを揃え、秘密鍵と混ぜない。
測れる基準：「SSHが不安定」という曖昧さを潰す
イメージとmacOS更新のたびにsshバージョンと実際のknown_hostsパス、rsyncのHost別名をログへ（秘密は出さない）。ホスト検証失敗・権限・ディスクを別メトリクスに。OIDC変更と同チケで方針を書く。再インストール等ではSecretをセット更新しチェックサム票に別名とマニフェストを併記。地域別試験で鍵一致を定期確認。静的検査で検査オフと無説明scanを禁止。暗号化は盗聴対策でホスト固定は別。テンプレでcomposite必須化。
検査方針の判断表（CI向け）
| 方針 | 向く場面 | 利点 | 欠点 |
|---|---|---|---|
StrictHostKeyChecking=no | 本番不可 | 手早い | 中間者・監査不可 |
ジョブ内ssh-keyscan | 試作 | 速い | 毎回初見 |
accept-newのみ | ラボ | 変更拒否 | 初回が危険 |
固定行＋UserKnownHostsFile＋yes | 本番 | 監査可 | Secret要 |
| プラットフォーム証明 | 大規模 | 自動化 | 依存 |
原子リリースと組み合わせ、「どこでも信じるネットワーク」と「本番パス」を同居させない。
手順：Secretから検証付きrsyncへ
# Collect keys offline from a trusted admin host, not inside CI
# ssh-keyscan -p 22 -H remote-mac.example.com > ci_known_hosts.fragment
# ssh-keygen -lf ci_known_hosts.fragment
# Store fragment in GitHub Secret SSH_KNOWN_HOSTS (host keys only)
# 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 BatchMode=yes -o StrictHostKeyChecking=yes -o UserKnownHostsFile=$HOME/.ssh/ci_known_hosts'
# Append bastion lines when using ProxyJump; verify ordering matches ~/.ssh/config Host blocks
# rsync -av ./dist/ user@remote-mac:/Volumes/builds/app/dist/
# ssh user@remote-mac 'shasum -a 256 -c manifest.sha256'
オプション群はcomposite actionに閉じ、フォークやコピペで半端設定が増殖しないようにする。
読む順番とCTAの揃え方
推奨順：OIDC→ユーザー証明書→scp/SFTP→bastion→並列→チェックサム→原子リリース→トップ。
ホストだけ・ユーザーだけを極端に磨く偽二択を避け、別名・印・Secret名・オーナー・並列上限を一枚に。ビルドの正はリモートMacへ寄せローカルは編集に専念。勉強会で印確認と意図的不一致デモ。共有ビルダは組織Secret一元化。
FAQとSFTPMACのホスト型リモートMacが効くとき
ホスト公開鍵は秘密か
いいえ。ただしSecret化は改ざん耐性と変更フローを揃える。ユーザ秘密鍵と混ぜない。
RunnerのCPUでピンは分けるか
不要。Mac側が基準。DNS一貫性は重要。
jumpホストとアプリホストでSecretを共有してよいか
分離推奨。部分更新で片方だけ古くなる事故を防ぐ。
長寿命VMのセルフホストRunnerは
分離ファイルで個人汚染を避け、方針は揃える。
まとめ：ホスト鍵検証は個人の習慣のコピペではなく、CIの第一級設定として設計する。
限界：自前fleetは保守と当番が重い。入口と鍵運用を短時間で揃えたいならSFTPMACのホスト型リモートMacで、配送に集中できる。
鍵・bastion・転送手順を一枚のRunbookにまとめ、ローテを横断で追えるようにする。