通常、人々はどこでも単一の秘密鍵と公開鍵のペアを使用することをお勧めします(私たちが秘密鍵を危険にさらす可能性について話していない場合):
SSHを介したクライアント証明書認証を使用する場合、これにより脆弱性が生じるようです。提案するのはとても人気があるので、以下の「アルゴリズム」は機能しないと思います。しかし、私はそれが正確に何が悪いのか分かりません。
説明をできるだけ詳細にして、可能な限り矛盾を最小限に抑えようとしました。そのため、長さをお許しください...
これはよく知られた 中間者攻撃 に似ていますが、少し異なります。
サーバーは公開鍵を共有しています
Diffie-Hellman を使用して、2つの個別の共有秘密トンネルが生成されます。
「サーバー1-サーバー2」
クライアント認証(Server2は、彼がPC1)と通信していることを確認したい
追伸私はウィキペディアで 公開鍵暗号 と 中間者攻撃 を調べました、そして この非常に詳細な答え (私の見解プロセス全体の大部分はそれに基づいています)が、答えはわかりません。
読みやすい「ダミーのssh認証と暗号化プロセス」を見つけることができませんでした...
Server Faultについてはすでに同じ質問をしましたが、ここに再投稿するには 推奨されました です。
最後に、私はそれを得たと思います。
まず第一に-私の説明ではssh v1とssh v2プロトコルを混同しています。チャレンジ/レスポンス認証はssh v1からのものです。
Ssh v2では、クライアントは自分の秘密鍵で特定のパッケージに署名するだけで、サーバーは格納された公開鍵を使用してそれをチェックします。このパッケージはrfcで説明されています here :
To perform actual authentication, the client MAY then send a
signature generated using the private key. The client MAY send the
signature directly without first verifying whether the key is
acceptable. The signature is sent using the following packet:
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
string signature
The value of 'signature' is a signature by the corresponding private
key over the following data, in the following order:
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
したがって、署名されたパッケージには、計算された「セッション識別子」が含まれています 次のように :
H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K)
<…..>
mpint K, the shared secret
つまり、署名は共有秘密に依存し、共有秘密はP1<->S1およびS1<->S2トンネル。
通常、人々はどこでも単一の秘密公開鍵ペアを使用することを推奨します(私たちが秘密鍵を危険にさらす可能性について話していない場合)
SSH接続には2つのキーペアが含まれることに注意してください。
引用する推奨事項は、ユーザーキーに関するものです。ユーザーごとに1つの秘密キーを使用することは実行可能なモデルですが、特にお勧めしません(ホストまたはサイトごとに個別のキーペアを使用するコストはそれほど高くありません)。一方、サーバーキーは複製されません。これらは、SSHサーバーのインストール時に新たに生成されます。
このトピックについては、質問で引用した投稿の他に、次も参照してください SSHのauthorized_keysファイルとknown_hostsファイルの違いは何ですか?
あなたが説明する攻撃では、鍵の役割を混同しています。これらはホストキーssh_Host_rsa
であり、ユーザーキーではありません。これは、説明する攻撃の動作には直接関係ありませんが、混乱の一部である可能性があります。
スティッキーポイントはステップ3.3にあります。
PC1はS1_id_rsa.pubのフィンガープリント(既知)を受け入れます
2つのケースがあります。
PC1が以前にS2に接続したことがある場合、PC1(より正確にはPC1のユーザーのアカウント)はS2のホスト公開鍵をknown_hosts
ファイルに記憶しています。そのため、S1がS2のホストキーを送信した場合、PC1のSSHクライアントは、ホストキーが記録されたホストキーと一致しないことを検出し、怖いメッセージで接続を中止します。
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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.
したがって、このシナリオでは攻撃は不可能です(ユーザーがチェックを回避するために邪魔をしない限り、OpenSSHは意図的にこれを困難にします)。
PC1がS2に接続したことがない場合、PC1はS1がS2のキーであると伝えているものを何でも受け入れます。 PC1は、名前S2と暗号化IDとの関連付けについて事前の知識がなく、そのような関連付けを知っている信頼できる第三者(つまり、公開鍵インフラストラクチャ)に連絡する方法もないため、この操作を防ぐ方法はありません。中間攻撃。
問題は、サーバー1の証明書を使用しているため、クライアントがサーバー1と通信していることをクライアントが知っていることです。 server1にserver2であることを示す有効な証明書がある場合、クライアントが以前にserver2に接続したことがない場合、クライアントはそれを認識しません。ただし、ほとんどのSSHクライアントは、特定のサーバー用に接続する証明書のフィンガープリントを追跡します。クライアントが接続に行き、サーバー1に接続すると、証明書が署名されていても、指紋が変更されたという警告がユーザーに表示される可能性があります。
S2であると主張するS1への既知の接続について、s2がp1の秘密鍵を正確に知っている場合、01がs1を介してs2と通信したい場合、s2を暗号化し、s2がp1を暗号化します。 p1がs2から鍵交換を受け取らない場合、s1はs2としてp1との交換に署名できないため、問題があることがわかります。
実際、これは信頼できるリストにあるクラックされた証明書の既知の脆弱性であり、失効リストが必要な理由です。
この攻撃が機能するには、2つの穴が必要です。
S1_id_rsa.pub
を信頼できる証明書として使用し、server2のアドレスを指します(そうしないと、PC1はステップ#4.3でserver2ではなくserver1と通信していることを認識します)。#1は信頼できないネットワークで発生する可能性がありますが、#2は、server1が自身を信頼できるパーティとして挿入することを許可した以前の違反が発生した場合にのみ発生します。