カスタムSSH DHグループをクライアント専用システムに展開することで、セキュリティ上の利点はありますか？

16

SSH でのLogjam関連の攻撃に対する緩和策として、次のようなものを使用してカスタムSSH Diffie-Hellmanグループを生成することをお勧めします（以下はOpenSSHの場合）

ssh-keygen -G moduli-2048.candidates -b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.candidates

その後、システム全体のモジュライファイルを出力ファイルに置き換えますmoduli-2048。（ssh-keygen -G候補DH-GEX素数をssh-keygen -T生成し、生成された候補の安全性をテストするために使用されます。）

これは、そうでなければ事前計算に役立つ有名なグループを使用するSSHサーバーで実行する合理的なことですが、カスタムSSH DHグループをクライアントのみのシステムに展開することでセキュリティ上の利点はありますか？（つまり、SSHサーバーに接続するが、SSHサーバーとしては決して機能しないシステムです。）

私は主にLinux上のOpenSSHに関連する回答に興味がありますが、より一般的な回答も歓迎します。

ssh ssh-keys logjam

— CVn
ソース

18

本当に必要な場合はできますが、OpenSSHの2048ビットDHパラメーターを再生成する必要はありません。弱い暗号を無効にするなど、SSHを保護するために行う必要があるはるかに重要なことがあります。

私がすることは、2048ビット未満の既存のものを削除することです。

awk '$5 >= 2000' /etc/ssh/moduli > /etc/ssh/moduli.strong && \
mv /etc/ssh/moduli.strong /etc/ssh/moduli

気がつかなかった場合のために、OpenSSHには、最大8192ビットまでの多数の事前生成モジュラスが付属しています。確かに今日の1024ビットプライムについては心配していますが、2048ビットプライムは近い将来に安全であると考えられています。そして、それは最終的には変化しますが、来週になる可能性がありますが、年金受給者になってからかなり長くなる可能性があります...

また、ssh-keygenmanページにはこの奇妙なビットがあります。

このファイルには、さまざまなビット長のモジュラスが含まれていること、および接続の両端が共通のモジュラスを共有していることが重要です。

既存のモジュライを置き換えることに反対しているように見えますが、実際にそうする理由は提供されていません。

— マイケル・ハンプトン
ソース

関連：暗号化の両側で異なるモジュラスを使用するDiffie-Hellman。私の限られた理解に、それはと思われる所望の長さのない共有弾性係数が存在しない場合は、その長さのグループとのDiffie-Hellmanは一般的なケースでは可能ではなく、任意の特定のケースでは可能ではないかもしれません。したがって、2つのエンドポイント間でモジュールを共有することはDiffie-Hellmanキー交換プロトコルの数学的な要件であり、共通のモジュールを持たない2つのエンドポイント間でDiffie-Hellmanキー交換を実行しようとすると失敗します。

— CVn

2

RFC 4419 [ tools.ietf.org/html/rfc4419]は、サーバーがカスタムDHパラメーターを提供できるようにするためのものです。サーバーはその候補パラメーターをクライアントに送信し、クライアントが同意すると、両側はサーバー提供のパラメーターを使用して、セッションキーとして使用される共有秘密を生成します。そのため、サーバーとクライアントのモジュールファイルに同じエントリが含まれていなくても問題ありません。

— ブライアンミントン

2

答えは「いいえ」です。メリットはありません。:)

/etc/ssh/moduli ファイルはサーバー側でのみ使用されます。

SSHクライアント側でそのファイルについて心配する必要はありません。

SSHクライアントの実行をトレースし、そのファイルが開かないことを確認できます。

$ strace -e openat ssh user@localhost

— アディ・ロイバン
ソース