known_hostsのエラー対処方法を理解してSSH接続トラブルを解決しよう

SSHを利用していると、ある日突然接続できなくなることがあります。

その際によく表示されるのがknown_hosts関連のエラーメッセージです。

特にサーバ再構築後やクラウド環境、VirtualBoxによる検証環境では頻繁に発生します。

SSHの仕組みを理解していないと原因が分かりにくいエラーですが、実際にはSSHの重要なセキュリティ機能が正常に動作している結果です。

本記事ではknown_hosts関連の代表的なエラーと対処方法について解説します。

known_hostsとは何か

known_hostsはSSHクライアントが接続先サーバのホスト鍵を保存するファイルです。

通常は以下に保存されます。

~/.ssh/known_hosts

SSHはこのファイルを利用して接続先サーバの正当性を確認します。

なぜknown_hostsが必要なのか

SSHは通信の暗号化だけではなく、接続先サーバが本物であることも確認しています。

この仕組みによって中間者攻撃（MITM）を防止しています。

known_hostsはそのための重要な仕組みです。

初回接続時の動作

初めて接続するサーバでは以下のようなメッセージが表示されます。

The authenticity of host
can't be established.

Are you sure you want to continue connecting?

yesを入力するとホスト鍵がknown_hostsへ登録されます。

代表的なエラー

最もよく見かけるエラーです。

WARNING: REMOTE HOST IDENTIFICATION
HAS CHANGED!

SSH管理者なら一度は見たことがあるでしょう。

Host key verification failed

次のようなエラーもあります。

Host key verification failed.

ホスト鍵の検証に失敗しています。

Offending keyエラー

典型的な表示です。

Offending RSA key in
/home/user/.ssh/known_hosts:15

15行目に問題があることを示しています。

原因1 サーバ再構築

最も多い原因です。

OS再インストールを行うと新しいホスト鍵が生成されます。

クライアント側には古い情報が残るためエラーになります。

原因2 VirtualBox環境

研修環境や検証環境で頻発します。

同じIPアドレスで新しい仮想マシンを作成すると発生します。

原因3 クラウドインスタンス再作成

AWSやAzureでもよくあります。

同じIPアドレスやDNS名を再利用すると発生します。

原因4 DNS切り替え

ホスト名が別サーバを指すようになった場合です。

本番環境の切り替え時によく発生します。

原因5 実際の攻撃

可能性は低いですが重要です。

ホスト鍵変更が想定外の場合は、中間者攻撃の可能性も考慮する必要があります。

まず原因確認を行いましょう。

現在の登録情報を確認する

known_hostsの内容を表示します。

$ cat ~/.ssh/known_hosts

保存済みホスト鍵を確認できます。

対象ホストを検索する

$ ssh-keygen -F server.example.com

特定ホストの情報だけを表示できます。

推奨される削除方法

最も安全な方法です。

$ ssh-keygen -R server.example.com

対象ホストのみ削除します。

IPアドレスの場合

$ ssh-keygen -R 192.168.60.101

IPアドレス指定も可能です。

削除後の再接続

再度接続します。

$ ssh user@server.example.com

新しいホスト鍵の登録確認が表示されます。

手動で削除する方法

直接編集することも可能です。

$ vi ~/.ssh/known_hosts

該当行のみ削除します。

ただし誤削除のリスクがあります。

行番号が表示される場合

例えば以下です。

Offending RSA key in
~/.ssh/known_hosts:12

12行目を削除すれば解決できます。

sedを使った削除

行番号が分かる場合です。

$ sed -i '12d' ~/.ssh/known_hosts

12行目を削除します。

ホスト鍵を確認する方法

サーバ側で確認できます。

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

フィンガープリントが表示されます。

フィンガープリント比較

サーバ管理者から通知された値と比較します。

一致すれば正当なサーバと判断できます。

本番環境では重要な作業です。

StrictHostKeyCheckingとの関係

SSHには以下の設定があります。

StrictHostKeyChecking yes

ホスト鍵検証を強制します。

StrictHostKeyChecking=no

以下のような指定です。

ssh -o StrictHostKeyChecking=no

検証をスキップできます。

検証環境では便利ですが、本番環境では推奨されません。

known_hostsを無効化する方法

UserKnownHostsFile=/dev/null

登録を行わなくなります。

ただしセキュリティ上は好ましくありません。

企業環境での運用

企業ではホスト鍵変更時に以下を実施することがあります。

• 事前通知
• フィンガープリント共有
• 変更手順書作成

安全な運用のためです。

よくある質問

known_hostsを全部削除してもよいか

接続は可能になります。

しかし全サーバの信頼情報が失われます。

必要最小限の削除を推奨します。

エラーが出たら即削除してよいか

本番環境では慎重に対応すべきです。

まずホスト鍵変更理由を確認しましょう。

実務でよく発生するケース

• VirtualBox再構築
• AWS EC2再作成
• Azure VM再作成
• OS再インストール
• DNS切り替え

原因を把握しておくと迅速に対応できます。

安全な対処手順

1. ホスト鍵変更理由を確認
2. フィンガープリント確認
3. ssh-keygen -Rで削除
4. 再接続
5. 新ホスト鍵を登録

実務ではこの手順が推奨されます。

まとめ

known_hosts関連のエラーはSSHのセキュリティ機能が正常に動作している証拠です。

多くの場合はサーバ再構築やクラウド環境の再作成が原因ですが、本当に正当な変更か確認することが重要です。

特に本番環境では安易にknown_hostsを削除するのではなく、フィンガープリントを確認しながら慎重に対応しましょう。

known_hostsの仕組みを理解することで、SSH運用の安全性をさらに高めることができます。

関連記事:

SSHのホスト鍵とは？サーバ認証の仕組みと役割をわかりやすく解説 Host key verification failed の原因｜SSH接続時に発生するホスト鍵エラーの対処法 known_hostsの役割とは？SSH接続先を検証する仕組みと管理方法 StrictHostKeyCheckingとは？SSH接続時のホスト鍵検証の仕組みを解説