OpenSSH、次期「OpenSSH 6.8」で「Ed25519オートコレクトキー」をサポート 16
ストーリー by hylom
うまくいくのかな 部門より
うまくいくのかな 部門より
あるAnonymous Coward 曰く、
OpenSSHの開発者であるDamien Miller氏は、次のバージョンである「OpenSSH 6.8」の新機能「hostkeys@openssh.com」についてコミットメントしている。それによると、プロトコル拡張によってサーバーが保持している公開鍵をクライアントに送信する機能が追加されるという。
この機能ではknown_hostsファイルがアップデートされるため、クライアント側のサポートが必要になる。サーバー上でキーの交換を開始するためには、拡張セクションにホストキーを追加し、同時ににsshd_configの中に新旧両方のキーを指定する必要がある（djm's personal weblog、Slashdot）。
今回のプロトコル拡張は、OpenSSLの公開鍵をDSAからEd25519へできるだけ簡単に移行することが目的である。またアクティブキーのシームレス交換による信頼性の低下に対応するため、予備のホストキーをオフライン格納することもサポートされるようだ。
記事の修正と補足 (スコア:5, 参考になる)
「コミットメント」→「コメント」
「OpenSSLの公開鍵を」→「OpenSSHの公開鍵を」
サーバ管理者がするべきことは「sshd_configの中に新旧両方のキーを指定する」だけです。「拡張セクションにホストキーを追加し」はSSHの実装者が行うことです。
現行の（オンラインの）キーの信頼性が停止した場合（例: 秘密鍵が盗まれた）に備えて、オフラインの予備の鍵（例: 秘密鍵を金庫にしまっとく）をあらかじめsshd_configに記述しておけば、シームレスに鍵が交代できる、ということです。
補足の補足: この機能は「Ed25519オートコレクトキー」ではない (スコア:1)
タイトルでは今回の機能を「Ed25519オートコレクトキー」としていますが、Damien Millerさんのブログ記事 [djm.net.au]にも、本家Slashdotの記事 [slashdot.org]にも、該当する名称は見当たりませんでした。また機能の中身からしても、ed25519への更新に限られるものではないため、不適切な名称だと思います。
「hostkeys@openssh.com拡張」ないし「ホストキーの自動更新機能」あるいは元の記事にあわせて「ホストキーのローテーション」あたりが妥当ではないでしょうか。
Re: (スコア:0)
んーとこういうこと？
■今まで
・クライアント：秘密鍵A
・サーバー：公開鍵A
■今後利用可能
・クライアント：秘密鍵A、秘密鍵B
・サーバー：公開鍵A、公開鍵B
A失効時にBに即変えられるように予め2つ用意しよう
なのでA失効時にはCを用意しましょう
みたいな？
でもそうなると
> サーバーが保持している公開鍵をクライアントに送信する機能が追加されるという
この意味が分かりません
サーバー側で公開鍵が流出しましたってケースなんですかね
むしろ乗っ取られたサーバーから
この公開鍵に更新したからこの秘密鍵に換えろ(ぐへへ)
ってケースが出そうな気が
> サーバーに保持させる公開鍵をクライアントから送信する機能が追加されるという
これなら意味が分かるんだけれど
# どこを理解できていないのかがわからない情弱ですんません
Re:記事の修正と補足 (スコア:3, 参考になる)
いえ、違います。ここで話題になっているのは接続元のクライアントの鍵ではなく、接続先のサーバ側の鍵（ホストキー）です。
SSHでは、接続先のサーバが真正であることを確かめるために、サーバの鍵ペアを使います。たとえばOpenSSHでは、接続先サーバのホストと対応するサーバ公開鍵を、接続元のクライアントの~/.ssh/known_hostsファイルに保管します。
サーバ側の鍵ペアのアルゴリズムが古すぎる場合には、サーバ側・クライアント側とも、古い鍵を失効させて新しい鍵を使う必要があります。ここで問題は、クライアント側のknown_hostsファイルに保管されているサーバ公開鍵をアップデートする方法が、SSHプロトコルあるいはOpenSSHに組み込まれていなかった、ということです。
今回のOpenSSHの変更は、(1)クライアントとサーバの間の認証が確立した後に、SSHプロトコルの拡張を用いて、サーバ公開鍵のリストをサーバからクライアントに送りつける (2)クライアントは受け取ったサーバ公開鍵のリストを使ってknown_hostsファイルを更新する、の2点です。
たとえばこんな使用方法があり得ます。現行のサーバ側の鍵が弱すぎるために、新しいアルゴリズムを使ったより強力な鍵に更新したいとします。 (a)この時サーバ側では、新しい鍵を生成してsshd_configにHostKeyの設定を追加します。 (b)クライアントは、次回ログインの際に新しい強力な鍵を含んだサーバ鍵のリストを受け取るので、known_hostsファイルを更新します。 (c)新しい鍵が充分に行き渡ったと判断したら、サーバ側の古い鍵を削除します。
この方式の問題は、(b)の接続は古い鍵を使って行われるということ、(c)で古い鍵を削除するタイミングをいつにするか決めなきゃならず、間に合わなかったクライアントが保持しているサーバ公開鍵は、従前どおり手動でアップデートする必要がある、ということです。
ちなみに。
サーバ側の~/.ssh/authorized_keysファイルで保持されているクライアントの公開鍵を追加する方法は以前からありました。ssh-copy-idコマンドです。たぶん削除するコマンドはないので、現状ではログインしてファイルを編集する必要がありそうです。
Re: (スコア:0)
#2755978です
おーなるほど
何を認識違いしていたかわかりました
ありがとうございます
Re: (スコア:0)
鍵更新のサポート機能がなかったってのも意外だけど、
多くの環境では /etc/ssh/sshd_config が 644 になってるので、
ホストへ入ったときに
とでもしとけば、設定してある鍵をごっそり取って来れるし
DSA から Ed25519 への upgrade であれば
(リモートからの ssh-keyscan で成りすましが検出可能かどうかは分からないけど)
ホストに入らなくても
Re:記事の修正と補足 (スコア:1)
鍵の安全性の観点から一定期間ごとに新しいものに変えたい時に便利って話なんじゃないかなぁと思った。
鍵交換の時にニセの誘導をされる所まで入り込まれてたら、どっちにせよアウトでしょう。
従来の場合でもサーバが侵入済みだってことは検知できなかったわけで、退化したわけでもないと思う。
まぁ、 Ed25519なんて初めて聞いたって奴（俺だよ俺）が言うことなんでもう少し詳しい人の解説待ったほうがいいかもね。
Re: (スコア:0)
>Ed25519なんて初めて聞いたって奴(俺だよ俺)
ならばこれも読んでおくといいぞ
Secure Secure Shell
https://stribika.github.io/2015/01/04/secure-secure-shell.html [github.io]
普及の道のりは遠い？ (スコア:0)
この１年、OpenSSHに限ってクライアントを調べてみたですよ。主力はやっぱりまだ5.X系、6.Xはがんばってる途中、4.Xもまだ4.6が瀬戸際で踏ん張っていて、中には3.Xや2.X使っている猛者もいるみたい。AdobeCSの中身は確かOpenSSH3.Xだったっけ？
OpenSSH_5.2 24.7%
OpenSSH_5.5 14.0%
OpenSSH_5.6 11.9%
OpenSSH_5.9 11.4%
OpenSSH_6.2 8.2%
OpenSSH_6.1 6.6%
OpenSSH_4.6 4.5%
OpenSSH_6.6 4.2%
OpenSSH_6.0 4.0%
OpenSSH_5.8 2.9%
OpenSSH_5.3 1.4%
OpenSSH_4.3 1.2%
OpenSSH_5.1 1.2%
OpenSSH_6.4 1.0%
OpenSSH_4.7 0.5%
OpenSSH_3.5 0.3%
OpenSSH_4.5 0.1%
OpenSSH_6.7 0.1%
OpenSSH_6.5 0.1%
OpenSSH_3.4 0.1%
OpenSSH_5.4 0.1%
OpenSSH_2.5 0.1%
OpenSSH_6.3 0.1%
OpenSSH_3.8 0.1%
Re: (スコア:0)
どんな用途のサーバでチェックしたのか非常に気になるところで・・・
ユーザ向けのwebサーバあたりですか？
Re: (スコア:0)
何にSSHを使っているかはひとそれぞれなんだと思うんですが、接続先がWebサーバ兼務していることは多いみたいです。
Re: (スコア:0)
5.2, 5.5, 5.6, 5.9, 6.2 の使用率が高いと言うことは、
RHELあるいはCentOSの特定バージョンに含まれるOpenSSHがこのバージョンだったということだろうか
Re: (スコア:0)
CentOS5が4.3、CentOS6が5.3、CentOS7が6.4ですね。
ECDSAの後継アルゴリズムと言われても (スコア:0)
Ed25519っていうのがECDSAの後継アルゴリズムで、ECDSAで指定の曲線が危険だというのはわかった。
でも実際はdropbearやルータ、Linux以外のOS向けsshクライアントはECDSAすらない素のssh-rsa 1024bitしか対応しなかったりするよね。
NSAの陰謀だとすればそれは予定通りなんだろうけど
Re: (スコア:0)
そもそもecdsaすら普及してないんだよなー・・・・
Cent7は最初から、Cent6もアップデートで使えるようにはなっているものの、ssh-keygenでオプションナシで作られるキーはrsaだし。
Re: (スコア:0)
サーバのホスト鍵は sshd を立ち上げたときにスクリプトか何かで勝手に作られる気がするから、サーバは対応バージョンになってれば大丈夫はなず。
クライアントが選択するホスト鍵の暗号化方式の順番がどうなってるかだけど、これはデフォルトで前のほうにあるから、暗号化方式にクライアントが対応してれば新しいアルゴリズムが勝手に使われる。
ユーザ認証用の鍵ペアのほうは、自分で意識しないと新しいアルゴリズムは使われないな。
実装する側からすると、RFC で MUST になってるものだけ対応するのが一番楽だからなー（邪悪）