CH-J Server ManagerSSH によるサーバー管理
メニュー
すべてのガイドと記事 →

SSHホスト鍵が変更された:警告の意味と対処方法

サーバーが新しいホスト鍵を提示する理由を調べ、別の経路で確認してから、保存済みの登録内容を安全に置き換えます。

警告が示すこと

サーバーはホスト鍵を使って自らの身元を証明します。クライアントが以前保存した鍵と異なる場合、OpenSSHはREMOTE HOST IDENTIFICATION HAS CHANGEDと表示して接続を拒否します。クライアントには無害な変更と攻撃を区別できないため、確認が済むまでは警告を未解決として扱ってください。

よくある原因

一般的な原因は、サーバーの再インストール、イメージからの仮想マシンの復元や複製、アドレスの別のマシンへの割り当て、異なるノードへ接続を振り分けるロードバランサーなどです。接続を傍受して介入する攻撃者も同じ警告を引き起こします。変更に心当たりがなければ操作を中止し、パスワードを入力しないでください。

フィンガープリントを比較する

プロバイダーのコンソールやハイパーバイザーのコンソールなど、このSSH接続に依存しない経路を使い、サーバー上で実際のフィンガープリントを確認します。ssh-keyscanコマンドが示すのはネットワーク経由で提示された値だけなので、それ自体では何も証明できません。コンソールから取得した値と比較するためにのみ役立ちます。

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

ssh-keyscan -t ed25519 server.example | ssh-keygen -lf -

古い登録内容を置き換える

フィンガープリントが一致したことを確認してから、古い登録内容を削除して再接続します。標準以外のポートには、角括弧を使って記述する専用の登録項目があります。ssh-keygenは以前のファイルをknown_hosts.oldとして残します。StrictHostKeyCheckingを無効にしたり、known_hostsファイル全体を削除したりしないでください。すべてのサーバーに対する保護が失われます。

ssh-keygen -R server.example
ssh-keygen -R '[server.example]:2222'
ssh user@server.example

再インストール後の警告を防ぐ

サーバーの再構築を予定していて、その身元を維持したい場合は、/etc/ssh内のホスト鍵を安全にバックアップし、同じ所有者と権限で復元します。複製では逆の対応が必要です。同じイメージから作成した各マシンには、それぞれ固有のホスト鍵が必要で、そうしないと複数のサーバーが同じ身元を共有します。

CH-J Server Managerのホスト鍵

アプリはホスト鍵のSHA-256フィンガープリントを、OpenSSHのknown_hostsファイルとは別に、独自の暗号化保管庫に保存します。変更があると接続をブロックし、既知のフィンガープリントと新しいフィンガープリントを表示します。登録内容はユーザーが確認した場合にのみ置き換えられ、キャンセルしても何も変わりません。Alpha 0.1.1では各踏み台ホストも確認対象となり、鍵が変わると実行中の転送は停止します。アプリは新しいフィンガープリントを代わりに検証できないため、別の経路での確認は引き続きユーザーの作業です。

詳しいドキュメント

OpenSSH: ssh →

OpenSSH: ssh-keygen →

生体認証によるロック解除とセキュリティ →