SSH2 拡張ネゴシエーション
とりあえず、送られてきたときに無視する（エラーになったり落ちない）ことを確認する？
doda Ticket: #36109 に関連してこちらも優先度を上げる。
doda doda doda doda TTXOpenTCP() のここでのみ、設定から client proposal を作成している。
// 設定を myproposal に反映するのは、接続直前のここだけ。 SSH2_update_kex_myproposal(pvar); SSH2_update_host_key_myproposal(pvar); SSH2_update_cipher_myproposal(pvar); SSH2_update_hmac_myproposal(pvar); SSH2_update_compression_myproposal(pvar);
REKEY のときは ext-info-c を送らないためには、以下のどちらかの方法をとればよい？
doda 新たに現在の設定から文字列を構築する（最初の設定とは変わる可能性があるが、それはよいのか？）
プロトコル的には問題ありません。
9. Key Re-Exchange ～略～ It is permissible to change some or all of the algorithms during the re-exchange.
設定は変えたけれど動作には反映して欲しくないという状況は考えづらいので、あとはSSH設定ダイアログの「いずれの変更も次回のセッション以降有効になります」との整合性ですね。
これが、
の3種類になります。
能動的なRekeyを実装したら、コントロールメニューに「鍵の再交換を行う」というような項目を作れば 現在のセッションに即座に反映できるようになるので、現在の設定を元にする方が便利なように思います。
設定は変えたけれど動作には反映して欲しくないという状況は考えづらい
「いずれの変更も次回のセッション以降有効になります」との整合性
SSH設定ダイアログには KEX 以外の設定もあります。たとえば agent forwarding は接続時にしか有効にできません。
ですので現状の「このダイアログの設定は次回のセッション以降有効」は気軽に変えられないように思います。
別件として、Rekey 中に送られてきたパケットの処理を破棄せず保留にしたとして、Rekey で設定が変わった場合、再開後のパケット処理はKEX完了前の設定値で処理するのが正しい？
ここも考えていくと難しそうなので、できるだけ変わらないよう「すでに作成された文字列の最後から ",ext-info-c" を削除する」動作としました。
doda nmaya への返信
SSH設定ダイアログには KEX 以外の設定もあります。たとえば agent forwarding は接続時にしか有効にできません。
プロトコル的にAgent Forwardingは新規セッション時にしか有効にできませんが、
辺りはプロトコル的にも即座に変更可能ですし、変更出来た方が使いやすいと思います。
なので、3種類に分かれるというのはそのようにしたいという要望ですね。 これに関しては別チケット(issue)にする方がよさそうです。
nmaya への返信
別件として、Rekey 中に送られてきたパケットの処理を破棄せず保留にしたとして、Rekey で設定が変わった場合、再開後のパケット処理はKEX完了前の設定値で処理するのが正しい？
Rekey中に破棄しているのは送信データのみです。このデータはまだSSH通信に乗る前の物なので、Rekey完了後に新しい設定で送信するのが正しいです。
Rekey(KEX)中に相手からKEX関連、およびTransport Generic以外のパケットが送られて来る事はありません。(禁止されている) もしRekey中に関係ないパケットが送られてきた場合は切断するべきですし、現状でもそうなっています。
RFC 4253 7.1. Algorithm Negotiation
Tera Term Once a party has sent a SSH_MSG_KEXINIT message for key exchange or
re-exchange, until it has sent a SSH_MSG_NEWKEYS message (Section
7.3), it MUST NOT send any messages other than:
o Transport layer generic messages (1 to 19) (but
SSH_MSG_SERVICE_REQUEST and SSH_MSG_SERVICE_ACCEPT MUST NOT be
sent);
o Algorithm negotiation messages (20 to 29) (but further
SSH_MSG_KEXINIT messages MUST NOT be sent);
o Specific key exchange method messages (30 to 49).
これに関しては別チケット(issue)にする方がよさそうです。
Rekey中に破棄しているのは送信データのみです。このデータはまだSSH通信に乗る前の物なので、Rekey完了後に新しい設定で送信するのが正しいです。
了解です。
Extension Negotiation in the Secure Shell (SSH) Protocol (RFC8308) へ対応する。
対応範囲
RFC8308 では以下の拡張ネゴシエーションが定義されている
server-sig-algs
公開鍵認証で rsa-sha2-256/512 (#36109) を利用するのに必要な為、最優先で対応する。
delay-compression
任意のタイミングで圧縮を有効に出来るが、
の二つの理由から非対応とする。
no-flow-control
フロー制御の無効化。以下の理由から非対応。
elevation
権限の昇格。おもにWindows Serverを想定していると思われる。
以下の理由から非対応。
Rekey時のext-info-cの無効化
参考
関連