[!NOTE] SSH3は名称変更の可能性があります。依然としてSSH接続プロトコル（RFC4254）をHTTP/3 Extended Connect上で動作させるものですが、変更内容は大きく、一般的なSSH実装の哲学からかけ離れているため、統合を検討するのは難しい状況です。仕様ドラフトは既に名称変更されています（「HTTP/3上のリモート端末」）が、適切な恒久的な名前を決めるには時間が必要です。

SSH3: HTTP/3 を用いたより高速でリッチなセキュアシェル

SSH3はSSHプロトコルを完全に見直し、そのセマンティクスをHTTPメカニズムの上にマッピングしたものです。これは私たちの研究成果であり、私たち（研究者）はこれを最近、インターネットドラフト（draft-michel-remote-terminal-http3-00）として提案しました。

簡単に言うと、SSH3はセキュアチャネルの確立にQUIC+TLS1.3を、ユーザー認証にHTTP Authorizationメカニズムを使用します。とりわけ、SSH3は以下の改善を実現します。

• セッション確立の大幅な高速化
• 従来のSSH認証に加え、OAuth 2.0やOpenID Connectなどの新しいHTTP認証方式
• ポートスキャン攻撃に対する耐性：SSH3サーバーを他のインターネットユーザーから不可視にすることが可能
• 従来のTCPポート転送に加えてUDPポート転送
• 最新のQUICプロトコルが可能にするすべての機能：接続マイグレーション（近日対応）とマルチパス接続

[!TIP] すぐに始めたいですか？ SSH3のインストール をチェックしてください。SSH3サーバーのセットアップとSSH3クライアントの使い方を学べます。

⚡ SSH3はより高速

高速なのはセッション確立であり、スループットではありません！SSH3はSSHv2よりもセッション確立が大幅に高速です。SSHv2で新しいセッションを確立するには5～7回のネットワークラウンドトリップが必要で、ユーザーが容易に体感できます。SSH3はわずか3回のラウンドトリップで済みます。実行中のセッションにおけるキーストローク遅延は変わりません。

SSH3（上） VS SSHv2（下）のセッション確立（サーバーへのping 100ms）

🔒 SSH3のセキュリティ

SSHv2がユーザー認証とセキュアチャネル確立に独自のプロトコルを定義しているのに対し、SSH3は強固で実績のあるTLS 1.3、QUIC、HTTPのメカニズムに依存しています。これらのプロトコルは、eコマースやインターネットバンキングなど、インターネット上のセキュリティクリティカルなアプリケーションの保護にすでに広く使用されています。

SSH3はすでに、一般的なパスワードベースおよび公開鍵（RSA、EdDSA/ed25519）認証方式を実装しています。また、OAuth 2.0などの新しい認証方式もサポートしており、Google/Microsoft/Githubアカウントを使ってサーバーにログインできます。

🧪 SSH3はまだ実験的

SSH3は高速なセッション確立に有望ですが、まだ初期の概念実証段階です。新しい複雑なプロトコルには、合理的なセキュリティ結論を導き出す前に、専門家による長期間の暗号レビューが必要です。

私たちはSSH3をオープンソースプロジェクトとして開発し、コミュニティのフィードバックと分析を促進しています。しかし、さらなるピアレビューなしに、本番システムへの適合性を推奨することはできません。関連する専門知識をお持ちの方は、ぜひご協力ください。

🥷 今のところ、本番サーバーにSSH3サーバーをデプロイしないでください

現在のプロトタイプの状態を考慮し、SSH3はサンドボックス環境またはプライベートネットワークでテストすることをお勧めします。実験的なサーバーを直接インターネットに公開すると、徹底的なセキュリティ評価が行われる前にリスクが生じる可能性があります。

サーバーを秘密のパス背後に隠すことには潜在的な利点がありますが、本番環境に入る前に厳格な脆弱性分析の必要性がなくなるわけではありません。私たちはSSH3の将来の可能性に興奮していますが、さらなる精査を推奨します。

🥷 SSH3の公開サーバーを隠すことができます

SSH3を使えば、SSHサーバーに対するスキャンや辞書攻撃による通常のストレスを回避できます。秘密のGoogleドライブ文書と同様に、SSH3サーバーを秘密のリンクの背後に隠し、次のように特定のリンクへのHTTPリクエストのみに認証試行を応答させることができます。

ssh3-server -bind 192.0.2.0:443 -url-path <my-long-secret>

<my-long-secret> を、たとえばランダムな値 M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU に置き換えると、SSH3サーバーはURL https://192.0.2.0:443/M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU へのSSH3接続試行にのみ応答し、それ以外のリクエストには 404 Not Found を返します。そのため、インターネット上の攻撃者やクローラーはSSH3サーバーの存在を検出できません。単にすべてのリクエストに404ステータスコードを返す単純なWebサーバーとして見えるだけです。

注意: SSH3サーバーを秘密のURLの背後に配置すると、スキャン攻撃の影響を軽減できる可能性がありますが、従来の認証メカニズムを決して置き換えることはできません。秘密リンクは、ホストが発見されるのを防ぐためにのみ使用するべきです。秘密URLを知っていることが、誰かにサーバーへのアクセスを許可するものであってはなりません。サーバーを保護するには、上記の従来の認証メカニズムを使用してください。

💐 SSH3はすでに豊富な機能を備えています

SSH3は、SSHv2プロトコルでは提供できなかった新機能を提供します。

まったく新しい機能

• UDPポート転送: SSH3ホストからのみ到達可能なQUIC、DNS、RTP、またはUDPベースのサーバーにアクセスできます。 UDPパケットはQUICデータグラムを使用して転送されます。
• X.509証明書: 従来のHTTPS証明書を使用してSSH3サーバーを認証できるようになりました。このメカニズムは、従来のSSHv2ホスト鍵メカニズムよりも安全です。証明書は、たとえばLetsEncryptを使用して簡単に取得できます。
• サーバーを秘密のリンクの背後に隠す機能。
• OpenID Connectを使用したキーレスでセキュアなユーザー認証。会社のSSOやGoogle/Githubアカウントを使用してSSH3サーバーに接続でき、ユーザーの公開鍵をコピーする必要がなくなります。

実装済みの有名なOpenSSH機能

このSSH3実装は、OpenSSHの人気機能の多くをすでに提供しており、OpenSSHに慣れている方なら、SSH3への移行はスムーズです。以下は、SSH3も実装しているOpenSSH機能の一部です。

• サーバー上で ~/.ssh/authorized_keys を解析
• 証明書ベースのサーバー認証
• X.509証明書を使用しない場合の known_hosts メカニズム
• 公開鍵認証に ssh-agent を自動的に使用
• SSHエージェント転送により、ローカル鍵をリモートサーバーで使用
• 直接TCPポート転送（リバースポート転送は今後実装予定）
• プロキシジャンプ（-proxy-jump パラメータ参照）。AがSSH3クライアント、BとCが両方ともSSH3サーバーの場合、Bをゲートウェイ/プロキシとして使用してAからCに接続できます。プロキシはUDP転送を使用してAからCへのQUICパケットを転送するため、BはA<->CのSSH3トラフィックを復号化できません。
• クライアントで ~/.ssh/config を解析し、Hostname、User、Port、IdentityFile の設定オプションを処理します（他のオプションは現在無視）。また、OpenSSHの ProxyJump と同様に動作する新しい UDPProxyJump も解析します。

🙏 コミュニティサポート

SSH3を責任を持って前進させるためにご協力ください！有能なセキュリティ研究者の皆様にコードベースをレビューし、フィードバックを提供していただけると幸いです。また、時間をかけて正式なIETF/IRTFプロセスを通じてSSH3を発展させる可能性について、関連する標準化団体との連携もお願いします。

協力を得ることで、SSH3を安全に本番環境で使用できるよう、反復的に改善していきたいと考えています。しかし、広範な専門家による暗号レビューと信頼されるセキュリティ機関による採用の証拠なしに、確定的なセキュリティ主張をすることはできません。SSH3の可能性を実現するために、一緒に取り組みましょう！

SSH3のインストール

最新のリリースバイナリをダウンロードするか、go install を使用してインストールするか、ソースコードをコンパイルして自分でバイナリを生成してください。

[!TIP] SSH3はまだ実験的であり、研究の成果です。新しいSSH3サーバーを公開デプロイするのが不安な場合は、SSH3のシークレットパス機能を使用して、サーバーを秘密のURLの背後に隠すことができます。

Go install を使用して ssh3 と ssh3-server をインストール

go install github.com/francoismichel/ssh3/cmd/...@latest

ソースからSSH3をコンパイル

これには最新の Golang バージョンが必要です。 以下の手順でソースコードをダウンロードし、バイナリをコンパイルします。

git clone https://github.com/francoismichel/ssh3    # リポジトリのクローン
cd ssh3
go build -o ssh3 cmd/ssh3/main.go                        # クライアントのビルド
CGO_ENABLED=1 go build -o ssh3-server cmd/ssh3-server/main.go   # サーバーのビルド（gccが必要）

root/sudo権限があり、ssh3を全ユーザーが利用できるようにしたい場合は、バイナリを /usr/bin に直接コピーできます。

cp ssh3 /usr/bin/ && cp ssh3-server /usr/bin

それ以外の場合は、実行ファイルを PATH 環境変数に追加するだけです。.bashrc または同等のファイルの末尾に次の行を追加します。

export PATH=$PATH:/path/to/the/ssh3/directory

SSH3サーバーのデプロイ

ホストに接続する前に、そのホストにSSH3サーバーをデプロイする必要があります。現在のところSSH3デーモンはありませんので、screen や類似のユーティリティを使用して ssh3-server 実行ファイルをバックグラウンドで実行する必要があります。

[!NOTE] SSH3はHTTP/3上で動作するため、サーバーにはX.509証明書と対応する秘密鍵が必要です。公開証明書は、サーバーで -generate-public-cert コマンドライン引数を使用すると、Let's Encrypt を通じて公開ドメイン名に対して自動生成できます。実際の認証局によって署名された証明書を生成したくない場合や、公開ドメイン名がない場合は、-generate-selfsigned-cert コマンドライン引数を使用して自己署名証明書を生成できます。自己署名証明書は、SSHv2のホスト鍵メカニズムと同様のセキュリティ保証を提供しますが、同じセキュリティ上の問題があります。サーバーへの最初の接続時に中間者攻撃に対して脆弱になる可能性があります。Let's Encrypt などの公開認証局によって署名された実際の証明書を使用すると、この問題を回避できます。

ssh3-server 実行ファイルの使用方法は以下の通りです。

Usage of ./ssh3-server:
  -bind string
        the address:port pair to listen to, e.g. 0.0.0.0:443 (default "[::]:443")
  -cert string
        the filename of the server certificate (or fullchain) (default "./cert.pem")
  -key string
        the filename of the certificate private key (default "./priv.key")
  -enable-password-login
        if set, enable password authentication (disabled by default)
  -generate-public-cert value
        Automatically produce and use a valid public certificate usingLet's Encrypt for the provided domain name. The flag can be used several times to generate several certificates.If certificates have already been generated previously using this flag, they will simply be reused without being regenerated. The public certificates are automatically renewed as long as the server is running. Automatically-generated IP public certificates are not available yet.
  -generate-selfsigned-cert
        if set, generates a self-self-signed cerificate and key that will be stored at the paths indicated by the -cert and -key args (they must not already exist)
  -url-path string
        the secret URL path on which the ssh3 server listens (default "/ssh3-term")
  -v    verbose mode, if set
  -version
        if set, displays the software version on standard output and exit

以下のコマンドは、ドメイン my-domain.example.org に対して有効なLet's Encrypt公開証明書を使用し、ポート443で公開SSH3サーバーを起動し、/ssh3 URLパスへの新しいセッション要求に応答します。

ssh3-server -generate-public-cert my-domain.example.org -url-path /ssh3

公開ドメイン名がない場合（IPアドレスのみの場合）、-cert および -key 引数を使用して既存の証明書をIPアドレスに使用するか、-generate-selfsigned-cert 引数を使用して自己署名証明書を生成します。

既存の証明書と鍵がある場合は、次のようにサーバーを実行してそれらを使用できます。

ssh3-server -cert /path/to/cert/or/fullchain -key /path/to/cert/private/key -url-path /ssh3

[!NOTE] OpenSSHと同様に、他のユーザーとしてログインするには、サーバーをroot権限で実行する必要があります。

認可用キーと認可用ID

デフォルトでは、SSH3サーバーは各ユーザーの ~/.ssh/authorized_keys および ~/.ssh3/authorized_identities ファイル内のIDを探します。 ~/.ssh3/authorized_identities は、後述するOpenID Connect（oidc）などの新しいIDを許可します。 rsa、ed25519 などの一般的な鍵タイプ、およびOpenSSH形式の鍵を使用できます。

SSH3クライアントの使用

SSH3サーバーが動作しているら、従来のSSHv2ツールと同様にSSH3クライアントを使用して接続できます。

ssh3 実行ファイルの使用方法は以下の通りです。

Usage of ssh3:
  -pubkey-for-agent string
        if set, use an agent key whose public key matches the one in the specified path
  -privkey string
        private key file
  -use-password
        if set, do classical password authentication
  -forward-agent
        if set, forwards ssh agent to be used with sshv2 connections on the remote host
  -forward-tcp string
        if set, take a localport/remoteip@remoteport forwarding localhost@localport towards remoteip@remoteport
  -forward-udp string
        if set, take a localport/remoteip@remoteport forwarding localhost@localport towards remoteip@remoteport
  -proxy-jump string
    	if set, performs a proxy jump using the specified remote host as proxy
  -insecure
        if set, skip server certificate verification
  -keylog string
        Write QUIC TLS keys and master secret in the specified keylog file: only for debugging purpose
  -use-oidc string
        if set, force the use of OpenID Connect with the specified issuer url as parameter
  -oidc-config string
        OpenID Connect json config file containing the "client_id" and "client_secret" fields needed for most identity providers
  -do-pkce
        if set, perform PKCE challenge-response with oidc
  -v    if set, enable verbose mode

秘密鍵認証

~/.ssh/id_rsa にある秘密鍵を使用して、/my-secret-path で待ち受ける my-server.example.org のSSH3サーバーに次のコマンドで接続できます。

  ssh3 -privkey ~/.ssh/id_rsa [email protected]/my-secret-path

エージェントベースの秘密鍵認証

SSH3クライアントはOpenSSHエージェントと連携し、エージェントとの通信には従来の SSH_AUTH_SOCK 環境変数を使用します。OpenSSHと同様に、SSH3はSSHエージェントが提供する鍵をリストし、デフォルトではエージェントが最初にリスンする鍵を使用して接続します。 エージェントで特定の鍵を使用したい場合は、上記のように -privkey 引数で直接秘密鍵を指定するか、-pubkey-for-agent 引数で対応する公開鍵を指定できます。これにより、エージェントだけが秘密鍵に直接アクセスできるが、公開鍵しか入手できない場合でも認証できます。

パスワードベース認証

推奨されませんが、サーバーでパスワード認証が明示的に有効になっている場合（ssh3-server で）、次のコマンドでサーバーに接続できます。

  ssh3 -use-password [email protected]/my-secret-path

設定ベースのセッション確立

ssh3 はOpenSSH設定を解析します。現在、Hostname、User、Port、IdentityFile のOpenSSHオプションのみを処理します。 また、URLPath や UDPProxyJump など、SSH3でのみ使用される新しいオプションも追加します。URLPath を使用すると、SSH3コマンドで秘密のURLパスを省略できます。UDPProxyJump を使用すると、SSH3のプロキシジャンプを実行でき、-proxy-jump コマンドライン引数と同じ意味を持ちます。 ~/.ssh/config に以下の行があるとします。

IgnoreUnknown URLPath
Host my-server
  HostName 192.0.2.0
  User username
  IdentityFile ~/.ssh/id_rsa
  URLPath /my-secret-path

OpenSSHと同様に、以下の ssh3 コマンドは、192.0.2.0 のUDPポート443で実行されているSSH3サーバーに、.ssh/id_rsa の秘密鍵を使用した公開鍵認証で接続します。

  ssh3 my-server/my-secret-path

設定ベースのSSH3利用を希望しない場合は、以下のセクションを読んで ssh3 のCLIパラメータの使用方法を確認してください。

OpenID Connect 認証（まだ実験的）

この機能を使用すると、会社の外部IDプロバイダーや、Google Identity、Github、Microsoft Entra など、OpenID Connect標準を実装するプロバイダーを使用して接続できます。認証フローは下のGIFで示されています。

Googleアカウントを使用した、秘密鍵なしのセキュア接続。

IDプロバイダーへの接続方法は、~/.ssh3/oidc_config.json というファイルで設定します。以下は、Googleアカウントで使用する config.json ファイルの例です。この設定ファイルは配列であり、複数のIDプロバイダー設定を含めることができます。

[
    {
        "issuer_url": "https://accounts.google.com",
        "client_id": "<your_client_id>",
        "client_secret": "<your_client_secret>"
    }
]

これは将来変更される可能性がありますが、現在この機能をGoogleアカウントで動作させるには、Google Cloudコンソールで新しい実験的なアプリケーションを設定し、メールアドレスを許可ユーザーとして追加する必要があります。これにより client_id と client_secret が提供され、それらを ~/.ssh3/oidc_config.json に設定できます。サーバー側では、~/.ssh3/authorized_identities に以下の行を追加するだけです。

oidc <client_id> https://accounts.google.com <email>

現在、将来的に authorized_identities ファイルに client_id を設定する必要をなくすことを検討しています。

プロキシジャンプ

一部のSSHホストはゲートウェイを経由してのみアクセスできることがよくあります。SSH3では、OpenSSHが提供するものと同様のプロキシジャンプを実行できます。Bをゲートウェイ/プロキシとして使用して、AからCに接続できます。BとCはどちらも有効なSSH3サーバーを実行している必要があります。これは、B上でUDPポート転送を確立し、AからCへのQUICパケットを転送することで機能します。 したがって、AからCへの接続は完全にエンドツーエンドであり、BはAとCの間のSSH3トラフィックを復号化したり変更したりすることはできません。