SSHエラーの修正:Host key verification failed - リモートホストの識別情報が変更されました

初級者🌐 Networking2026-04-18| Linux (Ubuntu, CentOS, Debian), macOS, Windows (WSL, Git Bash, PowerShell)

Error Message

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Host key verification failed.
#ssh#linux#システム管理#セキュリティ

TL;DR: すぐに解決したい場合

サーバーを信頼しており、識別情報が変更された理由(Ubuntuを再インストールした、クラウドインスタンスを入れ替えたなど)がわかっている場合は、ローカルマシンで次のコマンドを実行して古いエントリを削除します。

ssh-keygen -R 192.168.1.105

192.168.1.105 をサーバーのIPアドレスまたはホスト名に置き換えてください。次回接続時に、SSHが新しいフィンガープリントの承認を求めてきます。yes と入力すれば、再び接続できるようになります。

SSHが接続をブロックする理由

このエラーは、サーバーの「身分証明書」が手元の記録と一致しないために、警備員がドアをブロックしているような状態だと考えてください。リモートマシンに初めて接続するとき、SSHはその固有の公開鍵を ~/.ssh/known_hosts に保存します。これはデジタル指紋(フィンガープリント)として機能します。

それ以降の接続では、毎回ハンドシェイクが行われます。もしフィンガープリントが変更されていると、SSHはパニックを起こします。これは、中間者攻撃(MITM)によって誰かが通信を傍受している可能性があると想定するためです。警告は恐ろしく見えますが、通常は日常的な管理作業による変更が原因です。

警告が発生する主な原因

  • OSの再インストール: サーバーを初期化し、Debian や CentOS をクリーンインストールした。
  • IPアドレスの再利用: クラウドプロバイダーから割り当てられたIP(例:10.0.0.42)が、先週は別のサーバーに使われていた。
  • ハードウェアの交換: プロジェクトを新しい物理マシンに移行したが、固定IPアドレスはそのまま維持した。
  • SSHキーの更新(ローテーション): セキュリティコンプライアンスのために、システム管理者がサーバーのホスト鍵を手動で再生成した。

解決方法

方法1:ssh-keygen を使用する(推奨)

これが最も確実な方法です。known_hosts ファイル内のハッシュ化されたホスト名や複雑なフォーマットを自動的に処理します。特定のIPを検索し、それに関連する古いエントリをすべて削除します。

# サーバーのIPアドレスまたはドメイン名を使用します
ssh-keygen -R 192.168.1.105

2222などのカスタムポート経由で接続している場合は、エラーログに表示されている通りの形式で指定する必要があります。

ssh-keygen -R [192.168.1.105]:2222

方法2:手動で編集する

特定の1行だけを修正したい場合もあります。画面に表示されているエラーメッセージを確認してください。通常、問題のある行が直接示されています。例:

Offending ECDSA key in /home/user/.ssh/known_hosts:24

この場合、24行目が原因です。お好みのターミナルエディタでファイルを開きます。

nano ~/.ssh/known_hosts

24行目までスクロールしてその行を完全に削除し、保存して終了します。同じIPに対して複数のエントリがあり、そのうちの1つだけを削除したい場合に便利な方法です。

方法3:自動化のための一時的な回避策

数十台のプロビジョニング済みVMを立ち上げる自動化環境やCI/CDパイプラインでは、ホスト鍵の確認がボトルネックになることがあります。ホスト鍵のチェックを完全にスキップすることも可能ですが、信頼できないパブリックネットワークでは決して行わないでください。

ssh -o "StrictHostKeyChecking=no" root@192.168.1.105

このコマンドは、フィンガープリントに関係なく強制的に接続を続行します。使用は最小限にとどめてください。

変更の確認

古い鍵を削除した後、再度接続を試みてください。次のようなプロンプトが表示されます。

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

yes と入力します。SSHは新しい正しい鍵をローカルファイルに追加し、接続が正常に進行します。

ネットワーク管理のプロのヒント

頻繁な識別情報の変更は、不適切なIP管理に起因することが多いです。ホームラボやローカルの開発クラスターを運用している場合、DHCPが24時間ごとにIPを再割り当てし、常にSSHのトラブルを引き起こしている可能性があります。私は ToolCraftのサブネット計算機 を使用して、VM用の固定IP範囲を計画しています。サーバーを 192.168.1.200 のような固定アドレスにロックすることで、IPの競合や known_hosts の古いエントリが発生する可能性を大幅に減らすことができます。

CIDRブロックを整理しておくことで、ホスト鍵が実際に変更されたときに、それが設定ミスではなく意図的なものであると確信できるようになります。

参考文献

  • 高度な管理オプションについては、man ssh-keygen を実行してください。
  • UserKnownHostsFile の仕組みを理解するには、man ssh_config を確認してください。
  • ホスト鍵の検証を安全に自動化するための SSHFP DNSレコードについて学びましょう。

Related Error Notes