SSH トンネル経由でリレーに接続する

リレーは自分のサーバーに SSH で接続し、そのサーバーにポートをリレーへ転送し返すよう依頼できます。そうすると、サーバーのアドレスでリレーに接続でき、自宅ではインターネットに向けて待ち受けるものが何もなくなります。ssh のプロセスは、リレー自身が起動し、監視し、再起動します。

公開アドレスと SSH アクセスのあるサーバーをすでに持っている場合に選んでください。サーバーがない場合は、組み込みの Cloudflare Tunnel ならサーバーは不要です。

必要なもの #

• リレーのホストの PATH に ssh プログラムがあること（または、下記の command で別のプログラムを指定すること）。
• サーバーへの SSH ログインが、鍵で、確認なしにできること。リレーは ssh をバッチモードで実行するため、パスワードや鍵のパスフレーズを入力できません。パスフレーズ付きの鍵は、SSH エージェントがそれを保持している場合にだけ使えます。まずリレーのホストから試してください。ssh relay@relay.example.com が何も尋ねずにログインできる必要があります。
• トンネル用の、サーバー上の空いているポート（remotePort）。
• サーバー上で、そのポートを HTTPS で提供するもの（Caddy や nginx などの Web サーバーまたはリバースプロキシ）。トンネルはただの HTTP を運ぶので、これがないと、ポートに到達できるようになった時点で、トークンと会話が暗号化されずにインターネットを通ります。リバースプロキシの背後でリレーを動かすを参照してください。

リレーには sshd の特別な設定は要りません。remoteBind が loopback の場合、リレーはバインドアドレスなしで転送を要求するので、ポートが開く場所はサーバー自身の GatewayPorts の設定で決まります。既定値の no では、それはサーバー自身だけになり、インターネットに面するのはリバースプロキシだけです。public の場合、リレーはすべてのインターフェース（*:）を要求し、その要求はサーバーの sshd が許可している場合（GatewayPorts が clientspecified または yes）にだけ有効になります。

設定する #

config.json に sshTunnel ブロックを追加し（ファイルの場所を参照）、oar restart でリレーを再起動します。

"sshTunnel": {
  "mode": "managed",
  "required": false,
  "user": "relay",
  "host": "relay.example.com",
  "remotePort": 4444,
  "remoteBind": "loopback",
  "identityFile": "~/.ssh/id_ed25519"
}

サーバーでは、HTTPS をトンネルのポートに送ります。Caddy の場合：

relay.example.com {
    reverse_proxy localhost:4444
}

ブラウザーで https://relay.example.com/ を開き、アクセストークンでサインインします。リレーの起動時のバナーには Remote: の行が、oar url には QR コード付きで Tunnel URL: の行が出力されます。どちらも https:// に host の値を付けたもので、ポートは含まれず、トンネルが動作しているかも確認しません。そのため、正しいのはプロキシが標準のポートで HTTPS を提供している場合だけです。

sshTunnel のキー #

すべてのキーは sshTunnel ブロックに入ります。この表は、同じ一覧がある config.json と一致しています。

古い形式の "enabled": true も引き続き使え、"mode": "managed" を意味します。ただし、mode が disabled または managed に設定されていない場合に限ります。

リレーは、サーバーの remotePort を 127.0.0.1 上の自分のポート（port を変更していなければ 3333）に転送します。public の場合、転送は *:remotePort として要求され、それ以外の場合は remotePort として要求されます。

次の設定は固定で、キーはありません。リレーは ssh -N を ServerAliveInterval=30、ServerAliveCountMax=3、BatchMode=yes、StrictHostKeyChecking=accept-new、ExitOnForwardFailure=yes で実行します。ssh は、30 秒間隔の確認に 3 回続けて応答がないと、その接続をあきらめます。

必須の値（管理対象モードでの user、host、または有効な remotePort）が欠けている場合、リレーは通常どおり起動し、どれが欠けているかをログに出し、トンネルはオフのままにします。

動作 #

起動。 リレーは、待ち受けを始めた後にトンネルを起動します。ssh が 1.2 秒間動作し、サーバーが転送を拒否していなければ、トンネルが接続されたとみなします。その後、ログに Tunnel up to user@host remote port N と出ます。

再接続。 ssh が終了すると、リレーは待ち時間を延ばしながら再び起動します。5、10、20、40、そして 60 秒で、以降は 60 秒のままです。30 秒より長く続いた接続が切れると、カウントは最初からやり直しになります。リレーを停止すると、トンネルと再試行も止まります。

ホスト鍵。 リレーのホストが初めて接続するサーバーは、最初の接続で受け入れられ、記憶されます。その後ホスト鍵が変わると、known_hosts から古いエントリを削除するまで、ssh は接続を拒否します。

必須 #

required: true の場合、キューは起動時からトンネルが接続されるまで一時停止し、接続が切れるたびに再び一時停止します。送ったメッセージはキューで待ち、トンネルが動作すると実行されます。トンネルなしではリレーが役に立たない場合に使ってください。値が欠けていて起動できないトンネルでも、キューは一時停止したままになります。

リモートのポートが使われているとき #

サーバーがポートをバインドできないと言う場合、よくある原因は、以前のトンネルのセッションが残っていて、それが切れていることにサーバーが気付いていないことです。autoReclaimPort が false でない限り、リレーはサーバーに 2 回目の接続をして、そこでクリーンアップコマンドを実行します。

組み込みのクリーンアップは、次の順で処理します。

1. ポートが使われているかを確認します（ss を使い、なければカーネルの待ち受けソケットの一覧を読みます）。使われていなければ、そこで止まり、成功を報告します。
2. ポートで待ち受けているプロセスを探し（lsof、なければ fuser のうち、存在するほう）、終了シグナル（kill）を送って 1 秒待ちます。自分のログインがシグナルを送れないプロセスは残ります。この時点でポートが空いていれば、成功を報告します。
3. reclaimStaleSshSessions: true の場合に限り、かつポートがまだ使われている場合に限り、子プロセスを持たない自分のユーザーのすべての sshd セッションに終了シグナルを送り、1 秒待ちます。これらは ssh -N -R が残すセッションです。シェル、エディターのリモートサーバー、そのほかのプログラムを実行しているセッションは子プロセスを持つため、対象外です。クリーンアップを実行しているセッション自体も対象外です。
4. ポートがまだ使われている場合、クリーンアップはコード 3 で終了し、リレーはそれを is still held とログに出します。

remoteCleanupCommand を設定すると、これらすべての代わりに自分のコマンドが実行され、reclaimStaleSshSessions は効果がなくなります。リレーはそれを、同じ鍵による 2 回目の ssh ログインで、バッチモードで sh -lc '<command>' として実行します。コマンドは、ポートが空いていれば 0 で、まだ使われていればそれ以外のコードで終了する必要があります。

ポートを空けられたクリーンアップの後、リレーは 1 秒後に再試行し、続けて最大 3 回まで繰り返します。クリーンアップが失敗した後、または autoReclaimPort がオフの場合は、上記の通常の待ち時間を使います。

トンネルの状態を見る #

SSH トンネルは、Cloudflare トンネルが表示される場所には表示されません。oar status と oar doctor が報告するのは Cloudflare トンネルだけで、ステータスドットも SSH トンネルでは琥珀色になりません（ステータスドットを参照）。代わりに次の場所を見てください。

• リレーのログ。 すべての行が [ssh-tunnel] で始まります。実行する ssh のコマンドライン、ssh が出力する内容、Tunnel up to ...、Reconnecting in Ns (attempt N)...、ポートの回収の手順が表示されます。ログの場所はリレーの実行方法によって異なります。ファイルとフォルダーを参照してください。
• 起動時のバナー。 管理対象のトンネルが設定されているとき、Remote: の行と Tunnel: mode=loopback（または public）の行があります。これらが示すのは設定であり、トンネルが動作しているかどうかではありません。oar url は同じアドレスを Tunnel URL: として出力します。
• /api/status。 connected、connectedSince、reconnectAttempts、lastError、blocking、required、mode、valid、host、remotePort、remoteBindMode を持つ sshTunnel オブジェクトがあります。トークンを付けて取得してください。

lastError は、ssh が終了した後は exit:<code>、サーバーがポートを拒否した後は remote-forward-bind-failed:<code>、ブロックが不完全なときは invalid-config または値が欠けていることを示すメッセージになり、トンネルが動作している間は空です。

セキュリティ #

トンネルが動作すると、リレーにインターネットから接続できるようになり、見知らぬ人とあなたのエージェント（あなたのマシンでコマンドを実行します）との間にあるのはアクセストークンだけになります。そのため、次のようにしてください。

• remoteBind は loopback のままにし、サーバー上で前段に HTTPS を置いてください。public の場合、サーバーのトンネルのポートに到達できる人は誰でも、ただの HTTP でリレーに到達します。
• アクセストークンが唯一の鍵です。アクセストークンとリレーに接続できる範囲と OAR が公開するものを参照してください。
• リレーは、内部のセッションワーカーのパスへのリクエストが Cloudflare のマーカーヘッダー cf-ray か、tunnelMarkerHeaders に記載したヘッダーを含む場合、そのリクエストを拒否します。通常のリバースプロキシはこれらを何も付け加えないので、プロキシが付け加えるヘッダーのうちブロックしたいものがあれば、それを記載してください。config.json を参照してください。

トラブルシューティング #

まずログの [ssh-tunnel] の行を見てください。stderr: で始まる行は、ssh 自身が出力したものです。