もっと詳しく

SSH通信は、公開鍵暗号を使用して保護されています。 ユーザーがSSHクライアントを使用してSSHサーバーに初めて接続するとき、SSHプログラムはSSHサーバー公開鍵をユーザーのホームディレクトリ内のファイルknown_hosts内の〜/.ssh/という名前の隠しフォルダーに保存します。次のスクリーンショットに示すように：

これで、その後、ssh-clientがサーバーに接続するたびに、サーバーから送信された公開鍵を、〜/ .ssh/known_hostsファイルに保存されているサーバーの公開鍵と比較します。 公開鍵が一致しない場合、クライアントはネットワークトラフィックが乗っ取られているか、接続先のサーバーが同じではないと見なします。そのため、SSHクライアントは次のように接続を切断します。

$ ssh admin@192.168.12.12
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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.$

リモートホストキーが変更された理由は複数考えられます。 Man-in-the-Middle攻撃は、考えられる理由の1つにすぎません。 その他の考えられる理由は次のとおりです。

  • OpenSSHはリモートホストに再インストールされましたが、何らかの理由で元のホストキーが復元されませんでした。
  • リモートホストは合法的に別のマシンに置き換えられました。

正当な理由でサーバーが再フォーマットされたか、サーバーキーが交換された可能性もあります。 このような状況では、ユーザーはサーバーへのログインを有効にするために古いキーを削除して〜/ .ssh/known_hostsファイルを更新する必要があります。

これが無害であることが確実な場合は、以下の2つの方法のいずれかを使用して、openSSHをだましてログインさせることができます。 ただし、man-in-the-middle攻撃に対して脆弱になっていることに注意してください。

方法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

この方法では、SSHを、空のknown_hostsファイルを使用するように構成し、リモートホストIDキーの確認を求めないように構成することでだまします。

$ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no admin@192.168.12.12
Warning: Permanently added '192.168.12.12' (RSA) to the list of known hosts.
admin@192.168.12.12's password:

UserKnownHostsFileパラメーターは、ユーザーホストキーの保存に使用するデータベースファイルを指定します（デフォルトは〜/ .ssh / known_hosts）。 / dev / nullファイルは、書き込まれたすべてのものを破棄する特別なシステムデバイスファイルであり、入力ファイルとして使用されると、すぐにEndOfFileを返します。

nullデバイスファイルをホストキーデータベースとして構成することにより、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構成ファイルに全面的な永続的な変更を加えるのではなく、ケースバイケースでキーチェックをバイパスするのがおそらく最善です。

The post LinuxでSSHホストキーチェックを無効にする方法–オタク日記 appeared first on Gamingsym Japan.