VPSにTor経由で接続する方法

Anonymity · 8 分で読了

簡単に言うと: SSHをTor経由で通すには2つの方向がある。クライアント側をTorのローカルSOCKSプロキシに向けて自分のIPをサーバーから隠す方法と、VPS側のSSHポートをTorのonionサービスとして公開し、サーバー自体がクリアネット上に到達可能なSSHポートを一切持たないようにする方法だ。この2つは組み合わせることもでき、そうすればセッションのどちら側もオープンインターネットに一切触れない。直接接続に比べて明らかにレイテンシが増すことは覚悟すべきで、これは大容量のファイル転送の手段としてではなく、インタラクティブなシェル作業のための管理アクセス手法として捉えるべきだ。

「SSH over Tor」と呼ばれる2つの異なる問題

tor vps accessを検索している人は、たいてい2つの異なる問題のどちらかを解決しようとしていて、設定はどちらが該当するかによって変わる。1つ目はクライアント側の問題だ。自分のIPアドレスを、サーバーから、自分のローカルネットワークを監視している者から、そして後にVPSプロバイダーの接続ログに召喚状を送る誰かから隠したい、というものだ。2つ目はサーバー側の問題だ。VPS自体が公開インターネットから到達可能なSSHポートを一切持たないようにし、ポートスキャナーに発見されず、認証情報スタッフィングボットの標的にもならず、リスニングサービスから位置を特定されないようにしたい、というものだ。

この2つは互いに排他的ではない。ssh over torに関するフォーラムスレッドの混乱の多くは、「誰が接続しているかを隠したい」と「何に接続しているかを隠したい」を混同するところから生じている。本ガイドでは、より単純なクライアント側の設定から始め、次にサーバー側のonionサービス方式、そして結果の強化方法と、実際に期待できるパフォーマンスまで、両方を扱う。

クライアント側の匿名性:SSHクライアントがTorを経由するため、サーバー(および受信接続をログに記録する誰か)にはTorの出口ノードやリレーが見え、あなたの実IPは見えない
サーバー側の匿名性:sshdはTorのonionアドレス経由でしか到達できないため、SSH用の公開IP:ポートがそもそも存在しない

方法1:SSHクライアントをTorのSOCKSプロキシ経由にする

動作中のTorクライアント(Tor Browserではなく、Torデーモン自体)は、デフォルトで127.0.0.1:9050にローカルSOCKS5プロキシを公開する。SOCKS対応のアプリケーションであればこれを利用できるが、SSH自体はネイティブでSOCKSを話さないため、小さな橋渡しが必要になる。よく使われる2つの方法は、コマンドをラップしてそのTCP接続をプロキシ経由に強制するtorsocksと、SOCKS対応のnetcatを経由して接続をパイプするSSH設定内のProxyCommandエントリだ。

最も手っ取り早いテストは、torをインストールし、動作を確認した上で torsocks ssh user@your-vps-ip を実行することだ。これで接続できれば、SSHセッションは今や3ホップのTor回路を経由している。日常的に使うものについては、毎回torsocksを打つ代わりに ~/.ssh/config にHostブロックを追加し、nc -X 5 -x 127.0.0.1:9050 %h %p(OpenBSD netcatの場合)や connect -S 127.0.0.1:9050 %h %p(connect-proxyツールの場合)といったProxyCommand行を使うとよい。そうすれば、ラッパーを毎回思い出さなくても、ただの ssh myhost が常にTor経由で動作するようになる。

SSH自体のトラブルシューティングを始める前に、Torが実際に動作していて9050番でリッスンしていることを確認する
torsocks ssh user@host は最速のテスト方法。~/.ssh/config内のProxyCommandは日常的に使うための恒久的な方法
この方法はVPSとその認証ログを読む誰からもIPを隠すが、SSHポート自体は依然として公開インターネットに開いたままだ

方法2:VPS上でSSHをTor onionサービスとして公開する

目的が、管理アクセスに関してVPS自体のIPアドレスを完全に表舞台から消すことであれば、サーバー側でTorを動かし、sshdをhidden serviceとしてのみ公開する必要がある。VPS上にtorをインストールし、torrcに2行を追加する。Torが書き込み可能なディレクトリを指すHiddenServiceDirと、onionアドレスのポート22に到着した接続をローカルでリッスンしているsshdへ転送するよう指示する HiddenServicePort 22 127.0.0.1:22 だ。Torを再起動すると、最初の起動時にそのディレクトリ内に長いランダムな .onion ホスト名が生成される。

重要なのは、sshdにもVPSの公開インターフェースではなく127.0.0.1にバインドするよう指示しない限り(sshd_config内の ListenAddress 127.0.0.1、その後sshdを再起動)、この手順だけでは露出が取り除かれないという点だ。この手順を飛ばすと、SSHはonionアドレス経由でも公開IP上でも直接到達可能なままになり、意味がなくなる。設定が完了したら、クライアント側から torsocks ssh [email protected] で接続する。VPSのポートスキャンには、SSH用のIPv4またはIPv6アドレスが一切現れなくなる。

torrcに HiddenServiceDir と HiddenServicePort 22 127.0.0.1:22 を追加し、Torを再起動する
sshd自体を127.0.0.1のみにバインドする。まだ公開されたポートの手前にonionサービスを置くだけでは何も隠していない
HiddenServiceDir内に生成されたホスト名ファイルを読んで、接続先の.onionアドレスを取得する
torsocks ssh [email protected] で接続する。裸のIPはSSH用としてはもう一切機能しない

SSHが.onionでのみ応答するようになったら認証を固める

ポートを隠すことは、ログイン自体を強化することの代わりにはならない。ed25519の鍵ペアを使い、パスワード認証を完全に無効化し(PasswordAuthentication no)、SSH経由のrootログインも無効化する(PermitRootLogin no)。このVPSに到達するために使う鍵が、日常的なアカウントで使っている鍵と同じものであれば、その鍵のフィンガープリントが漏えいデータや、他の場所であなたの名前に紐づいたShodan/Censysスキャンに現れた瞬間、onionサービスによって得られた匿名性は台無しになる。匿名インフラ専用の鍵を新たに生成すること。

この設定で静かに機能しなくなるものが一つある。fail2banのようなIPベースのツールだ。接続はローカルのTorプロセスを経由してsshdに到着するため、成功・失敗を問わずすべてのログイン試行についてsshdがログに記録する送信元アドレスは127.0.0.1になる。攻撃者IPというものが存在しないのだ。これは何か回避策で埋めるべきギャップではない。パスワードのフォールバックがない鍵のみの認証は、そもそもfail2banが緩和しようとしているブルートフォースのリスクをすでに取り除いている。ただ、この構成ではそのログが意味を持たないことを理解しておけばよい。

鍵のみの認証、ed25519、パスワードのフォールバックなし
匿名サーバーごとに専用の鍵ペアを用意し、個人のマシンから決して使い回さない
PermitRootLogin no とし、実作業にはsudo権限を持つ非rootアカウントを使う
トラフィックがTor経由で到着するようになったら、fail2banやIP許可リストに頼らない。ログ上の送信元IPは常にループバックになる

実際のパフォーマンスはどうなるか

標準的なTor回路は3つのリレーで構成され、onionサービス経由の接続は3ホップの回路を2つ(クライアントからTorネットワークへの1つ、Torネットワークからhidden serviceへの1つ)エンドツーエンドで重ねる。そのため往復レイテンシは、回路の再構築時に時折スパイクが発生しつつも、数百ミリ秒から数秒程度になることが一般的だ。設定ファイルの編集、ログの確認、サービスの再起動といったインタラクティブな作業は、このレイテンシでも十分実用的だ。追加のホップによってアイドルセッションが切断されないよう、SSH設定でServerAliveIntervalを設定しておき、Torが新しい回路を選ぶ際に時折発生する停滞も想定しておこう。

うまくいかないのはスループットだ。scp、rsync、あるいは何ギガバイトも動かすような処理は、直接接続に比べて這うように遅くなる。Tor回路は多数の短命なストリームにまたがる低レイテンシのインタラクティブ性のために最適化されているのであって、持続的な帯域幅のためではないからだ。実際のデータ転送(バックアップや大容量アップロード)には、直接の暗号化チャンネル(公開IP上の通常のSSH/rsync、あるいはWireGuardトンネル)を使い、Tor経路は接続を隠すことが速度よりも重要な、管理用シェルアクセス専用に取っておくこと。

せっかくの匿名性を静かに壊してしまう間違い

ここでの失敗のほとんどは大げさな話ではない。裏口を開けたままにしてしまう、小さな設定の抜け漏れがほとんどだ。信頼する前に、以下の点に注意すること。

これらはどれも高度なツールを必要としない。Torの設定だけで済んだと決めつけるのではなく、実際にリッスンしているポートとDNSの挙動を一度確認しさえすればよい。

sshdがonionサービスと並行して依然として公開インターフェースにもバインドされており、「隠した」はずのポートが単純なポートスキャンでも見つかってしまう
Torの外でホスト名を解決してしまう(意図しないDNSルックアップや、DNSに関してSOCKSプロキシを無視するアプリケーション)ことで、Tor接続が始まる前に、これから接続しようとしているホストが漏れてしまう
Torが動いていない場合に黙って直接接続にフォールバックするProxyCommand。Torデーモンが停止している場合は接続しない「フェイルクローズ」になるよう設定し、意図せずクリアネット接続してしまう「フェイルオープン」を避けること
このセッションを、他の場所での非匿名の身元に結びつけるSSH鍵、端末プロンプト、シェル履歴の使い回し

SSHアクセス方式の比較
方式	何を隠すか	典型的な追加レイテンシ	設定の手間
クリアネット上の直接SSH	SSH自体の暗号化以外は何も隠さない	なし	なし
クライアントをTorのSOCKSプロキシ経由にする	自分のIPアドレス。サーバーとそのログから	中程度 — おおよそTor回路1本分、~300ms〜1秒	低い — torsocksまたはProxyCommand1行
SSHをTor onionサービスとして公開する	VPSの公開IP。インターネット上に開いたSSHポートがなくなる	中〜高 — サーバー側の回路が追加される	中程度 — torrcとsshd_configの変更が必要
両方の組み合わせ:クライアントはTor経由、サーバーはonionサービス	接続の両端が完全にクリアネットから外れる	最も高い — 独立した3ホップ回路が2つ	中程度

よくある質問

SSH over TorはSSHの暗号強度を弱めますか?+

いいえ。SSHは、それを運ぶトランスポートとは独立して、自らのエンドツーエンド暗号化チャンネルをネゴシエートします。Torはその上にさらに回路暗号化の層を加えるため、トラフィックは弱い何かで一度暗号化されるのではなく、二重に暗号化されることになります。

SSH over Torは実際の管理業務には遅すぎますか?+

ファイルの編集、ログの確認、サービスの再起動といったインタラクティブなシェルセッションであれば、追加されるレイテンシは目立つものの十分扱える範囲です。バックアップや大容量アップロードのような一括転送には、代わりに直接接続かWireGuard接続を使い、Tor経路は管理アクセス専用に取っておいてください。

SSHがonionサービス経由でしか到達できない場合でもfail2banは使えますか?+

実質的には使えません。接続はTorのローカルプロセスからsshdに到着するため、すべてのログイン試行が127.0.0.1発としてログに記録されます。代わりにパスワードのフォールバックがない鍵のみの認証に頼ってください。それがfail2banの本来の目的であるブルートフォースのリスクをすでに取り除いているからです。

VPSへのアクセスにはTorに加えてVPNも必要ですか?+

通常は不要です。商用VPNをTorの手前に連ねると、このユースケースに対して実質的な保護を加えることなく、信頼をVPNプロバイダーに移すだけになりがちです。SSHセッションにはTor単体で、レイテンシがTorネットワーク経由よりも重要な場合はWireGuardトンネルで、実用上のケースはカバーできます。

両端ともTorを動かす必要がありますか、それとも自分のノートPCだけでよいですか?+

自分のIPをサーバーから隠すだけなら、クライアント側だけがTorを動かしていれば十分です(方法1)。サーバー側のIPも隠すには、VPS側でもTorを動かし、sshdをonionサービスとして公開する必要があります(方法2)。この2つの設定は独立しており、別々にも一緒にも使えます。

オフショアを始める準備はできましたか?

本人確認もメールも不要——必要なのは匿名キーと暗号資産だけ。~55秒でデプロイ。

VPSを設定 →