ハクソク

世界を動かす技術を、日本語で。

SSH3: HTTP/3を利用した高速で豊富なセキュアシェル

240日前原文(github.com)

概要

  • SSH3 は、SSHプロトコルをHTTP/3の上に再設計した実験的なリモートターミナル技術
  • QUIC+TLS1.3 による高速なセッション確立とHTTP認証（OAuth2.0等）をサポート
  • 隠しURL機能 やUDPポートフォワーディングなど、従来SSHv2にない新機能を提供
  • セキュリティ検証中 のため、本番運用は非推奨
  • オープンソース開発 とコミュニティ協力による標準化と安全性向上を目指す

SSH3とは：HTTP/3上の新しいSSHプロトコル

  • SSH3 は、従来のSSHプロトコル（RFC4254）を HTTP/3 Extended connect 上で動作させる実験的プロジェクト
  • 公式名称は「 Remote Terminals over HTTP/3」に変更予定
  • QUIC+TLS1.3 を用いた安全なチャネル確立
  • HTTP認証 （OAuth 2.0、OpenID Connectなど）に対応し、Google/Microsoft/Githubアカウントでの認証も可能
  • 従来のSSH認証 （パスワード、公開鍵）も引き続きサポート

SSH3の主な特徴と利点

  • セッション確立の高速化
    • SSHv2は5～7往復必要だが、SSH3は 3往復 で完了
    • 実際のキーストローク遅延は変わらず
  • 新しい認証方式
    • OAuth 2.0 や OpenID Connect によるSSO
    • 企業アカウントや外部サービスアカウントでのログイン
  • 堅牢なセキュリティ基盤
    • TLS1.3、QUIC、HTTP による広く実績ある暗号化
    • X.509証明書 によるサーバ認証
  • UDPポートフォワーディング
    • QUICやDNS、RTPなど UDPベースのサービス にも対応
  • サーバの秘匿化
    • 秘密のURLパス でサーバを隠し、スキャン攻撃や辞書攻撃を回避
    • 404応答による存在の秘匿

セキュリティと運用上の注意

  • SSH3は実験段階
    • 現時点では 本番環境での運用は非推奨
    • サンドボックスやプライベートネットワークでのテスト推奨
    • 十分な 暗号レビューと脆弱性検証 が必要
  • 秘密URLは認証の代替不可
    • 秘密URLのみでアクセス制御せず、 従来の認証方式 を必ず併用
    • URLの秘匿は発見リスク低減用

SSH3の主な新機能

  • UDPポートフォワーディング
    • QUICデータグラムによるUDP転送
  • X.509証明書認証
    • Let's Encrypt等で取得した証明書を利用可能
  • OpenID Connectによるキー不要認証
    • SSOや外部アカウントでの認証
  • サーバの秘匿化
    • 秘密リンクによる非公開運用

OpenSSH互換機能

  • ~/.ssh/authorized_keys の解析
  • known_hosts によるサーバ認証（X.509未使用時）
  • ssh-agent との連携、エージェント転送
  • TCPポートフォワーディング （リバースは今後対応予定）
  • Proxy Jump 機能（UDP経由でのプロキシ転送）
  • ~/.ssh/config の一部オプション対応（Hostname, User, Port, IdentityFile, UDPProxyJump）

インストールとセットアップ

  • Go install によるインストール
    • go install github.com/francoismichel/ssh3/cmd/...@latest
  • ソースコードからのビルド
    • git clone https://github.com/francoismichel/ssh3
    • クライアント: go build -o ssh3 cmd/ssh3/main.go
    • サーバ: CGO_ENABLED=1 go build -o ssh3-server cmd/ssh3-server/main.go
  • パス設定
    • /usr/binへのコピー、またはPATHへの追加

サーバのデプロイと証明書管理

  • サーバ起動例
    • Let's Encrypt証明書: ssh3-server -generate-public-cert my-domain.example.org -url-path /ssh3
    • 自己署名証明書: ssh3-server -generate-selfsigned-cert -url-path /ssh3
    • 既存証明書使用: ssh3-server -cert /path/to/cert -key /path/to/key -url-path /ssh3
  • 証明書の種類
    • 公開ドメイン名があればLet's Encrypt推奨
    • IPアドレスのみの場合は自己署名証明書も可
  • root権限 での実行推奨（他ユーザーとしてのログイン時）

認証情報の管理

  • ~/.ssh/authorized_keys および ~/.ssh3/authorized_identities でユーザー認証情報を管理
  • 詳細設定や運用方法は今後のドキュメント拡充予定

コミュニティへの呼びかけ

  • セキュリティ研究者や開発者の協力 を歓迎
  • コードベースのレビューや標準化団体への橋渡しを希望
  • IETF/IRTF プロセスへの進展も視野
  • 安全性と信頼性の向上 に向けて共同開発を推進

まとめ

  • SSH3 はSSHの新たな進化形として、 HTTP/3とQUIC の利点を活かしつつ、従来SSHの使い勝手も継承
  • 現段階では 実験的 であり、セキュリティ検証とコミュニティの協力が不可欠
  • 本番運用前には十分な検証とレビュー が必要
  • 将来的な標準化と普及 を目指すオープンなプロジェクト

Hackerたちの意見

伝統的なSSHより速いっていう主張には疑問を持ってたけど、READMEには接続を確立するのが速いって書いてあって、アクティブな接続は同じ速度だって。なるほど、納得できるし、合理的な主張だと思う。

└

HTTP/3やQUIC全体とも関連してるし、主要な「セールスポイント」の一つは、ラウンドトリップを減らして接続のセットアップを速くすることだからね。

└

でも、私の予想では、このツール/プロトコルは高遅延のリンクでSSHよりずっと速いと思う。UDPを使うだけで、データを送る前にACKを待たなくていいから、大きなファイルを世界の一部から別の部分にscpする時にはかなりのブーストになるかも。

└

この意味では速くはないよ。ただ、SSH接続はポートフォワーディングのために複数のサブストリームを持つことができる。古典的な接続の上では、ヘッドオブラインブロッキングが起こることがあって、一つのストリームの問題が全体を遅くすることがある。QUIC/HTTP3プロトコルがこれを解決できるんだ。

なんでか、すべてのアプリケーションレイヤープロトコルがHTTPに吸収されるのがちょっと悲しい。

└

ずっとHTTPって呼び続ける限り、ちょっとごちゃごちゃしてる感じがする。接続初期化のベストプラクティスがすごく複雑になってるし、たくさんのプロトコルが同じ基本要素を必要としてるから、最も実績のあるプロトコルのアプローチを利用するのは有益なんだけど、もうハイパーテキストを転送するために使ってるわけじゃないから、なんか変な感じ。

└

もし本当にそうなら悲しいけど、標準のHTTPリクエスト/レスポンスモデルは多くのユースケースに対して制約が強すぎて、過剰設計になってるからね。でも、HTTP/2とQUIC（HTTP/3の「トランスポート層」）はすごく汎用的だから、HTTPの部分があまり意味を持たなくなってる気がする。少なくともQUICはTCPの代替として比較的オープンに推進されてるし、HTTPが主なユースケースだし。

└

これが採用される兆しはあるのかな？リンクされたietfの提出は期限切れの個人ドラフト（誰でも送れるやつ）で、SSH仕様の作業グループからのものじゃないみたいだし、SSH3って楽観的な名前を使った研究者たちからのものみたいだね。

└

これは、誤った企業のセキュリティチームが他のすべてをブロックして中断させる結果としての必要悪だね。ZscalerをTLSの中間者攻撃モードで運用してるチーム、見てるよ。

└

そうそう、あの古いネットワークの人たちや、技術に詳しくない企業の上司のおかげだよね。空港や世界中のホテルのワークスイートでWi-Fiを使ったことがあるなら、Apple Mailがメールを送受信できないことに気づくはず。多分、スパム対策の名のもとに、まずポート25をブロックするという企業全体のポリシーがあるんだ。すぐに143、587、993、995もブロックされるよ。今や80と443だけがファイアウォールを通過できる唯一のポートだね。本当に残念だよ。v6がもっと良くなってくれるといいな。で、EUがチャットコントロールをやろうとしてるって知ってる？この無意味なことをやめて、技術を実際に知ってる人の話を聞いてほしい。

└

なんかおかしい感じがするのは分かるよ。多様性が欠けてると、エコシステムの強靭性が失われてる気がする。でも、いい面もあるんだよね。多くのセキュリティ問題が、非常によくメンテナンスされた一つのスタックに集中してるから。つまり、その上に構築されたものは同じ攻撃面を共有してるってこと。確かに、一気に崩れる可能性もあるけど、多くの目が脆弱性を探してるから、すぐに修正されるだろうしね。同様に、パフォーマンスの最適化も共有されてるし、こういうのが人気になるとハードウェアにまで押し込まれることもある。TCP/IPがIPX/SPXやDECNet、X.25よりも優れていることに、世界が合意したデメリットがあまり見られないし、Linuxカーネルがどこにでもあるのも同じことだよ。

現在のプロジェクトの計画がどうなってるのか気になるな。最後のリリースからもう1年以上経ってるし、GitHubでのコミットや他の活動もないし。論文をもとにプロジェクトを進めてるみたいだから、他の関連する側面にも継続的に取り組んでるのかな？

└

指摘してくれてありがとう。これ、もう死んだプロジェクトだと思うわ。コミット数239回だけで、基本的には概念実証みたいなもんだし、真剣に考える価値はないよね。一方でOpenBSDはめっちゃ活発だから、OpenSSHがすぐに取って代わられることはないと思う。

ssh3って名前、ほんと嫌だわ。リポジトリのトップにこれがあって嬉しかったよ：

「SSH3は名前を変えるかもしれません。依然としてHTTP/3の拡張接続の上で動作するSSH接続プロトコル（RFC4254）ですが、必要な変更は多くて、人気のあるSSH実装の哲学からも遠すぎて統合を考えるには無理があります。仕様のドラフトはすでに「HTTP/3上のリモートターミナル」に改名されましたが、いい永久的な名前を考えるためには少し時間が必要です。」

└

同感だわ。これって、誰かが「Windows 12」や「Linux 7」って名前のリポジトリ作るのと同じ感じ。

└

もしかしてSSH/3の方がいいかもね（SSH + HTTP/3）？

└

SSHTTP

└

SSHoH

└

h3sh | hush3 | qs | qsh | shh | shh3

└

Quic Remote Shellの略でqrs？それともHTTP 3 Shellのためのh3s？http3リモートシェルのためのH3rs？

└

rthymとか、何かバリエーションはどう？

└

https://github.com/francoismichel/ssh3/issues/79#issuecommen...

└

HTTPSSH。なんでSSH/QUICにしないの？ HTTP/3のレイヤーはQUICにはない何を追加するの？

└

ussh（UDP用）

これ、HTTPの認証メカニズムなしでQUIC上のSSHにすべきだと思う。後者はユーザーにはほとんど使われてないし（API呼び出しやBearer認証だけ）、シェルログインには独自のセマンティクスがたくさんあるからね。例えば、PAM TOTP（あるいは単にパスワード+OTP）をHTTP認証に組み込むのは、かなり大変だと思うよ…

└

僕は別の視点で見てるんだ。全てのサービスで使ってる会社のアイデンティティをSSHでも簡単に使えるようにすれば、Linuxサーバー管理のための認証やRBACをちゃんと扱うのがすごく楽になると思う。今はSSHキーを使い分けなきゃいけないからね。SSH証明書に移行したいと思ってたけど、まだそのためのソフトウェアはあまりないんだよね（誰か作りたい人いる？連絡してね）。だから、Entra IDで誰かをブロックしたら、すぐに全てのサーバーからもロックアウトされるっていう安心感があれば、実際にすごくいいと思う。

PAM TOTP（あるいは単にパスワード+OTP）をHTTP認証に？ でも、なんでそんなことするの？ セッションを開始する前に、ユーザーはIdPに認証しなきゃいけないから、たぶんMFAやパスキーも含まれてるしね。もうPAMは必要ないよ。

└

それ、もう何年も前からあるよ： https://github.com/moul/quicssh

SSHv2で新しいセッションを確立するのに、5〜7回のネットワーク往復時間がかかることがあり、ユーザーには簡単に気づかれる。SSH3は3回の往復時間だけで済む。実行中のセッションのキーストローク遅延は変わらない。残念だね。ユーザーの視点から見ると、魅力を感じないな。接続設定の時間は、僕にとっては全然ストレスじゃなかったし。SSHは実績があるから、これを信頼するのはリスクがある気がするよ。たとえ彼らが生産準備完了と宣言してもね。

SSHが注目されてるのはいいけど、新機能に関してもうちょっと野心的になってほしいな。新しいものを作ってる感じがするから、ちょっと残念。接続の移行をサポートするみたいだけど、Moshのローミングや不安定な接続のサポートもあったらいいなと思う。

└

確か、接続の移行（それにマルチパス処理も）はQUICの機能なんだよね。それで、そのローミング機能は「組み込みのtmux」とどう違うの？ 組み込みの部分が本当に利点になるかはわからないな…。

セッション中のキーストロークのレイテンシは変わらない それは残念だね。レイテンシが低くて、持続的なセッション（毎回接続コストを払わなくていい）がMoshの一番の魅力なんだよね。

└

体感レイテンシが下がる。

SSHがサンドボックス化やアイソレーションのために多くの分離を使ってるデザイン制約について、まだ誰もコメントしてないのを見たことがないな。トランスポートはできるだけシンプルであるべきだと思う。SSHは高性能ゲートウェイを管理するための信頼できる、安全なトンネルである必要がある。攻撃面を避けるためにオフにできる方法がたくさんあるし、HTTPプロトコルには多くの基本要件がある。問題が違うんだよね。

任意のTCPポートをトンネリングできるの？