Ticket #36111

SSH2 拡張ネゴシエーション

Open Date: 2016-03-06 20:26 Last Update: 2023-10-03 08:42

Reporter:
(del#1144)
Owner:
Status:
Open [Owner assigned]
Component:
MileStone:
(None)
Priority:
5 - Medium
Severity:
9 - Highest
Resolution:
Accepted
File:
None
Vote
Score: 0
No votes
0.0% (0/0)
0.0% (0/0)

Details

Extension Negotiation in the Secure Shell (SSH) Protocol (RFC8308) へ対応する。

対応範囲

RFC8308 では以下の拡張ネゴシエーションが定義されている

  • server-sig-algs
  • delay-compression
  • no-flow-control
  • elevation

server-sig-algs

公開鍵認証で rsa-sha2-256/512 (#36109) を利用するのに必要な為、最優先で対応する。

  • 対応済み

delay-compression

任意のタイミングで圧縮を有効に出来るが、

  • ttssh では後から圧縮を有効にする手段を提供していない
  • OpenSSH が未対応

の二つの理由から非対応とする。

no-flow-control

フロー制御の無効化。以下の理由から非対応。

  • 有用なケースが不明
  • OpenSSH が未対応

elevation

権限の昇格。おもにWindows Serverを想定していると思われる。

以下の理由から非対応。

  • OpenSSH が未対応

Rekey時のext-info-cの無効化

  • trunk
    • r10949, r10955「すでに作成された文字列の最後から ",ext-info-c" を削除する」
  • 4-stable

参考

関連

  • #36109 rsa-sha2-256, rsa-sha2-512公開鍵アルゴリズムのサポート
  • #40391 SSH_MSG_NEWKEYSの次のパケットが復号出来ない

Ticket History (3/16 Histories)

2016-03-06 20:26 Updated by: (del#1144)
  • New Ticket "SSH2 拡張ネゴシエーション" created
2016-03-06 20:27 Updated by: (del#1144)
  • Component Update from (None) to TTSSH
Comment

とりあえず、送られてきたときに無視する(エラーになったり落ちない)ことを確認する?

2020-02-06 18:37 Updated by: doda
  • Milestone Update from (None) to Tera Term 4.106 (closed)
  • Resolution Update from None to Accepted
  • Owner Update from (None) to doda
  • Details Updated
  • Priority Update from 5 - Medium to 7
  • Severity Update from 5 - Medium to 7
Comment

Ticket: #36109 に関連してこちらも優先度を上げる。

2020-02-06 18:40 Updated by: doda
  • Severity Update from 7 to 9 - Highest
  • Details Updated
  • Priority Update from 7 to 9 - Highest
2020-02-10 16:21 Updated by: doda
  • Details Updated
2020-05-08 10:08 Updated by: doda
  • Details Updated
2021-02-16 22:05 Updated by: nmaya
  • Details Updated
2021-05-20 08:14 Updated by: nmaya
2022-09-15 18:51 Updated by: doda
  • Details Updated
Comment

仮対応

残件

  • Rekey時にext-info-cを使わないようにする
2023-01-09 23:00 Updated by: nmaya
  • Milestone Update from Tera Term 4.107 to (None)
  • Priority Update from 9 - Highest to 5 - Medium
2023-09-21 22:59 Updated by: nmaya
Comment

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 を送らないためには、以下のどちらかの方法をとればよい?

  • すでに作成された文字列の最後から ",ext-info-c" を削除する
  • 新たに現在の設定から文字列を構築する(最初の設定とは変わる可能性があるが、それはよいのか?)
2023-09-29 18:22 Updated by: doda
Comment

新たに現在の設定から文字列を構築する(最初の設定とは変わる可能性があるが、それはよいのか?)

プロトコル的には問題ありません。

RFC 4253

9.  Key Re-Exchange
  ~略~
It is permissible to change some or all of the algorithms during the re-exchange.

設定は変えたけれど動作には反映して欲しくないという状況は考えづらいので、あとはSSH設定ダイアログの「いずれの変更も次回のセッション以降有効になります」との整合性ですね。

これが、

  • 次回セッションから有効になる
  • 次回鍵交換から有効になる
  • 即座に有効になる

の3種類になります。

能動的なRekeyを実装したら、コントロールメニューに「鍵の再交換を行う」というような項目を作れば 現在のセッションに即座に反映できるようになるので、現在の設定を元にする方が便利なように思います。

2023-10-02 22:38 Updated by: nmaya
  • Details Updated
Comment

設定は変えたけれど動作には反映して欲しくないという状況は考えづらい

「いずれの変更も次回のセッション以降有効になります」との整合性

  • pvar->session_settings ... 接続開始時の設定。TTXOpenTCP() で pvar->settings がコピーされる
  • myproposal は TTXOpenTCP() で pvar->settings から構築される
  • pvar->settings ... ダイアログからの設定はここに保存される(次回のセッション以降有効になるのはこのため)

SSH設定ダイアログには KEX 以外の設定もあります。たとえば agent forwarding は接続時にしか有効にできません。

ですので現状の「このダイアログの設定は次回のセッション以降有効」は気軽に変えられないように思います。

2023-10-02 22:47 Updated by: nmaya
Comment

別件として、Rekey 中に送られてきたパケットの処理を破棄せず保留にしたとして、Rekey で設定が変わった場合、再開後のパケット処理はKEX完了前の設定値で処理するのが正しい?

ここも考えていくと難しそうなので、できるだけ変わらないよう「すでに作成された文字列の最後から ",ext-info-c" を削除する」動作としました。

2023-10-02 23:59 Updated by: doda
Comment

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

   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).

2023-10-03 08:42 Updated by: nmaya
  • Details Updated
Comment

これに関しては別チケット(issue)にする方がよさそうです。

Rekey中に破棄しているのは送信データのみです。このデータはまだSSH通信に乗る前の物なので、Rekey完了後に新しい設定で送信するのが正しいです。

了解です。

Attachment File List

No attachments

Edit

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Login