アカウント名:
パスワード:
「コミットメント」→「コメント」
「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ファイルに保管されているサー
鍵更新のサポート機能がなかったってのも意外だけど、多くの環境では /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-keyscan -t dsa,ed25519 host.name
とするだけで dsa と ed25519 の鍵取って来れるので、移行期間さえ設ければ、意外とどうにでも出来そう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
記事の修正と補足 (スコア: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ファイルに保管されているサー
Re:記事の修正と補足 (スコア:0)
鍵更新のサポート機能がなかったってのも意外だけど、
多くの環境では /etc/ssh/sshd_config が 644 になってるので、
ホストへ入ったときに
とでもしとけば、設定してある鍵をごっそり取って来れるし
DSA から Ed25519 への upgrade であれば
(リモートからの ssh-keyscan で成りすましが検出可能かどうかは分からないけど)
ホストに入らなくても
とするだけで dsa と ed25519 の鍵取って来れるので、
移行期間さえ設ければ、意外とどうにでも出来そう。