USSH

USSHは、USTP-Secure上に構築されたシェルプロトコルおよびクライアント/サーバーペアです。

これはTCPトンネルではなく、SSHをTCP内にラップするものでもありません。

ステータス: ベータ版

ライセンス: MIT

AEAD暗号名

• chacha20 = CHACHA20_POLY1305
• aes-256-gcm = AES_256_GCM
• aes-128-gcm = AES_128_GCM
• デフォルトのAEAD暗号: chacha20

デフォルトポート

• 5322

サーバー

python3 ussh_server.py \
  --peer-ip <CLIENT_IP_OR_DOMAIN> \
  --peer-port 0 \
  --bind-ip 0.0.0.0 \
  --bind-port 5322 \
  --cipher chacha20 \
  --congestion-control auto

--passwordを省略した場合、サーバーは起動時にUSSHログインパスワードの入力を求めます。

対話的な起動時、サーバーは自身をsystemdサービスとしてインストールするかどうかを尋ねます。通常実行するにはnと答えてください。この質問をスキップするには--no-systemd-promptを使用します。

クライアント

python3 ussh_client.py \
  --peer-ip <SERVER_IP_OR_DOMAIN> \
  --peer-port 5322 \
  --bind-ip 0.0.0.0 \
  --bind-port 0 \
  --cipher chacha20 \
  --congestion-control off \
  --cleartext off

クライアントはSSHと同様に、パスワードを対話的に要求します。

クライアントは最初に確認したサーバーのX25519公開鍵を~/.ussh_known_hosts.jsonに保存します。 その鍵が後で変更された場合、クライアントは新しい鍵を黙って信頼する代わりに、TOFU不一致エラーで中断します。 サーバーのホスト鍵を意図的にローテーションした場合は、クライアントを--regen-key付きで実行して、対話的な確認後に保存されたTOFU鍵の置き換えを許可してください。

Internet-Drafts

• USSH Internet-Draft: https://datatracker.ietf.org/doc/draft-x1co-ussh/

注記

• トランスポートはUDP上のUSTP-Secureです。
• USSHは、パケットごとのHMAC整合性を備えたオプションのクリアテキストDATAモードもサポートしています:
  • サーバー側: --cleartext auto|on|off
  • クライアント側: --cleartext on|off
  • サーバーがautoの場合、USSHはクライアントの要求に従います。
  • サーバーがonまたはoffの場合、サーバーは最終的なクリアテキストモードを強制します。
  • --cleartext onを使用すると、USSHはクリアテキストが実際のインターネット上では危険であり、ローカルネットワークなどの管理された環境でのみ推奨されるという警告を表示します。
• USSHの下層では、USTPSはACK: 10 MAC:<tag>、NACK: 42 MAC:<tag>、HELLO: ...、CLOSE:などの読み取り可能なASCII制御行と、バイナリのUPACK（UPAK）DATAフレームを使用します。
• ACKとNACKはデバッグ容易性のために平文のままですが、偽造されたACK/NACK制御攻撃を防ぐために、セッションごとのHMACタグで認証されます。
• 通常モードでは、DATAペイロードはAEAD暗号化を使用します。
• クリアテキストモードでは、DATAペイロードは暗号化されませんが、第三者による検出されない改変を防ぐためにHMACを保持します。
• USSHは、UPACK DATAペイロードあたり900バイトというUSTPSトランスポートのペイロード上限を継承します。
• USSHはUSTPSの下に2番目のフラグメンテーション層を定義しません。
• トランスポートレベルのMTU、PMTU、ノンスの動作、重複処理、および古いパケットの処理はUSTPSから継承されます。
• 自動ネットワーク/パス移行は削除されました。
• クライアントがネットワークを変更し、その送信元IP:portが変わった場合、現在のUSSHセッションは終了することが想定され、ユーザーはクリーンに再接続する必要があります。
• 移行実装は、実際の信頼性とセキュリティの問題を引き起こしたため削除されました:
  • NATやモバイルネットワークが経路を急速に変更した際の繰り返しの移行フラッド
  • 回復したように見えたが端末データの配信が停止したセッション
  • クライアントが経路の断絶に気付くまでの長い無通信期間
  • 実際のローミングクライアントと、既存セッションを主張するスプーフィングされたパケットとの間の曖昧さ
  • クリーンに再接続する代わりに端末をスタック状態のままにする可能性のある回復状態
• 現在の動作は意図的にシンプルです: 現在のIP:portでクライアントを検証し、セッションをそのエンドポイントにバインドし、エンドポイントが変更された場合は再接続します。
• USSHはトランスポートからオプションのUSTPS Congestionを継承します。
• サーバー側: --congestion-control auto|on|off
• クライアント側: --congestion-control on|off
• サーバーがautoの場合、USSHはクライアントの要求に従います。サーバーがonまたはoffの場合、サーバーは最終モードを強制します。
• USTP-Secure自体は順序付けされないままです。
• USSHはトランスポートをTCPのような順序付けされたチャネルに変換しません。
• USSHは、端末に書き込む前に論理的なstdoutバイトストリームのみを再組み立てします。
• USSHは、PTYが一貫したバイトストリーム動作を期待するシェル入出力チャンクに対して、アプリケーションレベルの順序付けも維持する場合があります。
• この再組み立てが存在するのは、対話型シェルの出力が連続したバイトストリームであり、端末バイトを生の到着順でレンダリングすると、ls、find、コンパイラログなどの大きな出力が破損する可能性があるためです。
• これは、USTP-Secureがトランスポートレベルのヘッドオブラインブロッキングを引き続き回避しつつ、USSHが端末レンダリングに必要なアプリケーションレベルの順序のみを復元することを意味します。
• ペイロードはパケットごとにAEADで暗号化されます。
• 静的PSKは使用されません。
• 各クライアントは、X25519を通じて個別の一時的なAEADセッション鍵を受け取ります。
• パスワードは、セキュアセッションが確立された後にUSSH認証に使用されます。
• サーバーは、ussh_server.pyを実行しているマシン上で実際のPTYバックアップシェルを起動します。
• クライアントはstdinバイトを送信し、stdoutバイトをレンダリングします。
• サーバーは複数のクライアントをサポートし、クライアントごとに1つのシェル/セッションを持ちます。
• サーバーで--cipherが設定されている場合、サーバーはその正確な暗号を使用します。
• --cipherが省略されるかautoに設定されている場合、サーバーはクライアントが要求した暗号を使用します。
• クライアントは予期しない暗号ネゴシエーションを拒否します。
• TOFU（初回使用時信頼）は、最初の接続後に予期しないサーバー鍵の変更を検出するためにクライアントで有効になっています。
• サーバーはデフォルトで~/.ussh_host_keyに永続的なX25519ホスト鍵を保持するため、TOFUは再接続や再起動をまたいで安定したままです。
• 通常のサーバー再起動ではホスト鍵は変更されません。
• ホスト鍵を意図的にローテーションする場合にのみ、サーバーで--regen-keyを使用してください。
• TOFUエントリは<peer-ip-or-domain>:<peer-port>ごとに保存されるため、異なるアドレス/ポートの別のサーバーは異なるホストIDとして扱われます。

トランスポートハンドシェイク

• USSHはUSTP-Secureと同じUSTPSリトライトークンハンドシェイクを継承します。
• サーバーはまず、リトライトークンとセッションメタデータでクライアントにチャレンジします。
• クライアントは、暗号化されたUSSHセッションが受け入れられる前に、そのトークンをエコーバックする必要があります。
• 同じハンドシェイクで、最終的なAEAD暗号と、USTPS Congestionがonかoffかもネゴシエーションされます。
• 同じハンドシェイクで、DATAがAEAD暗号化を使用するか、クリアテキストとHMACを使用するかもネゴシエーションされます。
• リトライトークンは、セッション作成前の到達可能性の証明にすぎません。
• これはセッション鍵でも、パケットノンスでも、後で導出されるAEADセッション鍵の代わりでもありません。