Man-in the-Middle攻撃は、キーを使用したSSH認証中にセキュリティの脅威ですか?
-
13-10-2019 - |
質問
私はネットワークのセキュリティの専門家ではないので、この質問があまり賢くない場合は許してください:)。 SSHを使用していくつかのマシンにログインを自動化しています。現在、ホストキーの警告を使用しています StrictHostKeyChecking no
.
私は、誰かがサーバーとしてなりすますことができることを素朴に理解しており、そうであれば彼にパスワードを失う危険があります。ただし、パブリック/プライベートキーベースの認証のみを使用している場合(使用 PasswordAuthentication no
)、侵入者は依然として害を引き起こす可能性がありますか?
だから基本的に、 ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no"
:
1)侵入者は私の秘密鍵を解読できますか?
2)他のセキュリティの脅威はありますか?
よろしく、
JP
解決
いいえ。少なくとも...直接ではありません。あなたはあなたの秘密鍵を決して送ることがないので、 鍵 安全です。それは、MITM攻撃を実行している人がコマンドを実行したり、取得している出力を読み取ったりできないという意味ではありません。
はい、他のリスクがあります。 MITM攻撃を実行している人が、アクセスしようとしていたマシンでコマンドを実行するために秘密鍵を使用することが可能になるよりも、データを正しいサーバーに転送する場合。
他のヒント
実際、パブリックキー認証方法はMITM攻撃を防ぎます。私が知る限り、それはデザインではなく、偶然です。本格的なMITM攻撃は不可能ですが、攻撃者はまだサーバーになりすまします。クライアントから送信されたコマンドとデータを受信し、クライアントに任意の応答を返します。したがって、結局、サーバーホストのキーチェックを無効にすることは良い考えではないかもしれません。
以下は、パブリックキー認証が使用されているときに本格的なMITM攻撃を実行できない理由です。私のブログ投稿 http://www.gremwell.com/ssh-mitm-public-key-authentication さらに詳細が含まれています。
MITM攻撃中、攻撃者はクライアントとサーバーの間に自分自身を挿入し、2つの個別のSSH接続を確立します。各接続には、独自の暗号化キーとセッションIDがあります。
Public-Keyメソッドを使用して認証するために、クライアントは秘密鍵を使用して、セッションIDを含む多数のデータに署名し、サーバーに署名を送信します。サーバーは、署名を検証し、署名が無効である場合、認証の試みを拒否することが期待されます。上で説明したように、サーバーとクライアントは、セッションIDがどのようなものであるかについてまったく異なるアイデアを持っています。これは、サーバーがMITM攻撃の下でクライアントによって生成された署名を受け入れる方法がないことを意味します。
上記のように、セッションIDは、クライアントMITMとMITM-Server接続の場合に異なることが保証されています。それらは、Diffie-Hellmanと個別に交渉された共有秘密または各接続から計算されます。これは、攻撃者が同じセッションIDを持つように2つのセッションを手配できないことを意味します。