この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
SE時代に初めてこの状況に遭遇したとき、私は本当に頭が真っ白になりました。
ターミナルに「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」と表示され、さらに「POSSIBLE BREAK-IN ATTEMPT!」という物騒な言葉が続いた瞬間、「まずい、本番サーバーが攻撃されたかもしれない」と青ざめた記憶があります。結局それはサーバーのOSを再インストールした後に起きる正常な現象だったのですが、そのことを理解するまでに1時間以上かかりました。
この記事では、Linuxのsshコマンドで突然この警告が出てサーバーに繋がらなくなった体験から、known_hostsの仕組みと正しい対処法を、20年以上Linuxサーバーを運用してきた経験からお伝えします。同じ状況に遭遇して焦っている方が、この記事を読んで10分以内に解決できるよう書きました。
この記事のポイント
・警告が出ても即座に慌てず、まずホスト鍵変更の心当たりを確認する
・正規の変更なら ssh-keygen -R でold鍵を削除するだけで解決する
・「POSSIBLE BREAK-IN ATTEMPT!」は攻撃の証拠ではなくnの「鍵が変わっています」という通知
・中間者攻撃との見分け方は「サーバー側に最近変更があったか」を軸に判断する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
SE時代、「POSSIBLE BREAK-IN ATTEMPT!」で頭が真っ白になった話
私がこの警告メッセージに初めて遭遇したのは、SE時代の2003年ごろのことです。当時、担当サービスで使っていたLinuxサーバーをOSから再インストールする作業がありました。作業自体は無事に終わり、新しいOSが起動しているのを確認して、いつも通りSSHで繋ごうとしました。そのとき、ターミナルに以下のメッセージが表示されたのです。
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX. Please contact your system administrator. Add correct host key in /home/user/.ssh/known_hosts to get rid of this message. Offending RSA key in /home/user/.ssh/known_hosts:5 RSA host key for 192.168.1.100 has changed and you have requested strict checking. Host key verification failed.
その後、先輩に状況を説明したところ、「ああ、それはOS再インストールしたからだよ。known_hostsを消せば繋がる」と一言で解決されました。たった1行のコマンドで解決する問題を、私は1時間以上パニックで過ごしていたのです。「その場でちゃんと理解しておけばよかった」と後悔した出来事です。
セミナーで3,100名以上を指導してきた中で、この「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」を見て焦った経験のある受講生は本当に多いです。特にLinuxを学び始めた頃は、英語の警告メッセージを読んで意味が把握できず、ただ恐怖を感じる方が少なくありません。
「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」が出る仕組み
この警告を理解するには、まず「known_hosts」というファイルの役割を知る必要があります。SSHでサーバーに接続するとき、クライアント（あなたのPC）はサーバー側が持つ「ホスト鍵（host key）」を受け取ります。このホスト鍵は、「このIPアドレスのサーバーはこの鍵を持っているはず」という情報としてクライアント側の `~/.ssh/known_hosts` ファイルに保存されます。
2回目以降に同じサーバーに接続するとき、SSHクライアントは「前回記録したホスト鍵」と「今回サーバーが提示したホスト鍵」を比較します。ここで2つが一致すれば正常接続、一致しなければ「鍵が変わっている。誰かが偽サーバーに誘導しようとしているかもしれない」と判断して警告を出すのです。
ホスト鍵が変わる原因は、大きく分けて2つあります。
・正規の原因：サーバーのOSを再インストールした、OSをアップグレードした、仮想マシンを作り直した、IPアドレスを別のサーバーに付け替えた
・危険な原因：中間者攻撃（man-in-the-middle attack）によって、別のサーバーやプロキシが同じIPアドレスを騙っている
この2つのどちらの可能性もあるため、SSHは「危険かもしれない」という趣旨の警告を出すようになっています。「POSSIBLE BREAK-IN ATTEMPT!」は「不正侵入の試みです」という断定ではなく、「その可能性を含むのでご確認ください」という意味なのです。
「IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!」も同様で、「悪いことが起きている可能性がある」という表現であり、実際に攻撃が起きているとは限りません。初見では恐ろしい印象を受けますが、メッセージをよく読むと「それとも鍵が変わっただけかも（It is also possible that a host key has just been changed.）」ともちゃんと書かれています。
エラーが出た時のトラブルシュート・対処手順
警告が出たときにまずやることは「焦らず状況確認」です。以下の手順で判断してください。1. 心当たりを確認する（最重要）
「このサーバーについて、最近何かあったか」を確認します。・サーバーのOSを再インストールしたか
・仮想マシンを作り直したか
・同じIPアドレスを別のサーバーに割り当てたか
・クラウドインスタンスを削除して作り直したか
・SSH設定でホスト鍵を再生成したか（`ssh-keygen -A` 等）
これらに心当たりがあれば、警告の原因はほぼ正規の変更です。安心してknown_hostsから古い鍵を削除してください。
2. 古いホスト鍵を削除して再接続する
心当たりのある正規の変更が原因なら、以下のコマンドで古いホスト鍵を削除します。# 特定のIPアドレスに対応するホスト鍵を削除する # ssh-keygen -R IPアドレス または ホスト名 $ ssh-keygen -R 192.168.1.100 # ホスト名でも削除できる $ ssh-keygen -R server01.example.com # 実行後の出力例 # /home/user/.ssh/known_hosts updated. # Original contents retained as /home/user/.ssh/known_hosts.old # 削除後に再接続すると新しいホスト鍵を確認するメッセージが出る $ ssh user@192.168.1.100 # The authenticity of host '192.168.1.100 (192.168.1.100)' can't be established. # ED25519 key fingerprint is SHA256:YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY. # This key is not known by any other names. # Are you sure you want to continue connecting (yes/no/[fingerprint])?
エラーメッセージに「Offending RSA key in /home/user/.ssh/known_hosts:5」という行番号が表示されている場合、known_hostsファイルの5行目に古い鍵があるということです。`ssh-keygen -R` を使えば行番号を気にせず削除できるので、直接ファイルを編集するよりも安全です。
3. 中間者攻撃が疑われる場合の確認手順
以下のような状況が重なる場合は、中間者攻撃の可能性も視野に入れて調査します。・サーバーの変更に全く心当たりがない
・不審なタイミングで警告が出た（例：社外のWi-Fiに接続中、VPN切断中）
・過去にそのサーバーで不正アクセスの痕跡があった
このような場合は、サーバーに直接コンソールアクセスして（VMなら仮想コンソール、VPSなら管理画面から）、サーバー側のホスト鍵のフィンガープリントを確認します。
# サーバーに直接ログインして実行（SSH経由ではなくコンソールから） # サーバー側のホスト鍵のフィンガープリントを確認する $ ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub 256 SHA256:YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY root@server01 (ED25519) # RSA鍵も確認する場合 $ ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub 3072 SHA256:ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ root@server01 (RSA) # 接続元PCで警告に表示されたフィンガープリントと目視で比較する # 一致していれば正規のサーバー # 一致していなければ中間者攻撃の可能性あり → サーバー管理者・セキュリティ担当に即報告
known_hostsを正しく管理するための実践的なコマンド
known_hostsファイルは手動で編集もできますが、`ssh-keygen -R` コマンドで管理することを強く勧めます。直接編集すると行番号のズレや書式ミスでSSH全体の接続に影響することがあるためです。私が現場でよく使うknown_hosts関連のコマンドをまとめておきます。
# ホスト鍵の削除（IPアドレス指定） $ ssh-keygen -R 192.168.1.100 # ホスト鍵の削除（ホスト名指定） $ ssh-keygen -R server01.example.com # 非標準ポート（22以外）の場合 $ ssh-keygen -R [192.168.1.100]:2222 # known_hostsの内容を確認する（読みやすい形式で） $ ssh-keygen -l -f ~/.ssh/known_hosts # 特定ホストのエントリだけ確認する $ grep 192.168.1.100 ~/.ssh/known_hosts # known_hostsファイルのバックアップを取ってから削除 $ cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak $ ssh-keygen -R 192.168.1.100 # 接続先のホスト鍵を事前に取得しておく（初回接続前に使う） $ ssh-keyscan 192.168.1.100 # ssh-keyscanの結果をknown_hostsに追加する（安全な環境でのみ） $ ssh-keyscan 192.168.1.100 >> ~/.ssh/known_hosts
StrictHostKeyCheckingオプションについて
「警告を出さずに自動で繋がるようにしたい」という理由で、sshの設定に `StrictHostKeyChecking no` を書いてしまう方がいます。これはホスト鍵の検証を無効化する設定で、中間者攻撃に対して完全に無防備になるため、本番環境では絶対に使わないでください。自動化スクリプトなどでどうしても対話確認なしに接続したい場合は、`ssh-keyscan` で事前にknown_hostsを用意しておく方法を使うのが正しいアプローチです。
現場エンジニアが覚えておくべきknown_hosts管理の鉄則
20年以上サーバーを運用してきた経験から言うと、この「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」に関するトラブルはほぼパターンが決まっています。パターン1：サーバーのOS再インストール後
最多のケースです。OSを入れ直すとホスト鍵が新しく生成されるため、必ず警告が出ます。作業手順書に「再インストール後は接続元PCのknown_hostsを更新する」と明記しておくことで、現場の混乱を防げます。
パターン2：クラウドインスタンスの再作成
AWSのEC2、GCPのCompute Engineなどでインスタンスを削除して作り直した場合も同じです。同じIPアドレスを引き継いでも、ホスト鍵は新しく生成されます。クラウドを使い始めた方が最初に遭遇しやすいパターンです。
パターン3：VPSのIPアドレス付け替え
旧サーバーのIPアドレスを新サーバーに割り当てたケース。古いknown_hostsには旧サーバーの鍵が残っているため、警告が出ます。
パターン4：ローカル検証環境の頻繁な作り直し
Vagrantや仮想マシンで検証環境をよく作り直す場合は、`vagrant ssh-config` と組み合わせた鍵管理や、`HashKnownHosts no` と `StrictHostKeyChecking accept-new`（初回のみ自動登録）を検証環境専用に設定するテクニックもあります。ただし本番環境には適用しないことが前提です。
私のセミナーでは、受講生にサーバーをゼロから構築する演習を行いますが、必ず「演習後にknown_hostsを削除してから翌日の演習を始める」という手順を入れています。そうしないと翌日の演習でこの警告が出て、受講生が困ってしまうからです。この警告を一度ちゃんと理解すれば、以後は「ああ、鍵が変わったんだな」と冷静に対処できるようになります。
SSH公開鍵認証の仕組み（authorized_keys・known_hostsの役割）については、ssh-keygenコマンドでSSH公開鍵認証を設定する方法も合わせて読むと理解が深まります。また、接続元PCを変えてもknown_hostsの問題が起きないようにするSSH設定の詳細は、SSHのポート番号を変更する方法｜sshd_configの設定からfirewalld・SELinux対応までも参考にしてください。
まとめ
「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」は、SSHクライアントが「以前記録したホスト鍵と今提示されたホスト鍵が違う」ことを検知したときに出る警告です。英語のインパクトが強く焦りますが、ほとんどの場合はサーバーの再構築や作り直しによる正規の鍵変更が原因です。| 確認事項 | 対処法 |
|---|---|
| OS再インストール・VM再作成・IP付け替えの心当たりがある | ssh-keygen -R IPアドレス で古い鍵を削除して再接続 |
| 非標準ポートを使っている | ssh-keygen -R [IPアドレス]:ポート番号 で削除 |
| 変更の心当たりが全くない・不審なタイミング | コンソールアクセスでサーバー側のフィンガープリントと比較して確認 |
| フィンガープリントが一致しない | 接続を中止し、セキュリティインシデントとして調査・報告 |
| 自動化スクリプトで確認をスキップしたい（検証環境のみ） | ssh-keyscan で事前にknown_hostsを構築しておく |
| StrictHostKeyChecking no を設定してしまっている | 削除して accept-new（初回のみ自動登録）に変更する |
「POSSIBLE BREAK-IN ATTEMPT!」という言葉は怖く見えますが、「可能性がある」という意味であり、攻撃の断定ではありません。この記事で紹介した手順で状況を確認し、心当たりがあれば迷わず `ssh-keygen -R` で古い鍵を削除してください。私自身がSE時代に1時間パニックで過ごした経験から、同じ時間を無駄にしてほしくないと思います。
SSHだけでなく、サーバー全体の設定を「型」として身につけませんか？
ホスト鍵の仕組みも、公開鍵認証も、実際に手を動かして構築することで初めて本当に理解できます。「なんとなく繋がっている」ではなく、何が起きているかを把握した上で操作できるエンジニアになることが現場での信頼につながります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：LinuxのSSH接続が切れて長時間処理が消えた日の話｜SE時代のtmux未知期と現役講師が語るセッション管理の鉄則
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます