「Host key verification failed」:意味と直し方

このエラーが実際に意味すること

「Host key verification failed」(しばしばより大きな声で WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! と表示されます)は、サーバーが、クライアントが以前の接続で記憶していたものとは異なる識別鍵を提示していることを意味します。これはまさに中間者攻撃に見えるものなので、SSH は処理の続行を拒否します。とはいえ正直なところ、ほとんどの場合は攻撃ではありません ── サーバーの再インストール、IP の使い回し、または VM の復元です。正しい対応は、まず鍵がなぜ変わったのかを突き止め、そのうえで初めて古い鍵を削除することです。反射的に削除してはいけません。

ホスト鍵が変わる理由(無害 vs 疑わしい)

ステップ 1 — 新しい鍵を帯域外で検証する

コンソール/物理アクセス(またはすでに信頼できる任意のセッション)があれば、サーバー上で現在のフィンガープリントを表示します:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

それをクライアントの警告に表示されたフィンガープリントと比較します。一致すれば → 変更は本物で無害です。古いエントリの削除に進みましょう。一致せず、その変更を説明できない場合 → 立ち止まり、認証情報を入力する前に調査してください。(SSH がこのように動作する理由は ホスト鍵の TOFU 解説を参照。)

ステップ 2 — 古い鍵を削除して再接続する

デスクトップでは、known_hosts から古いエントリを削除します:

ssh-keygen -R hostname-or-ip
# then reconnect and accept the new fingerprint
ssh user@host

モバイルクライアントには編集するファイルがありません ── 記憶された鍵はアプリ内に保存されています。TermAI では、鍵が変わると両方のフィンガープリントを示す警告が表示されます。変更が正当だと確認できたら、新しい鍵を受け入れる(または接続設定で保存済みのホスト鍵をクリアする)して再接続します。新しい鍵はそのままピン留めされ、OpenSSH と同じ TOFU モデルになります。

この煩わしさを避ける

• 安定したアドレス。家庭ネットワークでの「鍵が変わった」ノイズのほとんどは、DHCP がマシンを IP 間でシャッフルすることが原因です。Tailscale を使えば各マシンが 1 つのアドレスを保持するため、同じ IP で別のマシンに接続することがなくなり、鍵は「変わらなく」なります。
• 再インストール時にホスト鍵を保持する。/etc/ssh/ssh_host_* をバックアップして再構築後に復元すれば、クライアントは何も気づきません。
• チェックを無効にしない。StrictHostKeyChecking no は、SSH が MITM に対して持つ唯一の防御を無効にします。原因を直しましょう。

FAQ

「REMOTE HOST IDENTIFICATION HAS CHANGED」は常に攻撃ですか?
いいえ ── 通常は再インストール、復元した VM、またはその IP が今は別のマシンに属していることが原因です。ただし同時に MITM もこのように見えるため、受け入れる前に新しいフィンガープリントを帯域外で検証してください。

すばやく直すには?
変更が正当だと確認したら、デスクトップでは ssh-keygen -R host、モバイルクライアントでは保存済みのホスト鍵を受け入れる/クリアして、再接続します。

スマホは既知のホスト鍵をどこに保存しますか?
SSH アプリ内です(known_hosts ファイルではありません)。TermAI は接続ごとに鍵をピン留めし、変わったときには両方のフィンガープリントを示して警告します。

クイックファクト

• 意味:サーバーの識別鍵が、クライアントがピン留めしたものと異なる
• 通常は無害:再インストール、IP の再利用、復元した VM ── ただし受け入れる前に検証する
• 検証:サーバー上で ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub を実行し、フィンガープリントを比較する
• 修正:ssh-keygen -R host(デスクトップ)/ アプリ内で新しい鍵を受け入れる(モバイル);チェックは決して無効にしない