アカウント名:
パスワード:
「コミットメント」→「コメント」
「OpenSSLの公開鍵を」→「OpenSSHの公開鍵を」
サーバー上でキーの交換を開始するためには、拡張セクションにホストキーを追加し、同時ににsshd_configの中に新旧両方のキーを指定する必要がある
サーバ管理者がするべきことは「sshd_configの中に新旧両方のキーを指定する」だけです。「拡張セクションにホストキーを追加し」はSSHの実装者が行うことです。
またアクティブキーのシームレス交換による信頼性の低下に対応するため、予備のホストキーをオフライン格納することもサポートされるようだ。
現行の（オンラインの）キーの信頼性が停止した場合（例: 秘密鍵が盗まれた）に備えて、オフラインの予備の鍵（例: 秘密鍵を金庫にしまっとく）をあらかじめsshd_configに記述しておけば、シームレスに鍵が交代できる、ということです。
んーとこういうこと？
■今まで ・クライアント：秘密鍵A ・サーバー：公開鍵A
■今後利用可能 ・クライアント：秘密鍵A、秘密鍵B ・サーバー：公開鍵A、公開鍵B
A失効時にBに即変えられるように予め2つ用意しようなのでA失効時にはCを用意しましょうみたいな？
でもそうなると
> サーバーが保持している公開鍵をクライアントに送信する機能が追加されるという
この意味が分かりませんサーバー側で公開鍵が流出しましたってケースなんですかねむしろ乗っ取られたサーバーからこの公開鍵に更新したからこの秘密鍵に換えろ(ぐへへ)ってケースが出そうな気が
> サーバーに保持させる公開鍵をクライアントから送信する機能が追加されるという
これなら意味が分かるんだけれど
# どこを理解できていないのかがわからない情弱ですんません
いえ、違います。ここで話題になっているのは接続元のクライアントの鍵ではなく、接続先のサーバ側の鍵（ホストキー）です。
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コマンドです。たぶん削除するコマンドはないので、現状ではログインしてファイルを編集する必要がありそうです。
#2755978ですおーなるほど何を認識違いしていたかわかりましたありがとうございます
鍵更新のサポート機能がなかったってのも意外だけど、多くの環境では /etc/ssh/sshd_config が 644 になってるので、ホストへ入ったときに
grep ^HostKey /etc/ssh/sshd_config | awk '{print $2".pub"}' | xargs cat | awk '{print HOSTNAME" "$0}' HOSTNAME=host.name
とでもしとけば、設定してある鍵をごっそり取って来れるしDSA から Ed25519 への upgrade であれば(リモートからの ssh-keyscan で成りすましが検出可能かどうかは分からないけど)ホストに入らなくても
ssh-ke
鍵の安全性の観点から一定期間ごとに新しいものに変えたい時に便利って話なんじゃないかなぁと思った。鍵交換の時にニセの誘導をされる所まで入り込まれてたら、どっちにせよアウトでしょう。従来の場合でもサーバが侵入済みだってことは検知できなかったわけで、退化したわけでもないと思う。
まぁ、 Ed25519なんて初めて聞いたって奴（俺だよ俺）が言うことなんでもう少し詳しい人の解説待ったほうがいいかもね。
>Ed25519なんて初めて聞いたって奴(俺だよ俺)ならばこれも読んでおくといいぞSecure Secure Shellhttps://stribika.github.io/2015/01/04/secure-secure-shell.html [github.io]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
記事の修正と補足 (スコア:5, 参考になる)
「コミットメント」→「コメント」
「OpenSSLの公開鍵を」→「OpenSSHの公開鍵を」
サーバ管理者がするべきことは「sshd_configの中に新旧両方のキーを指定する」だけです。「拡張セクションにホストキーを追加し」はSSHの実装者が行うことです。
現行の（オンラインの）キーの信頼性が停止した場合（例: 秘密鍵が盗まれた）に備えて、オフラインの予備の鍵（例: 秘密鍵を金庫にしまっとく）をあらかじめsshd_configに記述しておけば、シームレスに鍵が交代できる、ということです。
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]