Host key verification failed（SSH）

一言でいうと（このエラーが何を意味するか）

Host key verification failed. は、接続先サーバーが提示したホスト鍵（サーバーの公開鍵）が、あなたのマシンに保存済みの記録と食い違ったため、SSHクライアントが接続を打ち切ったことを示します。エラーではなく防御が正しく作動した状態です。

SSHはパスワードやユーザー鍵で「あなたが誰か」を認証する前に、まず「相手が本当に以前と同じサーバーか」を確認します。この照合に使うのがクライアント側の ~/.ssh/known_hosts（システム全体では /etc/ssh/ssh_known_hosts）で、初回接続時に受け入れた鍵を記録しておき、次回以降そのフィンガープリントと突き合わせます。今回はそれが一致しませんでした。

典型的な警告は次のように出ます。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
...
Offending ECDSA key in /home/user/.ssh/known_hosts:12
Host key verification failed.

末尾の known_hosts:12 は「12行目の記録と衝突した」という意味で、後述の削除で使う重要情報です。

横にスクロール

よくある原因（複数を具体的に、頻度順）

• サーバーの再構築・OS再インストールで鍵が変わった（最頻）: OSを入れ直すと /etc/ssh/ssh_host_* が再生成され、ホスト鍵が別物になります。クラウドVMの作り直し、コンテナやAMIからの新規起動、sshd の鍵再生成でも同様。IPやホスト名は同じでも中身が別のサーバーなら必ず起きます。
• known_hosts が古い／使い回しの衝突: DHCPやクラウドでIPが再割り当てされ、以前は別ホストだったIPに繋いでいる。あるいはロードバランサやDNSラウンドロビンの背後で、接続のたびに実体の異なるサーバーへ振られている場合も、記録した1つの鍵と一致しません。
• 接続先の取り違え・ポート違い: ssh の宛先ホスト名やIPを打ち間違えた、SSHポートフォワード（踏み台のローカルポート転送）越しで別サーバーに繋がっている、といった構成ミス。
• 中間者攻撃（MITM）の可能性: 頻度は低いものの、けっしてゼロではありません。攻撃者が経路上で偽のサーバーになりすまし、あなたの認証情報や通信を盗もうとしている場合にも同一の警告が出ます。SSHはこの区別ができないため「変わった」とだけ伝えます。心当たりのない環境や公共ネットワークでは、まずこれを疑うのが安全側の判断です。

診断の手順（切り分け方・見るべきログ/コマンド）

鍵が「変わった」こと自体は警告文で確定しています。診断の主眼はその変化が正当か、攻撃かの判定です。手順を飛ばして削除するのが最も危険です。

まず、相手が提示している鍵のフィンガープリントを取得します。-o StrictHostKeyChecking を触らずに、鍵情報だけ見るには次を使います。

# 接続先が今提示しているホスト鍵のフィンガープリントを表示
ssh-keyscan -t ed25519,rsa,ecdsa example.com 2>/dev/null | ssh-keygen -lf -

次に、known_hosts に記録されている旧フィンガープリントを確認します。

# 手元の known_hosts に保存済みのフィンガープリントを表示
ssh-keygen -lf ~/.ssh/known_hosts -F example.com

両者の SHA256:... を比較し、本当に別の鍵に変わっているかを確定させます。そのうえで、新しい鍵が正しいかを必ずSSH以外の経路（アウトオブバンド）で照合します。次のいずれかが信頼できる正解です。

解決と予防（対処と再発防止）

新しい鍵が正当だと確認できたら、衝突している該当ホストの記録だけを削除します。known_hosts 全体を消すのは、他のすべてのサーバーの記録まで失い保護を弱めるので避けます。

# 該当ホストの古い記録だけをピンポイントで削除（ホスト名・IP双方）
ssh-keygen -R example.com
ssh-keygen -R 203.0.113.10

ssh-keygen -R は該当行を消し、元の known_hosts を known_hosts.old に退避します。警告文の known_hosts:12 のように行番号が分かる場合、その行を直接消しても構いません。削除後に再接続すると初回扱いとなり、新しい鍵の受け入れを聞かれます。

The authenticity of host 'example.com' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

ここで先ほど別経路で確認したフィンガープリントと目視照合し、一致した場合のみ yes と答えます。これが再登録です。予防策は次のとおりです。

• ssh-keygen -R で局所削除: 全消しやファイル手編集の癖をやめ、ホスト単位の削除を習慣化する。
• 正規フィンガープリントの配布: 組織なら known_hosts を構成管理で配布するか、SSH証明書（CA署名のホスト証明書）を使い、CAを一度信頼すれば個々の鍵登録を不要にする。DNSSEC下の SSHFP レコードで公開する方法もある。
• 再構築時に鍵を保全する: 意図的な作り直しでは、旧サーバーの /etc/ssh/ssh_host_* を安全に引き継げば、そもそもこのエラーを起こさず運用できる。

SSHが依存する公開鍵暗号とフィンガープリント（鍵のハッシュ）の原理はセキュリティを、鍵配送やなりすましが問題になる通信経路の話はネットワークを、known_hosts の探索やファイル権限まわりはOSを参照してください。