SSH3 - HTTP/3を使う、より高速で高機能なセキュアシェル

 (github.com/francoismichel)
8 ポイント 投稿者 GN⁺ 2025-09-28 | 1件のコメント | WhatsAppで共有
  • SSH3 は HTTP/3 上で動作する次世代の セキュアシェルプロトコル であり、従来の SSHv2 と比べて セッション接続速度 を大幅に向上させる
  • QUIC と TLS 1.3 によりセキュアチャネルを形成し、OAuth 2.0、OpenID Connect などのモダンな認証基盤をサポートする
  • サーバーを秘密のパスの背後に隠せるため、ポートスキャン などの攻撃に強く、UDPポートフォワーディングや QUIC マルチパスなどの 新機能 を提供する
  • OpenSSH の複数の中核機能をすでに採用しているが、現時点では 実験的 段階のため、本番環境への展開は推奨されない
  • SSH3 という名前は適切ではないという意見が多く、標準化ドラフトでは「Remote Terminals over HTTP/3」に変更されており、名称変更が進められている

SSH3プロジェクトの概要と重要性

  • SSH3 は、既存の SSH プロトコルを HTTP/3 とモダンな Web 技術に合わせて再設計したオープンソースソリューション
    • 既存の SSH 接続プロトコル (RFC4254) の意味論を HTTP/3 Extended CONNECT と QUIC+TLS 1.3 チャネル上で再構成
  • IETF インターネットドラフト draft-michel-remote-terminal-http3 として提案されており、セッション接続速度 を大きく短縮し、モダン認証方式の拡張 など多くの利点を提供する
  • 他の SSH 実装と比べて、QUIC の利用や 隠蔽型サーバー構成 のような革新的なアイデアが特徴

主な機能と特徴

  • 高速なセッション接続
    • 従来の SSHv2 接続は平均して 5〜7 回のネットワーク往復が必要なのに対し、SSH3 は 3 往復 だけで済み、ユーザーが感じる待ち時間を大幅に減らす
    • キー入力遅延 (latency) は従来水準を維持する
  • 強化されたセキュリティ
    • TLS 1.3、QUIC、HTTP 認証 に基づき、すでに電子商取引やインターネットバンキングなどで使われている検証済みのセキュリティプロトコルを活用
    • RSA、EdDSA/ed25519 ベースの公開鍵方式、および OAuth 2.0、OpenID Connect など多様な認証方式をサポート
    • Google、Microsoft、Github のアカウントでもログイン可能
  • サーバーを隠す機能
    • サーバーを特定の 秘密 URL（例: https://192.0.2.0:443/M3MzkxYWMx... など）の背後に置き、その URL に認証リクエストが来た場合にのみ応答する
    • それ以外のリクエストには 404 Not Found を返すため、インターネット上の攻撃者やクローラーはサーバーの存在を把握できない
    • ただし、秘密のパスは認証の代替ではないため、必ず別の認証メカニズム（公開鍵、パスワード、OIDC など）を使うことが推奨される
  • 継続開発中の実験的プロジェクト
    • 構造的に信頼できるセキュリティ検証が必要であり、運用サーバーへの導入は推奨されない
    • 実験環境または閉域ネットワークでコミュニティのフィードバックを集めている
  • OpenSSH 互換性と追加機能
    • ~/.ssh/authorized_keys と known_hosts のパース、ssh-agent 連携、TCP/UDP ポートフォワーディング、Proxy Jump をサポート
    • UDP フォワーディング により DNS・RTP・QUIC サービス など UDP ベースのサーバーへのアクセス経路を提供し、QUIC datagram 経路を利用
    • X.509 証明書 による HTTPS レベルのサーバー認証機能
    • キーレス (Keyless) 認証: OpenID Connect により公開鍵をコピーせずに、企業 SSO や Google/GitHub などの外部アカウントだけで接続可能

結論

  • SSH3 は モダンなネットワークプロトコルと認証 を導入し、SSH 環境を進化させるオープンソースの実験的プロジェクト
  • 速度、柔軟性、セキュリティを大幅に強化するが、十分な検証が済むまでは 本番運用での利用には慎重であるべき
  • OpenSSH に近いユーザー体験を提供し、新機能も豊富である
  • 適切なセキュリティ評価とコミュニティ参加を通じて、次世代 SSH として定着する可能性を持っている

関連記事

1件のコメント

 
GN⁺ 2025-09-28
Hacker Newsのコメント
  • ssh3 という名前は本当に好きになれなかったが、リポジトリの冒頭に「SSH3 は将来的に改名予定です。現時点では SSH Connection Protocol (RFC4254) を HTTP/3 Extended Connect 上で動かす形ですが、必要な変更が多く、既存の SSH とも大きく異なるため、簡単に統合できるものではありません。仕様ドラフトはすでに ‘Remote Terminals over HTTP/3’ に改めており、より良い恒久的な名前を検討する時間が必要です」と書かれていて良かった
    • こういう名前は、誰かが「Windows 12」や「Linux 7」というリポジトリを作ったような、場違いな感じがする
    • SSH3 の代わりに Secure Hypertext Interactive TTY みたいな名前はどうかという提案
    • SSH/3 はどうだろうと思った (SSH + HTTP/3 という感じ)
    • このスレッドはまさに本格的な “bike-shedding” 論争の名作だ
    • SSH2/3 くらいならどうかと思った。大半は SSH2 だが、HTTP/3 上に載る構造だ
  • SSH は遅いが、自分の経験では最大のボトルネックはセッションセットアップにある。PAM のせいか、OpenBSD の方針のせいか、SSH 接続を再利用する場合でも新規作成する場合でも、毎回セッションセットアップ段階が深刻に遅い。長時間セッションなら問題ないが、単にコマンドを一つ実行するだけでも毎回オーバーヘッドがあるので、Ansible の性能にも満足できず、結局セッションオーバーヘッドなしでリモートコマンドを実行するミニ Ansible を自作することになった
  • 「これ、本当に従来の SSH より速いのか？」と疑っていたが、README を見ると接続確立段階だけが速く、その後の実効速度は同じだと書いてあり、納得した。それだけでも十分に妥当な改善だ
    • 実際には、その意味では速くない。単一の SSH 接続で複数ポートのトラフィックをフォワードするとヘッドオブラインブロッキングが発生するが、QUIC/HTTP3 プロトコルならこの問題を解決できる
    • 賭けてもいいが、このプロトコルは高レイテンシの回線では SSH よりずっと速いと思う。UDP ベースなので ack を待たずに大量データを連続送信でき、世界各地との大きな scp 転送ではかなりの速度向上が期待できる
    • VPN 上では本当に速いかもしれない。"TCP の中にさらに TCP" という罠がないからだ
    • HTTP/3、QUIC 全体の主な利点は従来よりラウンドトリップが減ることにあり、それが接続確立の高速化につながるという点で筋が通っている
  • 「SSHv2 ではセッション初期化に 5〜7 回程度のラウンドトリップが必要だが、SSH3 では 3 回で済む。実際のセッション中の入力遅延（キー入力から応答まで）は同じ」という説明だった。ユーザーとしては接続速度が大きな問題になったことはあまりなく、魅力を感じにくい。SSH には実戦で検証され尽くした安定性もあり、こういう新しいツールはたとえ実運用レベルでも信頼するにはリスクが大きい
    • UDP トンネルが中核機能だ。WireGuard よりかなり軽量で、OpenID 認証のようなものもある
    • 「接続速度」はいつも少し気になっていた。リモートでコマンドを即実行したいときに遅いのが特に惜しかった
    • ssh3 ではヘッドオブラインブロッキングが解消されている可能性が高い。1 本の物理接続で複数ポートや複数接続を多重化するなら、より速くなるはずだ
    • 滑らかなユーザー体験が必要なら Mosh を勧める
  • すべてのアプリケーションレイヤープロトコルが HTTP に吸収されていくのが、なぜこんなに悲しく感じるのか分からない
    • 本当にそういう流れなら悲しいと思う。HTTP の典型的なモデルは多くの場合で制約が強すぎるうえ複雑すぎて、いろいろな場面に合わない。だが HTTP/2 や QUIC（HTTP/3 のトランスポート）はあまりに汎用的で、HTTP という名前自体の意味が薄れているように見える。少なくとも QUIC は TCP の代替としてかなり明確に位置付けられている
    • 実際、こうしてすべてのプロトコルが標準化されると、トラフィックシェーピングや検閲などがやりにくくなるので、前向きに捉えている。結局、トラフィックが HTTP かランダムなバイトストリームであれば（つまり目立たなければ）、ネットワークの監視や遮断は難しい。新しいプロトコルを作るなら、通信事業者が何か特別に有利にしてくれない限り、HTTP に偽装するのが遅くならずに通す方法だ
    • こういう現象は、企業のセキュリティチームが何でもかんでも遮断したり妨害したりしたがる慣行のせいでもある。Zscaler や TLS ミドルマンモードを使うチーム、まさに君たちのことだ
    • こうした遮断は空港の Wi‑Fi や世界中のホテルでも起きている。たとえば Apple Mail でメール送信ができないのも、企業方針で 25 番ポートを塞ぐからだ。スパム対策と言いながら 143、587、993 なども全部塞ぎ、結局 80 と 443 しか通さない。IPv6 で少しは良くなってほしいし、EU の ChatControl 推進のような動きも止まってほしい。本当に IT を分かっている人の話を聞いてほしい
    • connection init、つまりネットワーク接続初期化の複雑さが高まり、結局は battle-tested なプロトコルにもとづくベストプラクティスに乗る必要がある、というのも理解できる。だが実際の転送内容がもはや hypertext ではないのに、ずっと http と呼び続けるのはやはり違和感がある
  • SSH の機能自体が進化するのは素晴らしいが、どうせほとんど作り直しに近いなら、もう少し実験的な新機能も入れてほしかった。たとえば Mosh のような「ローミングや一時的なネットワーク不安定」への対応など、便利な機能があるといい https://mosh.org/
    • Mosh の利点はキー入力への反応が非常に速く、まるでローカルシェルで直接作業しているように感じられることだ。SSH3 にこうした面の改善があるのか気になる。QUIC が多少は補ってくれるだろうが、Mosh とはまた別物だ
    • 自分の理解では connection migration や multipath 対応は QUIC の基本特性であり、ローミング機能や「内蔵 tmux」との違いについては、それがシステムに直接組み込まれていること自体に本当に価値があるのかはよく分からない
  • 短い名称や略語に執着する人たちが理解できない。本当に良くない。今はコマンドが長くても構わないのだから、できる限り技術的に明確な長い名前を使うべきだと思う。フルネームを基本にして、略称は一部のシステム管理者やディストリビューションが短くして使えばいい。人にはフルネームを教えるべきだ。たとえば Set-Location は cd より望ましいし、remote-terminals-over-http3 のような名前のほうが ssh3 より良い
  • 最後のコミットが 1 年前だが、最近の進捗を知っている人はいる？
  • プロジェクト計画が気になる。リリースも GitHub 活動も 1 年以上音沙汰がない。論文から始まったタイプなので、関連研究や別の付随作業を続けている可能性はあると思う
    • この点を指摘してくれてありがとう。個人的にはこのプロジェクトはもう終わったと見ている。239 コミット程度で、実質的には Proof of Concept レベルにすぎず、まだ本気で使えるものではない。一方で OpenBSD 側（OpenSSH）は依然として非常に活発なので、当面置き換わる余地はなさそうだ https://github.com/openbsd/src/commits/master/
  • プロジェクトのアイデア自体は悪くない。一般的な H3 プロキシでプロキシできるなら、特に期待できる。そこに multipath / migration や TCP 関連のブロッキング問題まで解決できるなら、すでに大きな前進だ