2026 年リモート Mac sshd ホスト鍵ローテーション：UpdateHostKeys、Ed25519 移行、二重鍵ウィンドウと CI known_hosts

監査対応、マシン入替、古い RSA ホスト鍵の廃止——いずれもリモート Mac の OpenSSH サーバでホスト鍵の計画ローテーションが必要になる。サーバ側だけ差し替え、CI に固定した known_hosts を放置すると、深夜の rsync が一斉に REMOTE HOST IDENTIFICATION HAS CHANGED で止まる。これは検査が厳しすぎるのではなく、変更管理が半分しか回っていないサインだ。本稿は UpdateHostKeys、Ed25519 への移行、二重鍵併存ウィンドウ、GitHub Actions との同期を Runbook 化し、known_hosts 固定・ControlMaster・OIDC デプロイ と接続する。

ローテを「再インストールの事故」にしない

つらみ①：事後対応の指紋更新。macOS アップグレードや Time Machine 復元のあと、/etc/ssh/ssh_host_* だけ新しくなり、known_hosts 記事の Secret は三年前のまま。ログは rsync の帯域やオプション疑いになり、本丸のホスト鍵不一致が埋もれる。

つらみ②：ControlPersist が換鍵を隠す。ControlMaster の master が生きている間は新鍵でも古い検証済みセッションを使い続け、切断時に一斉赤化する。ローテ前後は ssh -O exit か ControlPersist 短縮を計画に入れる。

macOS sshd：HostKey 列と Ed25519 追加

使用中の秘密鍵ファイルを上書きしない。新ファイル名で ssh-keygen -t ed25519 し、sshd_config の HostKey に追記、sshd -t のあと launchd で再読込する。Ed25519 は短く検証が速く、2026 年のデフォルト候補として妥当だ。レガシー RSA は移行期のみ残し、スキャナや古いクライアント向けに読み取り可能にしておく。

sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo launchctl kickstart -k system/com.openssh.sshd

フィンガープリント採取は帯外の信頼できる端末から ssh-keyscan -t ed25519 し、Runner 上の初回接続で Secret を書き換えない。TOFU を CI の一時ネットワークに委ねると監査で説明できない。

UpdateHostKeys：人間用。Runner の代替ではない

OpenSSH 8 以降の UpdateHostKeys は、サーバが新しいホスト鍵素材を出したとき、対話端末の known_hosts を更新する仕組みだ。運用者のノート PC では ask や accept-new が摩擦を下げる。

GitHub Actions では逆に、StrictHostKeyChecking=yes と専用 UserKnownHostsFile を維持する（固定記事参照）。ディスクは毎回空。自動更新は「誰がいつ承認したか」を残せない。Job 先頭で Secret から ci_known_hosts を書く。

二重鍵ウィンドウ：T0→T1 の三幕

T0：サーバが旧 RSA と新 Ed25519 を同時に載せ、協商で両方提示。T0〜T1：Secret・運用 known_hosts・監視プローブに二行併記し、rsync と sftp バッチのフル CI を一巡。T1 以降：依存が無ければ HostKey 旧行と Secret 旧行を削除。

ウィンドウ長は最長リリース周期＋週末バッチを見込む。金曜のみフルビルドなら、週末を跨いだ二指紋が現実的だ。ControlMaster 環境では T0 当日に master 無しの探針ジョブを入れ、新握手を強制する。

CI known_hosts：パイプラインを緑のまま

# Secret SSH_KNOWN_HOSTS（同一ホスト名に旧・新の二行、T1 で旧行削除）
[build-mac.example.com]:22 ssh-ed25519 AAAA...old...
[build-mac.example.com]:22 ssh-ed25519 AAAA...new...
export RSYNC_RSH='ssh -o BatchMode=yes -o StrictHostKeyChecking=yes \
  -o UserKnownHostsFile=$HOME/.ssh/ci_known_hosts'

ホスト鍵変更は OIDC ローテと同じリリース審査表に載せる。列にはホスト名、旧新フィンガープリント、Secret PR、T1 収束日、bastion 影響を入れる。Secret マージ後は rsync --dry-run の読み取り専用探針を先に、本番アップロードは後。

Host key verification failed を転送失敗と別メトリクスにする。ローテ週に急増したら、Secret 二行未設定か Control パス残存が大半だ。ログに known_hosts 全文を出さず、別名とファイルパスだけで足りる。

判断表

読む順：本稿 → known_hosts 固定 → ControlMaster → OIDC → 整合性／原子リリース各編。「ユーザー証明は最新、ホストは TOFU のまま」になっていないか、合同レビューで問う。

まとめと SFTPMAC

ホスト鍵ローテはサーバ・人間クライアント・CI の三点同期だ。UpdateHostKeys と二重鍵ウィンドウの役割分担が明確なら、Ed25519 移行後もパイプラインは信頼でき、かつ説明可能になる。

自前 Mac では HostKey・Secret・オンコールを自社で抱える。SFTPMAC ホスト型リモート Mac なら指紋庫と変更窓をパッケージ Runbook に含め、ビルド成果物に集中できる。 料金。