SSH 通信は、公開鍵暗号化を使用して保護されます。ユーザーが SSH クライアントを使用して SSH サーバーに初めて接続すると、SSH プログラムは SSH サーバーの公開鍵をユーザーのホーム ディレクトリ内のファイル known_hosts 内の ~/.ssh/ という名前の隠しフォルダーに保存します。次のスクリーンショットに示すように:
その後、ssh-client がサーバーに接続するたびに、サーバーから送信された公開鍵を ~/.ssh/known_hosts ファイルに格納されているサーバーの公開鍵と比較します。公開鍵が一致しない場合、クライアントはネットワーク トラフィックがハイジャックされているか、接続先のサーバーが異なると見なし、SSH クライアントは次のように接続を切断します。
$ ssh [email protected] @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 3f:1b:f4:bd:c5:aa:c1:1f:bf:4e:2e:cf:53:fa:d8:59. Please contact your system administrator. Add correct host key in /home/admin/.ssh/known_hosts to get rid of this message. Offending key in /home/admin/.ssh/known_hosts:3 RSA host key for 192.168.12.12 has changed and you have requested strict checking. Host key verification failed.$
リモート ホスト キーが変更された理由は複数考えられます。中間者攻撃は考えられる理由の 1 つにすぎません。他に考えられる理由は次のとおりです:
- OpenSSH がリモート ホストに再インストールされましたが、何らかの理由で元のホスト キーが復元されませんでした。
- リモート ホストが別のマシンに正当に置き換えられました。
また、正当な理由でサーバーが再フォーマットされたか、サーバー キーが置き換えられた可能性もあります。このような状況では、ユーザーは古いキーを削除して ~/.ssh/known_hosts ファイルを更新し、サーバーへのログインを有効にする必要があります。
これが無害であると確信している場合は、以下の 2 つの方法のいずれかを使用して、openSSH をだましてログインさせることができます。ただし、中間者攻撃に対して脆弱になっていることに注意してください。
方法 1 – ~/.ssh/known_hosts ファイルからホスト キーを削除する
最初の方法は、~/.ssh/known_hosts ファイルからリモート ホストを削除することです。警告メッセージには、対象のリモート ホストに対応する known_hosts ファイル内の行番号がすでに示されていることに注意してください。上記の例で問題のある行は 3 行目です (「/home/admin/.ssh/known_hosts:3 の問題のあるキー」)
次のワンライナーを使用して、その 1 行 (3 行目) をファイルから削除できます。
$ sed -i 3d ~/.ssh/known_hosts
上記の方法では、ssh を実行してログインするときに、ホスト キーのフィンガープリントを確認するよう求められることに注意してください。
方法 2 – StrictHostKeyChecking を無効にする
2 番目の方法では、2 つの openSSH パラメータを使用します:
- StrictHostKeyChecking
- UserKnownHostsFile
このメソッドは、空の known_hosts ファイルを使用するように構成することで SSH を騙し、リモート ホスト ID キーの確認を求めないようにします。
$ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected] Warning: Permanently added '192.168.12.12' (RSA) to the list of known hosts. [email protected]'s password:
UserKnownHostsFile パラメーターは、ユーザー ホスト キーの格納に使用するデータベース ファイルを指定します (デフォルトは ~/.ssh/known_hosts です)。 /dev/null ファイルは、書き込まれたすべてのものを破棄する特別なシステム デバイス ファイルであり、入力ファイルとして使用されると、すぐに End Of File を返します。
ヌル デバイス ファイルをホスト キー データベースとして構成することにより、SSH は、SSH クライアントが以前に SSH サーバーに接続したことがないため、ホスト キーの不一致が発生しないと思い込ませます。パラメータ StrictHostKeyChecking は、SSH が新しいホスト キーをホスト キー データベース ファイルに自動的に追加するかどうかを指定します。 no に設定すると、すべての初回接続で、ユーザーの確認なしでホスト キーが自動的に追加されます。 null キー データベース ファイルのため、すべての接続が SSH サーバー ホストに対して初めて表示されます。したがって、ホスト鍵は、ユーザーの確認なしでホスト鍵データベースに自動的に追加されます。キーを /dev/null ファイルに書き込むと、キーが破棄され、成功が報告されます。
コマンド ラインで上記の 2 つの SSH オプションを指定すると、その特定の SSH ログインのホスト キー チェックをバイパスできます。ホスト キーのチェックを永続的にバイパスする場合は、SSH 構成ファイルで同じオプションを指定する必要があります。すべてのユーザーに対して変更を永続的にしたい場合は、グローバル SSH 構成ファイル (/etc/ssh/ssh_config) を編集できます。
特定のユーザーをターゲットにする場合は、ユーザー固有の SSH 構成ファイル (~/.ssh/config) を変更します。以下の手順は両方のファイルに適用されます。特定のサブネット (192.168.0.0/24) のキー チェックをバイパスするとします。
次の行を SSH 構成ファイルの先頭に追加します。
Host 192.168.0.* StrictHostKeyChecking no UserKnownHostsFile=/dev/null
構成ファイルには、Host * のような行があり、その後に 1 つ以上のパラメーターと値のペアが続く必要があることに注意してください。ホスト *任意のホストに一致することを意味します。基本的に、Host * に続くパラメータは一般的なデフォルトです。各 SSH パラメータの最初に一致した値が使用されるため、ホスト固有またはサブネット固有のパラメータをファイルの先頭に追加する必要があります。
最後に注意事項として、何をしているのかわからない場合は、SSH 構成ファイルに一括で永続的な変更を加えるよりも、ケースバイケースでキー チェックをバイパスすることをお勧めします。