Host key verification failed の原因｜SSH接続時に発生するホスト鍵エラーの対処法
KoAN
目次
Host key verification failed エラーの原因と対処方法を理解しよう
SSHを利用してサーバへ接続していると、突然以下のようなエラーが表示されることがあります。
Host key verification failed.SSH初心者だけでなく、実務経験のある管理者でも遭遇することがある代表的なエラーです。
このエラーは認証失敗とは異なり、SSHサーバの正当性を確認する段階で発生します。
つまり、SSHが安全性を確保するために意図的に接続を拒否している状態です。
本記事ではHost key verification failedの仕組みと原因、実務での対処方法について詳しく解説します。
Host key verification failedとは
SSHでは接続先サーバが本物であることを確認する仕組みがあります。
その際に利用されるのがホスト鍵（Host Key）です。
接続先サーバのホスト鍵が期待値と一致しない場合、SSHは接続を拒否します。
その結果表示されるのがHost key verification failedです。
ホスト鍵とは
ホスト鍵はSSHサーバ自身を識別するための鍵です。
ユーザー認証用の公開鍵とは用途が異なります。
サーバが「本物」であることを証明するために利用されます。
初回接続時の動作
初めて接続するサーバでは以下のようなメッセージが表示されます。
The authenticity of host
can't be established.
Are you sure you want to continue connecting (yes/no)?yesを入力するとホスト鍵が保存されます。
known_hostsの役割
保存されたホスト鍵は以下のファイルに記録されます。
~/.ssh/known_hostsSSHは次回以降、この情報を利用してサーバの正当性を確認します。
なぜエラーが発生するのか
保存済みのホスト鍵と実際のホスト鍵が異なる場合です。
SSHは中間者攻撃（MITM）を防ぐため接続を拒否します。
典型的なエラーメッセージ
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
WARNING: REMOTE HOST IDENTIFICATION
HAS CHANGED!
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@非常によく見かけるエラーです。
原因1 サーバ再構築
最も多い原因です。
OS再インストールを行うと新しいホスト鍵が生成されます。
クライアント側には古い鍵が残っているためエラーになります。
原因2 VMの再作成
VirtualBoxやVMware環境でも発生します。
新規作成したVMに同じIPアドレスを割り当てると発生しやすくなります。
原因3 クラウドインスタンスの再作成
AWSやAzureでもよくあります。
同じIPアドレスへ新しいVMを割り当てた場合です。
known_hostsとの不一致が発生します。
原因4 DNS設定変更
同じホスト名が別サーバを指すようになった場合です。
DNS切り替え後に発生することがあります。
原因5 IPアドレス変更
ホスト名とIPアドレスの対応が変化した場合です。
検証環境でよく見られます。
原因6 実際の攻撃
可能性は低いですが重要です。
中間者攻撃（MITM）の可能性があります。
不用意に削除せず、原因を確認することが重要です。
known_hostsを確認する
登録済みホスト鍵を確認します。
cat ~/.ssh/known_hosts$ 接続先情報が保存されています。
対象ホストを検索する
$ ssh-keygen -F server.example.com該当エントリを検索できます。
安全に削除する方法
推奨される方法です。
$ ssh-keygen -R server.example.com対象エントリのみ削除します。
IPアドレス指定の場合
$ ssh-keygen -R 192.168.1.100IPアドレスでも削除可能です。
再接続する
削除後に再接続します。
$ ssh user@server.example.com新しいホスト鍵の登録確認が表示されます。
ホスト鍵を確認する方法
サーバ側で確認します。
$ ssh-keygen -lf \
/etc/ssh/ssh_host_ed25519_key.pubフィンガープリントが表示されます。
フィンガープリントとは
ホスト鍵の要約情報です。
クライアントとサーバで比較することで正当性を確認できます。
known_hostsを手動編集する
直接編集することも可能です。
$ vi ~/.ssh/known_hostsただし誤操作のリスクがあります。
ssh-keygen -Rの利用が推奨されます。
StrictHostKeyCheckingとの関係
ホスト鍵検証の動作は以下で制御されます。
StrictHostKeyChecking yes厳格な検証を行います。
StrictHostKeyChecking=noは危険か
以下のような設定です。
ssh -o StrictHostKeyChecking=no検証をスキップできます。
便利ですがセキュリティリスクがあります。
本番環境では推奨されません。
企業環境での対応
企業ではホスト鍵変更時に以下を実施します。
- サーバ再構築通知
- フィンガープリント共有
- 運用手順書更新
安全性を確保するためです。
AWSでよくある事例
EC2インスタンス再作成後によく発生します。
Elastic IPを再利用した場合に特に多く見られます。
VirtualBoxでよくある事例
研修環境や検証環境では頻繁に発生します。
同じIPアドレスでOSを再インストールすると発生します。
実務での切り分け手順
- サーバ再構築有無を確認
- IP変更有無を確認
- DNS変更有無を確認
- フィンガープリント確認
- known_hosts削除
- 再接続
ほとんどのケースはこの手順で解決できます。
よくある誤解
known_hostsは削除しても問題ない
確かに接続はできます。
しかしホスト検証機能を失うため、安全性は低下します。
エラーが出たら即削除する
本番環境では危険です。
まず原因を確認することが重要です。
まとめ
Host key verification failedは、SSHがサーバの正当性を確認できなかった場合に発生するエラーです。
多くの場合はサーバ再構築やVM再作成によるホスト鍵変更が原因ですが、中間者攻撃対策として重要な仕組みでもあります。
エラー発生時は安易にknown_hostsを削除するのではなく、まず原因を確認し、正当な変更であることを確認してから対処することが重要です。
SSHの安全性を支える仕組みとして、ホスト鍵とknown_hostsの役割を理解しておきましょう。
