OpenSSH 完全に理解した（笑）へのツッコミ

[angel-p57]

間違いへの指摘ということではないですが、通信の手順を挙げるなら、鍵交換と同時に行われるホスト認証に触れてないのは大きいところかと思います。
流れについては https://qiita.com/angel_p_57/items/30a12a0d45457b5f76d5 をどうぞ。

[spiegel-im-spiegel]

ご指摘ありがとうございます。「ホスト認証」については後ほど追記しておきます。

See: #93

「ホスト認証」については何をやってるか分からなかったのでスルーしてたのですが（ホスト間認証かと思ってましたw） Qiita 記事の図は分かりやすかったです。ただ，あれだと「認証」の体を成してないですよね。事前に証明（certificate）されてるわけではない鍵で署名しても認証にはならないと思うのですが...

Qiita 記事で言うところの「ホスト鍵」のライフサイクル（生成・証明・配布・失効）について説明している記事が見当たらなくて，いったん理解を保留している状態です。

[angel-p57]

事前に証明（certificate）されてるわけではない鍵

そこはSSL/TLSで「証明」が話題にされることが多いから気になっているんだと思うんですけど、あくまで認証は「本人確認」( この場合「対応する鍵の持ち主かどうかの確認」 ) なので、証明というのはまた別問題です。

つまり前提の違いで、なので紹介した記事では「確認する責任はクライアントが負う」と書いているわけです。
※これは、確認を怠ると不利益を被るのがクライアントだからこういう書き方にしてるんですが、本当のことを言えば「サーバ運用者が利用者に適切に情報提供する義務を負う」という面もあるわけで、だからgithubなんかだとGitHub の SSH キーフィンガープリントというページを用意していて、これが「証明」の役割を果たしています。

SSHではPKIみたいに枠組みを決めているわけではなくて、鍵の正当性については当事者間で何らかの形で解決してくださいね、方法は任せます、と。そういう位置づけになっているわけです。

[spiegel-im-spiegel]

そうか！ 納得しました。いわゆる TOFU (Trust On First Use) 信用モデルのことですね。そういや SSH は TOFU だって，どっかで見たような...

アドホック認証は OpenPGP でもそうなので，それ自体には違和感はないですが，鍵交換のプロトコルの中で送られた公開鍵で署名検証するのは何か違うよなぁ，と思ったもので。

またひとつ理解が進みました。ありがとうございます。