編集長の佐藤（@akihirosato1975）です。
先週話題になったLogjam脆弱性ですが、SSL/TLS以外にもSSHやIPSecが影響を受けることが明らかになっているのに、SSL/TLS以外での対応について意外と情報がありません。
自分が探した範囲では、OpenSSHについて日本語で情報がまとまっているところがなかったので、とりあえず概略をまとめてみました。
基本的なところについては「On OpenSSH and Logjam」を参照してますが、もし不完全な所があればコメントで連絡ください。
サーバ側
基本的には以下の2手順を踏む。
- /etc/ssh/moduli から、ビット長が2000bit以下のものをコメントアウトする。またはビット長を2048bit以上にして、同ファイルを新規に生成する。
- /etc/ssh/sshd_config で、「KexAlgorithms」ディテクティブで鍵交換の方式を制限する。
ただし「KexAlgorithms」ディテクティブ自体が、OpenSSH 5.7以降でないと使えない（RHEL/CentOS 6.x系だと、openssh-5.3p1-94以降で対応している模様）。もし古いOpenSSHのパッケージを使っている場合は、可能な限りバージョンアップを図るべき。
鍵交換の方式をどう制限するかについてはいろいろ悩ましい。
まずSHA-1系の鍵交換は、SHA-1自体の寿命がもう残り少ないので基本は非推奨。
ecdh-*系の鍵交換方式については「少ないビット長でRSAよりも高い強度を実現できる」と一般的に言われているが（ECDH/ECDSA 対応など）、一方で「問題有りなので使うべきではない」という人もおり（Secure Secure Shell）、使うかどうかは個人の判断次第になる。
「curve25519-sha256@libssh.org」はその手の問題はないが、情報元のサイトによれば、そもそもOpenSSH 6.7以降でないと実用的に動かないらしい（サポート自体はOpenSSH 6.5以降）。
以上を考慮すると、OpenSSHのバージョンを問わず確実なのは「diffie-hellman-group-exchange-sha256」の一択。これにOpenSSHが最新ならcurve25519を加えて、ecdh-*系についてはお好みで追加というところか。
クライアント側
基本はサーバ側と同様に、ssh_configの「KexAlgorithms」ディテクティブで鍵交換の方式を制限する。
ただし問題が一つあって、サーバ側が2048bit未満の鍵交換を無効にしてくれていない場合、クライアント側から「最低2048bit」を強制するためには「クライアントソフトの再コンパイル」が必要になるらしい。LinuxならまだしもWindowsではちょっと現実的ではないので、この点は今すぐの対応は難しそう。