2026：ProxyMac Mac mini を香港・日本・韓国・シンガポール・米国間で移す（または改名する）ときの SSH known_hosts・ホスト鍵・信頼のリセット
Apple Silicon M4 のミニを 香港・日本・韓国・シンガポール・米国 で借りている運用者は、いずれ DNS の書き換え、インスタンスの再構築、都市間の移行に直面し、OpenSSH は悪名高い REMOTE HOST IDENTIFICATION HAS CHANGED を返す。これは「Apple が SSH を壊した」のではなく、古いフィンガープリントが ~/.ssh/known_hosts に残っているのに新しいサーバー公開鍵を提示されたため、クライアントが握手を拒否している状態だ。本稿では (1) 日常運用で移行が MITM より頻繁に信頼を壊す理由、(2) 良性ローテーションとレッドチーム想定を分けるシグナル表、(3) ホスト名対 IP 対リゾルバ現実を揃える三列マトリクス、(4) 盲目的な StrictHostKeyChecking=no に代わる八段階ランブック、(5) 秘密管理が戻ったあとに UpdateHostKeys と任意の SSH 証明書を重ねる方法を述べる。ホスト名がネットワーク変更と同時に動く場合は DNS リゾルバ障害、リージョン間レイテンシ、踏み台経路 と併読してほしい。
リージョンやホスト名の移行直後に known_hosts が騒ぐ理由
OpenSSH は、コマンドラインに入力した文字列をキーに信頼を保存する。昨日 mini-hk-01.provider.example で接続し、今日は財務の都合で同じシリアルを指す mini-sg-07.provider.example に切り替えても、ノート PC は古い名前の下に古い公開鍵を覚えている。一方プロバイダは OS 再インストール後に ed25519 のホスト鍵を正当にローテーションしていることがある。信頼を IP にだけ釘付けにすると、IPv4 とプールが災害復旧で変わるたびに痛みが増幅する。
- 定量的現実：サポートでは DNS の TTL が落ち着いたあと、「移行後に SSH が壊れた」チケットのおよそ 30–45% が古いフィンガープリントのみが原因だと報告される——ACL や遅延ではない。
- ツール連鎖の現実：CI では
UserKnownHostsFile=/dev/nullが焼き込まれ、開発者のローカルは逆のデフォルトを継承し、ステージングは成功してノートは失敗する。 - 人間の現実：括弧付き IP バリアントを消さずに
ssh-keygen -R [hostname]だけ叩くと、ProxyJump の構成が DNS 名を行き来するときに再び驚く。
シグナル表：正当なローテーションと悪意ある傍受
| シグナル | 良性ローテーションらしい | 潔白が証明されるまで侵害として扱う |
|---|---|---|
| プロバイダの変更ログ／メンテナンス枠が公開されている | はい——パッチ火曜日スタイルの再構築後の鍵ローテーション | 文書がないのに鍵が毎時間反転する |
| フィンガープリントが署名付き通知と一致 | 署名チェーンを検証したうえで受け入れ可能 | 帯域外の確認が存在しない |
| 自分のノートだけが文句を言い、VPN 上の同僚は同じ鍵を見る | 古いローカルキャッシュ | リージョンごとに split-brain DNS が異なる A を返す |
無関係な二つのネットワークからの ssh-keyscan が一致 | 信頼度は高い | 結果が分岐——選択的傍受の可能性 |
検証マトリクス：ホスト名・数値 IP・リゾルバ出力は一致しなければならない
信頼データを消す前に三つの事実をスナップショットする：シェルが使う正確な Host スタンザ、macOS では dscacheutil -q host -a name、Linux では dig +short で得た宛先 IPv4/IPv6、そして 踏み台ガイド のとおり Hostname を書き換えるかどうか。いずれかの列が食い違うと、誤った known_hosts 行を消して午後を幽霊追いに費やす。
デュアルスタックで Happy Eyeballs が混乱するときは、一つのアドレス族だけで鍵を採信する前に AAAA / Happy Eyeballs のガイドに沿って整える。
企業プロキシは HTTPS 管理ポータルに TLS を終端しつつ SSH には触れないことがある——「ダッシュボードが開ける」と「その PDF のフィンガープリントが OpenSSH の表示と一致する」は同義ではない。ベンダ PDF か署名 JSON をエクスポートしローカルで SHA256 を計算する。クリップボードの丸め誤りは内部監査でおおよそ 200 件に 1 件の誤承認につながるという。
八段階ランブック：規律ある信頼回復
- 自動化を凍結：鍵が揺れているあいだに SSH を乱打ちする CI を一時停止し、レート制限と騒がしいアラートを避ける。
- 権威あるフィンガープリントを集める：コンソールから JSON や PEM 裏付けをダウンロードする。Slack の見知らぬ DM は信じない。
- 古い行を削除：使ったことのある別名すべてに対し
ssh-keygen -R hostnameとssh-keygen -R ipを実行する。 - 意図的にプローブ：一度
ssh -o VisualHostKey=yesで接続し、ランダムアートをスクリーンショットと比較する。 - 慎重に再シード：信頼できるネットワークでのみ
ssh-keyscan -t ed25519 hostnameをknown_hostsへパイプする——空港の Wi‑Fi は避ける。 - Jump 設定を更新：
ProxyJumpチェーンがミニが期待する論理ホスト名と同じになるようにする。 - チームに通知：新しいフィンガープリントを社内ステータスチャンネルにタイムスタンプとチケットリンク付きで投稿する。
- ログを監視：48 時間、ゲートウェイログで想定外の IP 帯からの SSH を grep する——想定外の国は SOC レビューへ。
known_hosts を一括削除しない——他のパイプラインは無関係ベンダ向けの保存信頼に依存している。
~/.ssh/config に頼る：UpdateHostKeys・証明書・将来対策
現行の OpenSSH は UpdateHostKeys yes をサポートし、信頼できるサーバーがローテーションする鍵を週次の手編集なしで公開できる。HostKeyAlgorithms では ssh-ed25519 を先に並べる。大企業では SSH ユーザ証明書を配ることもある——その場合は CA 公開鍵を中央保管し、ノートごとにホスト鍵を釘付けしない。
GUI クライアント（Royal TSX、Termius）と CLI を混在させるチームは、MDM の金庫から同じ known_hosts 断片をエクスポートし、信頼できないホテルネットワークでフィンガープリントの写真撮影に頼らないようにする。
HSM を配備したり SSHFP を DNS に載せたりする組織は、DNSSEC 検証がすでに強制されている場合にのみ VerifyHostKeyDNS yes を評価する——そうでなければ手動ピンと四半期ローテ、チケット ID 添付に留まる。
大規模フリートは設定管理リポジトリで known_hosts 断片をミラーする——ファイアウォールルール変更と同じ扱いで、必須レビュアー、必須ロールバックハッシュ、本番マージ前のステージング SSH 統合テストを課す。
FAQ
VNC は SSH ホスト鍵を再利用するか？いいえ——画面共有は別の信頼プロンプトを持つ。それでも DNS 名を突き合わせ、人間が誤ったモーダルにパスワードを貼らないようにする。
JP から KR へ移すと必ず鍵が変わるか？下層の VM やベアメタルが変わる場合に限る——鍵はインスタンスに従い、マーケのリージョンバッジではない。
セキュリティは毎回のローテーションを承認すべきか？規制スタックではそうすべきだ——監査のため変更記録にフィンガープリントを添付する。
フィンガープリントが現実と一致したあとも ProxyMac Mac mini が合う理由
信頼ストアが再び現実と揃ったあとも、借りた Mac mini M4 は macOS の挙動を開発者のノートと一致させ、香港・日本・韓国・シンガポール・米国 で鍵が計画メンテのあいだにローテーションするときの驚き面を縮める。Apple Silicon の予測可能なユーザ空間は、机上のマシンと同様に ssh-keygen と画面共有が振る舞う。料金ページ でリージョンを比較し、ヘルプセンター でリモート手順を演習し、PEM を GUI で検証したいときは VNC の手順 を参照してほしい。
