web-dev-qa-db-ja.com

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

SSHへの Logjam 関連の攻撃に対して推奨される緩和策の1つは、次のようなものを使用してカスタムSSH Diffie-Hellmanグループを生成することです（以下はOpenSSH用です）

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

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

これは、他の方法では事前計算に適した既知のグループを使用するSSHサーバーで実行するのにかなり合理的ですが、カスタムSSH DHグループをにデプロイすることにはセキュリティ上の利点があります。クライアントのみのシステム？（つまり、SSHサーバーに接続するが、それ自体はSSHサーバーとして機能しないシステム）

私は主にLinux上のOpenSSHに関する回答に関心がありますが、より一般的な回答もいただければ幸いです。

sshssh-keyslogjam
16
a CVn

本当に望めばできますが、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-keygenのマニュアルページにも、この興味深いビットがあります。

このファイルにビット長の範囲の係数が含まれていること、および接続の両端が共通の係数を共有していることが重要です。

これは、既存の係数を置き換えることに反対するようですが、実際にそうする理由はありません。

18
Michael Hampton

答えは次のとおりです。いいえ。メリットはありません。 :)

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

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

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

$ strace -e openat ssh user@localhost
2
Adi Roiban