警告: Remote Host Identification Has Changedの意味と修正方法

SSHはシステム間に暗号化されたトンネルを作成するセキュアなネットワークプロトコルです。グラフィカルユーザーインターフェースを必要とせずにコンピューターにリモートアクセスする必要がある開発者の間で人気があります。SSHは数十年前からあり、数え切れないほどのユーザーに確実に機能してきましたが、特定の状況でも特定のエラーの影響を受ける可能性があります。

これらのエラーの多くは SSH コミュニティで認識されており、その回避方法は広く文書化されています。これらには以下が含まれますファイアウォール非互換性, SSHの公開鍵インジェクションの問題, SSHファイルキーモードの問題および「警告：リモートホストの識別が変更されました」エラー。

このエラーは Windows、Linux、macOS を含むすべての主要なオペレーティングシステム上で発生します。問題の原因は、単なる技術的な不具合ではなく、正当なセキュリティ上の懸念である可能性があります。このアーティクルでは、これがなぜ起きるのか、SSH 接続のセキュリティにとって何を意味するのか、そして各主要プラットフォームでどのように解決するのかを説明します。

「警告：リモートホストの識別が変更されました」をトリガーする原因（心配すべきか？）

「警告：リモートホストの識別が変更されました」は、SSH 公開鍵が保存されている場所に known_hosts ファイルがサーバーが現在提示しているキーと一致しません。この不一致により、SSHの組み込みセキュリティメカニズムが起動して、潜在的な脅威から保護します。

ホストキー変更の正当な理由

サーバーのホストキーが変わる理由にはいくつかの無害な原因があります。使用されている特定のキータイプに応じて、「RSAホストキーが変更されました」のようなバリエーションが表示されることがあります。

Infographic showing server changes that modify SSH host keys, including OS upgrades, server rebuilds, backup restoration, physical to virtual migration, and SSH configuration resets.
サーバー関連の変更

サーバーオペレーティングシステムが再インストールされたか、アップグレードされました
サーバーが再構築されたか、バックアップから復元されました
サーバーのSSH設定がリセットされました
物理マシンまたは仮想マシンが置き換えられました
新しいハードウェアへのサーバー移行

ネットワーク構成の変更

クラウドプロバイダーは時間とともにIPアドレスを再利用したり、接続がロードバランサーを経由したりします。
DHCP が別のマシンに IP アドレスを再割り当てしました
廃止されたサーバーのIPアドレスが新しいシステムに割り当てられました
DNS レコードが別のサーバーを指すように更新されました

Network diagram showing a DHCP server assigning dynamic IP addresses to virtual machines, with server decommissioning and reissuing causing SSH host key conflicts.

主要な管理アクション:

システム管理者がセキュリティ上の理由でホストキーを手動で再生成しました
SSHサーバーソフトウェアが再インストールされました
セキュリティポリシーに鍵のローテーションが必要です

ユーザーパスワードの変更はホストキーに影響しないことを認識することが重要です。これらは別の認証メカニズムを表しています。ホストキーはサーバー自体またはそのSSH設定が変更されたときのみ変わります。

警告を真摯に受け止めるべき時

ホストキーの変更の多くは正当なものですが、これは本当のセキュリティ脅威を示している可能性があります。以下の場合は懸念が必要です。

サーバーに変更を加えず、スケジュール済みのメンテナンスについて知りませんでした
サーバー管理者に鍵の変更理由を確認することはできません
サーバーは公開ネットワークまたは信頼できない接続経由でアクセスされます
本番環境システムまたは機密データを含むサーバーに接続しようとしています

Split screen comparing legitimate SSH changes shown in green with security threat scenarios in red, featuring a hooded figure representing man-in-the-middle attacks.
中間者攻撃は比較的稀ですが、発生します。このような攻撃では、攻撃者があなたのコンピュータと正当なサーバーの間に位置し、すべてのトラフィックを傍受します。

人的ミスとソーシャルエンジニアリングはセキュリティ侵害の68%を占めており、警戒心が重要です。以下について学ぶことで、システムをさらに保護できます。ブルートフォース攻撃対策

IBM の最近の統計によると、グローバルな平均コストはデータ漏洩 2025年には440万ドルでしたが、検出時間は平均8ヶ月でした。これはSSHのホストキー検証メカニズムが存在する理由と、調査せずにこれらの警告を決して無視すべきではない理由を示しています。

警告が安全かどうかを確認する方法

問題の修正に進む前に、これらの検証手順を実行してください。

Flowchart showing five verification methods for confirming legitimate SSH host key changes, including team consultation, hosting provider contact, secure channels, and fingerprint comparison.

チームに確認してください。 サーバーアクセスを共有している場合は、同僚に変更を加えたかどうか確認してください
サーバーログを確認： メンテナンス記録または変更ログを確認して、最近のアクティビティを確認してください
ホスティングプロバイダーにお問い合わせください： クラウドサービスを使用している場合は、メンテナンスが発生したかどうかを確認してください
セキュアなチャネルを使用してください： 可能であれば、既知の安全なネットワークから接続してフィンガープリントを確認してください。
フィンガープリントを比較: 一部のホスティングプロバイダーは、コントロールパネルに現在のSSH指紋を表示しています

キーの変更が正当であることを確認できた場合、古いキーを安全に削除し、次回の接続時に新しいキーを受け入れることができます。

動的IPの再割り当てやホストキーの競合を避けたい場合、選択するインフラストラクチャが大きな役割を果たします。

Cloudzyが提供する SSH VPS ホスティング専用の静的IP付き。AMD Ryzen 9プロセッサ上で、コマンドを即座に実行するためのNVMeストレージとともに動作します。当社のネットワークは13リージョンにわたって40 Gbpsに達します。さらに、接続を安全に保つための無料DDoS保護も含まれます。

「Remote Host Identification Has Changed」エラーを修正する方法

修正は簡単です。古いキーレコードをシステムから削除してください。これで不一致がクリアされ、次回の接続時に新しいキーを保存できます。こちらのガイドをご確認ください。 SSHクライアントさらに多くのツールについては。

これは単一のコマンドで実行することも、ファイルを手動で編集することもできます。

方法1: コマンドライン (最速)

このメソッドはmacOS、Linux、Windows 10以上(OpenSSHを使用)で機能します。エラーを解決する最速の方法です。詳細については、以下をご覧ください。 ssh-keygenマニュアルページ.

ターミナルを開く。
このコマンドを実行してください(以下を置き換えてください hostname サーバーのIPまたはドメイン):

ssh-keygen -R hostname

This command automatically finds the old key in your known_hosts file and deletes it.  Method 2: Manual File Editing (macOS)

ビジュアルエディタを使用する場合は、キーを自分で削除できます。エラーメッセージは通常、削除する行番号を正確に示しています。

ターミナルを開いて、ファイルを編集してください Nano:

nano ~/.ssh/known_hosts

エラーメッセージから行を見つけてください。削除してから、次を押してください。 Ctrl + X と Y 保存する

macOS terminal window showing nano text editor open with known_hosts file, highlighting line to delete with numbered steps and save instructions displayed.

Windows向けの解決策

Windowsユーザーは通常、組み込みOpenSSHクライアントまたはPuTTYのいずれかを使用します。

オプション 1: Windows OpenSSH (Windows 10/11)

Windows 10と11では、OpenSSHはオプション機能です。設定 > アプリ > オプション機能から追加できます。Server 2025にはクライアントが含まれていますが、手動で有効にする必要があります。

PowerShell またはコマンドプロンプトを使用している場合、 ssh-keygen Method 1からのコマンドはここでも機能します。

代わりにファイルを手動で編集するには:

押す Windows キー + R.
タイプ %USERPROFILE%\.ssh そして押してください Enter.
開く known_hosts Notepadで開く。
エラーの原因となっている行を削除して、ファイルを保存します。

キーの適切な管理については、こちらのガイドを参照してください。 Windows で SSH キーを生成する.

オプション2: PuTTYを使用する

PuTTY はファイルではなく Windows レジストリにキーを保存します。

レジストリエディターを開く (押してください Windows キー + R、入力 regedit、をクリック Enter).
に移動: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
サーバーのホスト名または IP アドレスと一致するエントリを見つけます。
右クリックして選択削除.

Windows PowerShell command removing SSH host key with File Explorer showing updated known_hosts file, and PuTTY Registry Editor displaying delete confirmation dialog for host key.

Linux向けの解決策

現在の ssh-keygen 説明した command 方法1 Linux 上でこれが標準的な解決方法です。高速で、ネイティブにサポートされています。

手動編集

ファイルの内容を確認したい場合は、Nano などのテキストエディターで編集できます。

ターミナルを開く。
タイプ nano ~/.ssh/known_hosts そして押してください Enter.
エラーメッセージに記載されている行番号を見つけます。
ラインを削除してから、押してください Ctrl + X と Y 保存する

以下のようにも使用できます Vim (vim ~/.ssh/known_hosts詳しい場合は使用してください。)

Linux terminal showing ssh-keygen commands to remove SSH host keys by hostname and IP address, with success confirmation and known_hosts file examples.
チェック無効化に関する警告

SSH に検証なしで接続を強制することはできますが、これは危険です。中間者攻撃からの保護をバイパスします。

この方法は信頼できるネットワーク上のローカルテストのみで使用してください。macOS および Linux では、次のように入力します:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected]

Windows を使用している場合、Unix パスは機能しません。次を使用する必要があります。 NUL バイパスを機能させるには:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL [email protected]

これらのオーバーライドを、公開接続や本番サーバーで実行しないでください。

キーの不一致を修正することは日常的なメンテナンスですが、接続のセキュリティをさらに強化することもできます。ボットは多くの場合、デフォルトポート 22 をブルートフォース攻撃の対象にします。ほとんどのバックグラウンドノイズを回避するには、 Linux での SSH ポート変更より予測不可能なものへ

Diagram of a man-in-the-middle attack on SSH: attacker intercepting client-server connection, attacker key vs server key, data theft and financial loss highlighted.

本番環境またはセキュアでないネットワークでこの方法を使用しないでください。

リモートホストの識別が変更されたというメッセージを次回防ぐ方法

ホストキーの正当な変更を常に防ぐことはできませんが、中断を最小化し、セキュリティのベストプラクティスを維持することはできます。

クイックリファレンスガイド

あなたの役割	主な戦略
システム管理者	キーをバックアップし、変更を文書化し、証明書を使用し、キーを定期的にローテーションしてください
通常ユーザー	インベントリを管理し、セキュアなチャネルを通じて確認し、ログを監視してください
クラウド環境ユーザー	DNS名を使用し、プロバイダーツールを活用し、インフラストラクチャをコードとして実装します

Infographic showing SSH key management best practices: use SSH certificates, DNS names, Infrastructure as Code, back up host keys, document changes, and consider bastion hosts.

システム管理者向け

ホストキーをバックアップ: キーを保存 /etc/ssh/ OS を再インストールする前。その後復元して、ユーザーへの警告を防ぎます。

ドキュメント予定変更 キーを変更する前にユーザーに通知し、新しいフィンガープリントを安全に共有します。これにより、接続を検証できます。

SSH 認証書を使用してください: 大規模なチームは中央認証局を使用する必要があります。これはホストキーに署名し、手動検証の必要性を排除します。

キー回転を実装： ホストキーの変更をスケジュールします。予測可能な更新は、予期しない更新よりもチームが対応しやすくなります。

一般ユーザー向け

インベントリを維持する： サーバーフィンガープリントを個人で記録するか、チームのセキュアなドキュメンテーションを使用してください。

帯域外認証で確認 キーはクラウドコンソールなどの信頼できるソースで確認し、カジュアルなメッセージからは確認しないでください。

ログを監視: SSH のログを定期的にチェックして、異常な接続パターンや繰り返されるエラーがないか確認してください。

設定管理を使用する： SSH設定ファイルを使用して、セキュリティ設定を低下させることなく動的な開発環境を処理します。

ダイナミッククラウド環境向け

DNSネームを使用: IP アドレスではなくホスト名を使用して接続してください。下層のアドレスが変わるときも一貫性を保ちます。

クラウドツールを活用する： プロバイダーコンソールを使用して現在のフィンガープリントを取得します。変更を受け入れる前に、これらのツールに対してキーを検証してください。

Infrastructure as Code Terraform のようなツールを使ってキー検証を自動化してください。高度な設定の場合は、次のようにすることもできます。 SSH SOCKS5プロキシを使用する.

Bastion Hosts: セキュリティゲートウェイ 安定したキーを持つジャンプサーバーをセットアップしてください。これらは動的なインフラへの安全なエントリーポイントとして機能します。

結論

「警告：リモートホスト識別が変更されました」は SSH のセキュリティ機能であり、無視すべき欠陥ではありません。この警告はサーバーメンテナンスや設定変更など正当な理由で頻繁に出現しますが、中間者攻撃や不正アクセスからの保護に重要な役割を果たします。

この警告が表示される場合、原因を確認してから進めてください。ほとんどの場合、解決方法は簡単です。使用している OS の指示に従って古いホストキーを削除し、次の接続時に新しいキーを受け入れてください。

SSH のホストキーの仕組みとベストプラクティスを学ぶことで、リモートアクセスワークフローでセキュリティと利便性の両立を実現できます。ファイルの安全な転送についての詳細は SSH経由でのファイルコピー.

よくあるご質問

リモートホスト識別が変更されたという警告を真摯に受け止めるべきですか?

はい、真摯に受け止めてください。サーバーの身元が変わったことを意味し、中間者攻撃または単なるルーチンメンテナンスを示す可能性があります。新しいキーを受け入れる前に、必ず管理者またはプロバイダーに変更内容を確認して、セキュリティを確保してください。

警告の原因: Remote Host Identification Has Changed とは?

この警告は、サーバーの現在のフィンガープリントが known_hosts ファイルのものと一致しない場合に発生します。一般的な原因には、OS の再インストール、IP の再割り当て、SSH 設定のリセットが含まれます。まれに、アクティブな中間者攻撃による傍受を示すこともあります。

このエラーはオペレーティングシステム間で発生する可能性がありますか？

はい、この警告は Windows、macOS、Linux を含む SSH を使用するすべてのオペレーティングシステムに影響します。これは SSH プロトコルのセキュリティ検証に由来します。修正方法はプラットフォームによって異なりますが、基になるセキュリティトリガーはすべてのシステムで同じです。

ホストキーの変更が正当なものか攻撃なのか、どう見分ければよいですか?

正当性を確認するには、最近のメンテナンス、OS アップデート、IP 変更を確認してください。接続する前に、クラウドプロバイダーのコンソールやシステム管理者からの確認など、信頼できるソースに対して新しいフィンガープリントを検証する必要があります。

ホストキー検証を無効にするとSSHがより便利になりますか？

利便性は増しますが、セキュリティは削除されます。チェックを無効化すると、中間者攻撃に対する保護が失われ、接続が脆弱になります。この設定はテスト環境の隔離された環境でのみ使用し、本番サーバーや機密データを含むパブリックネットワークでは使用しないでください。

SSH ホストキーはどのくらいの頻度で変更すべきですか?

ホストキーは通常、定期的なローテーションは不要です。通常、サーバーの再構築、OS の再インストール、またはセキュリティ侵害の後にのみ変更する必要があります。頻繁な変更はユーザーに支障をきたすため、更新が必要な場合は安定性と明確なコミュニケーションを優先してください。