SSH接続フロー解説の修正

• Reporter: (Anonymous)
• Owner: doda
• Type: Bugs
• Status: Open [Owner assigned]
• Component: Document
• MileStone: Tera Term 4.107 & 5.0
• Priority: 5 - Medium
• Severity: 5 - Medium
• Resolution: None
• File: None

Details Reply

https://twitter.com/ttdoda/status/1192418059119558656

すべてのデータを正しく書こうとすると、結果的にRFCの図説になりそうですね（あると資料としてわかりやすくて助かりますが）。

また、フローのすべての分岐を書こうとするとパターンが結構ありそうですね。

バージョン交換
KEX方式ネゴシエーション
KEX方式で分岐
　KEX / GEX / ECDH 
KEX完了
認証開始
CheckAuthListFirst の設定により分岐（省略）
認証方式で分岐
　password / keyboard-interacive / publickey
セッションオープン
ForwardAgent の設定により分岐（省略）
/ssh-N により分岐（省略）
　シェルリクエスト
　シェルオープン

Ticket History (3/7 Histories)

2019-11-13 01:20 Updated by: None

• New Ticket "SSH接続フロー解説の修正" created

2022-08-19 12:27 Updated by: nmaya

Comment Reply

現在の図

• https://ttssh2.osdn.jp/manual/4/ja/reference/image/ssh2_sequence1.png
• https://ttssh2.osdn.jp/manual/4/ja/reference/image/ssh2_sequence2.png
• https://ttssh2.osdn.jp/manual/4/ja/reference/image/ssh2_sequence3.png
• https://ttssh2.osdn.jp/manual/4/ja/reference/image/ssh2_auth1.png
• https://ttssh2.osdn.jp/manual/4/ja/reference/image/ssh2_auth2.png

作画ツール

PlantUML というツールがあり、見やすい画像を作れるかもしれない。

2022-08-20 01:16 Updated by: nmaya

Comment Reply

KEXが途中ですが、作画してみました。出来ている部分でおかしな点があれば指摘していただけるでしょうか。

https://ttssh2.osdn.jp/snapshot/ssh-flow/

2022-08-21 17:42 Updated by: nmaya

Comment Reply

図を更新しました。https://ttssh2.osdn.jp/snapshot/ssh-flow/

• KEX の部分を作りました。
  • 「相手方に何を渡すか」だけでなく、それがどこから来ているのか（この時点でどうして知っているのか、どう算出されるのか）がわかるように記述しています。
• Authentication の部分を1枚にまとめました。（以前の図が分割になっていたのは、Power Point で用紙の制限があったためです）
• note のうち、送信するパラメータを黄色背景に、それ以外の「処理」「知っていること」「合意の仕方」「意味」などを白背景にしました。

レビューのお願い

既存の図で問題があるところは特に確認していただけると幸いです。

(1) サーバホスト鍵の秘密鍵

RFC では "server's public host key" と書かれている K_S を、"サーバホスト鍵の秘密鍵"/"public key of server's host key" としています。

厳密には「サーバホスト鍵ペアの秘密鍵」なのでこうしましたが、RFC の表現 "server's public host key", "サーバの公開ホスト鍵" でも通じるものでしょうか。

(2) サーバホスト鍵の秘密鍵

"private key of server's host key" としてあります。

signature の生成にサーバホスト鍵の秘密鍵を使うので、秘密鍵であることを記述したいです。

ここにも、K_S の結論と同じ形になる表現を用います。

(3) KEX の最後の署名の検証

「復号」と書いていたが、「検証」という語を使うように変更（r10670）

署名の検証には RSA_public_decrypt() 関数が使われている（OpenSSH でもそう @ ssh-rsa.c openssh_RSA_verify() ）のだが、RFC 4253, 4419,5656 には「verifies the signature s on H」とあるため。

H から s(signature) を生成するのが sign で、それに対応するのが verify であるなら、s から H(サーバ側) を復元する部分が verify(検証) である（cf. https://www.jipdec.or.jp/project/research/why-e-signature/PKI-crypto-mechanism.html#col3 ）。だが、H(サーバから送られてきたsを復元したもの) と H(クライアント側で生成したハッシュ) を比較することで署名が正しいかどうか判定できる。「verifies the signature s on H」は復元と比較までを含むものとみなし「検証」という言葉を選択した。s から H(サーバ側) を生成する verify(検証) については触れないこととした。

(4) publickey 認証のときの公開鍵の検証

「公開鍵を用いて署名が正しいか検証」に修正（r10670）

RFC 4252 に「check whether the signature is correct」とあり、公開鍵を使うことを明示するためこのようにしました。

(5) これ以降の通信はshared secretで暗号化される

shared secretそのものが使われるのではなく、ネゴシエーションで決定した暗号化方式での暗号の初期化に使われる、というイメージでしょうか？ 暗号化方式ごとにshared secretがどのように使われるかまでは書ききれないと思うので、 「これ以降の通信は暗号化される」に変更しました。

(Edited, 2023-04-08 23:28 Updated by: nmaya)

2023-01-11 20:50 Updated by: nmaya

• Milestone Update from (None) to Tera Term 4.107 & 5.0

2023-01-12 00:19 Updated by: nmaya

Comment Reply

r10477 で 4-stable にコミットしました。

チェックをお願いしたいです。

2023-04-08 23:28 Updated by: nmaya

Comment Reply

r10670 をコミットし、チェック依頼項目を修正しました。