web-dev-qa-db-ja.com

キーベースの認証が使用されている場合、SSHホストキーチェックを無効にしても安全ですか？

私はそのように行くいくつかのタスクがあります：

  1. 新しいEC2インスタンスをいくつか起動する（Amazon Webサービス）
  2. 彼らにタスクを実行させる
  3. それらを殺す

問題は、IPアドレスが（一見）ランダムに割り当てられており、偶然に新しいマシンが以前に使用されていたアドレスを再利用したことです。

これは明らかに次のエラーにつながり、私のスクリプトは失敗しました：

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 
Please contact your system administrator.
Add correct Host key in /home/ec2-user/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/ec2-user/.ssh/known_hosts:595
RSA Host key for 127.0.0.1 has changed and you have requested strict checking.
Host key verification failed.

パスワード認証を使用するのではなく、これらのマシンに接続するときにキーペアを使用しています。攻撃者が同じキーペアを持たないため、中間者攻撃を防ぐことができますか？

SSHホストキーチェックを無効にしても安全ですか？

sshman-in-the-middle
21
Dean

短い答え：はい、いいえ

まず最初に、物事をまっすぐにしましょう。とにかくSSHでキーベースの認証はどのように機能しますか？ SSH接続が認証フェーズに達すると、クライアントはプライベートキーを使用して一連のデータ（セッション識別子を含む）に署名し、それを確認するためにサーバーに署名を送信します。

署名検証パス->認証に成功しました。

この場合、 MiTM攻撃 はどのようになりますか？攻撃者はあなたとサーバーの間に座っています。攻撃を成功させるには、彼とのセッションを開始する必要があり、サーバーとのセッションを開始する必要があります。あなたがサーバーに送信するものは何でも、実際には彼に行き、彼はそれを変更してサーバーに送信することができ、サーバーが送信するものは何でも実際に攻撃者に送信され、攻撃者はそれを変更して送信することができます。

何か面白いことに気づきましたか？ここには2つのセッションがあります（これを覚えておいてください）。セッション識別子の生成はサーバーまたはクライアントだけでは決定されないため、各セッションには独自のセッション識別子があります。つまり、攻撃者への認証に使用する署名は、攻撃者が実サーバーへの認証に使用する必要がある署名とは異なります。

攻撃者はクライアントの秘密鍵を持っていないため、実サーバーが受け入れる署名を作成することはできません。これがこの種の完全なMiTMが不可能になる理由です

MiTM SSH

だから、ホストキー/指紋チェックを無効にするのは安全ですよね？ではない正確に。攻撃者がサーバーを認証できないため、サーバー上で悪意のあるコマンドを実行することはできません。 [〜＃〜]しかし[〜＃〜]

2つのセッションについてお話ししたのを覚えていますか？攻撃者は実サーバーとのセッションを確立することはできませんが、簡単にあなたに彼とのセッションを確立させることができます。攻撃者は、あなたが彼に与えたどんな署名も受け入れ、あなたがあなたが本当のサーバーに接続していると思い込ませます。あなたは彼にコマンド（そしておそらくいくつかのプロセス固有のパスワード）を送信し、彼はあなたを幸せにするものなら何でも喜んで返信します。

確かに、これらのコマンドは実際にはサーバーに到達していないので、サーバーに本当の危険はありません。実際にサーバー（現在は攻撃者）に何を送信するのかわからないだけです。鍵、パスワード（パスワードを変更すると、サーバーが現在のパスワードを尋ねる）、およびその他の機密情報を送信する場合があります。

ボトムラインは次のとおりです：実サーバーに送信しているものを知っている偽のサーバーに接続するリスクを受け入れることをいとわないなら、次に、ホストキー/指紋チェックを無効にします。それ以外の場合は、有効のままにします。

参考文献：

16
Adi

問題のサーバーの構成でSSHエージェント転送を有効にしている場合、安全ではありません。

SSHエージェントを使用してキーベースの認証を管理し、ssh -Aまたは、このようなものが~/.ssh/config：

Host example.com
    ForwardAgent yes

または、グローバルにForwardAgentを有効にしている場合、ホストキーのチェックをスキップまたは無視するのは安全ではありません。

受け入れられた答えは素晴らしいですが、この非常に重要な警告を省略しています。

エージェント転送が有効になっていて、エージェントがMITM対象のサーバーへのキーを持っていると想定すると、攻撃者は受け入れられた回答に記載されているとおりにエージェントに接続することを許可し、次に、ユーザーのキーを使用して実サーバーに新しい接続を確立できます。転送されたエージェント。ほとんどの（すべての？）エージェントはこれを黙って許可します。その結果、実サーバーへのMITM接続が完全に確立されます。

ある意味で、これはパスワード認証MITM攻撃に似ています。パスワード認証のシナリオでは、MITMがパスワードを盗み、それを使用してサーバーを認証するので、賢くなりません。公開キー認証シナリオ（エージェント転送あり）では、攻撃者はエージェントを利用して認証を行います。そのため、攻撃者はあなたのキーを手に入れることはできませんが、サーバーを介してあなたを認証するためにエージェントを介してあなたのキーを使用し、あなたのキーを受け入れる他のホストにあなたを偽装する可能性があります（ただし、セッションの間のみ） ）。

このシナリオと、MITM以外の場合の SSHエージェントハイジャック シナリオは、[〜＃〜] very [〜＃〜]エージェントの転送先のホストに注意してください。エージェントがロードしたキーへのアクセスで攻撃者が実行できるすべてのことを考えてください。たとえば、ワークステーションがいずれかのキーを受け入れるように構成されている場合、攻撃者はワークステーションにSSHで戻り、SSH秘密キーを取得する可能性があります。また、秘密鍵にパスフレーズがある場合、攻撃者はキーロガーをインストールして、次に復号するまで辛抱強く待機する可能性があります。

4
joelsmith