2024/04/21 SSHのRFCの実装に着手したい

気がしている、だけではある

RFC内にも断片的に関連RFCを参照する記述は存在するが、網羅性がない

検索すると得られる情報

どのようなRFCが存在しているか

各RFCはどのRFCによって更新されているか

一度発表されたRFCは取り消すことができない

更新が必要になった場合は、新しくRFCを作って、古いRFCをUpdateする

IETF datatrackerは、RFCの新旧関係を「Updated by」で示してくれるので、確認すること

https://scrapbox.io/files/6624ec182ce04900266f4df2.png

古い順にソートしてみる

https://scrapbox.io/files/6624ee2e08c273002501aedb.png

RFC 4250は単にマジックナンバーの一覧

RFC 4251はSSHプロトコルを概観できる資料となっている

SSHの最も低層にある

SSH-ARCHを読んだあとは、これを読むと良さそう

4.1.

TCP/IPの22番ポートでサーバーをlistenさせよ

4.2.

まず、互いに「SSH-2.0-foobar （任意でコメント）（CRLF）」という形式の文字列を送れ

ただし、これより前に、SSH-で始まらない行を送信しても良い

この場合、RFC3649のUTF-8でエンコードすること

クライアントはこのような行を処理できるよう実装すること

それぞれのバージョン文字列はprintableなUS-ASCIIである

空白とマイナスは存在してはならない

このあと鍵交換が始まる

7.

鍵交換の概要

guessの正誤判定

guessはMAYの要件なので実装しなくも良さそう？

PuTTYで使用する各アルゴリズムだけを使えるようにしよう

7.1.

SSH_MSG_INITについて

鍵交換のために互いに送受信するべきパケットの構造を示している

アルゴリズム名のリスト（name-list）は、アルゴリズム名をカンマ区切りで結合したもの

アルゴリズム名のリストは最低一つの要素を持つ。最初の要素はguessed algorithm

kex_algorithms（鍵交換用アルゴリズム）について

guessed algorithmが合致すればそれを鍵交換に使う

そうでなければ所定の方法でアルゴリズムを選択する

条件をいずれも満たさなければ接続を切断すべし

cookieという16バイトの値はランダムにする

すべてのhost keyがすべての鍵交換方式で有効であるとは限らない

これは、鍵交換方式がhost keyに対して暗号化や署名の機能を要請することがあるため

どちらも要求しないことはないだろうが..

encryption, mac, compressionはそれぞれ目的ごとのアルゴリズム名リスト

クライアントのname listを先頭から見て、サーバのname listにも存在するアルゴリズム名があればそれを選択する

もし条件をいずれも満たさなければ両側切断

これらは「none」という値を含むことができる。

鍵交換

SSH_MSG_KEXINITのあと、SSH_MSG_NEWKEYSで鍵交換を行う

KEXINITからNEWKEYSまでの間に、特定の形式のメッセージを送ることが許可されている

NEWKEYSが送られた段階で、鍵交換が終了したとみなされる

以降のメッセージは、交換済の鍵を使って暗号化する

7.2.

鍵交換完了時点で交換されている情報について

鍵交換が完了した時点で、暗号化用の秘密鍵Kと、セッションを識別するハッシュHが生成・交換されている

Hはキーが再交換されても変化しない

なお、Hを生成するハッシュ関数（≠ハッシュ）は鍵交換方式の指定に含まれる

生成にはKが用いられる。詳細な方法はRFCで規定されているのでそれを読むこと

8.

Diffie-Hellman鍵交換についての説明

わかっていないこと

host_keyという概念は多分ホストを認証するための公開鍵

そのための