VPS 用の Tor ベースの管理経路
SSH に SOCKS プロキシを使用し、プライベートな onion エンドポイントを公開し、パブリックアクセスを閉じる前に DNS、認証、および復旧を確認してください。
概要
TorはVPSに到達するために使われるネットワーク経路を変更でき、SSH onionエンドポイントは従来の公開管理先を回避できます。どちらのアプローチもサーバーを自動的に保護するものではありません。SSH鍵を保護し、ホストの身元を検証し、アクセスを制限し、依存する前に構成をテストしましょう。
チェックアウトと同様に管理も保護する
保護されたブラウザを通じてサーバーを注文しても、その後のSSHセッションが自動的に保護されるわけではありません。直接ログインすると、あなたの送信元アドレスがサーバーおよび経路上のネットワークに明らかになる可能性があります。最初の接続前に、優先ルートが失敗した場合の緊急アクセスを含め、管理をどのように行うかを決めてください。
Torは、クライアントの直接IPを宛先から隠すことができますが、資格情報の再利用、構成データの特定、またはあらゆるトラフィック相関攻撃に対する解決策ではありません。また、遅延も増加します。有用な目的は、その動作を理解し確認できる一貫した管理経路です。
動作するローカルのTorクライアントから始めてください
システム Tor デーモンは通常 127.0.0.1:9050 で SOCKS を提供し、一方 Tor Browser は通常 9150 を使用します。どちらのポートも想定せず、実際の設定を確認してください。アプリケーションはそのプロキシを通して接続を送信する必要があり、Tor Browser を開いてもコンピューター上のすべてのプログラムがルーティングされるわけではありません。
対応システムでは、torsocks が SSH などのアプリケーションをラップし、対応するネットワーク呼び出しを Tor 経由でルーティングします。設定は、ドキュメント専用の例のアドレスをサーバーの実際のアドレスに置き換えてテストしてください。次のコマンドは、稼働中のシステム Tor デーモンと専用の管理アカウントを前提としています。
torsocks ssh -i ~/.ssh/silentvps_ed25519 [email protected]ルートをSSH設定の一部にする
通常の使用では、ホストごとの設定によりラッパーを忘れる可能性が減ります。以下の例ではSOCKS5プロキシをサポートするnetcat実装を使用しています。実装によって異なるため、インストールされているバージョンで-xオプションと-Xオプションを確認し、ホスト名解決がリモートで行われるかどうかを検証してください。
IdentitiesOnlyはサーバーに提示する鍵を制限します。このプロジェクト用に使う新しい鍵と組み合わせてください。信頼できるプロビジョニング経路を通じてサーバーのホスト鍵フィンガープリントを確認し、保持してください。Torはネットワーク経路を変更しますが、SSHのホスト認証は依然として不可欠です。
Host silent-admin
HostName 203.0.113.45
User admin
IdentityFile ~/.ssh/silentvps_ed25519
IdentitiesOnly yes
ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %pSSHをオニオンサービスへ移す
オニオンエンドポイントを使えば、公的に到達可能なSSHポートなしで管理でき、この接続にTor出口を使うことを避けられます。サーバーにTorをインストールして設定し、その後オニオン仮想ポートをローカルのSSHサービスにマッピングしてください。この例は開始時の設定です。サービスのパスとコマンドはディストリビューションによって異なります。
Torがサービスディレクトリを作成した後、そのホスト名ファイルを非公開で取得し、クライアントプロキシ経由で接続をテストしてください。オニオンサービスの識別鍵は秘密に保ってください。独立したログインが成功した後にのみ、SSHをlocalhostに制限し、公的アクセスを削除してください。その変更を行う前に、復旧コンソールが動作することを確認してください。
HiddenServiceDir /var/lib/tor/silent-admin/
HiddenServicePort 22 127.0.0.1:22プライベートエンドポイントにクライアント認証を追加する
追加の認証がなければ、onionアドレスを知った者は誰でもサービスとそのSSHプロンプトに到達できます。Tor v3クライアント認証は別個の暗号ゲートを追加します。サービスは認証されたクライアントの公開鍵を保持し、クライアントは対応する秘密鍵を保持します。
鍵の形式とauthorized_clientsディレクトリについては、Torプロジェクトの現在の指示に従ってください。認証されていないクライアントが接続できないことを検証してください。SSH鍵認証も同様に維持し、自分自身の残りのアクセスを失うことなく、紛失したデバイスの認証を取り消す方法を計画してください。
DNSをテストし、身元の漏洩を避ける
ローカルリゾルバによるホスト名の照会は、接続がプロキシに到達する前にターゲットを明らかにする可能性があります。クリアネットの宛先にサーバーIPを使用すると、その特定の照会を避けられます。onion名はTor内での解決が必要です。その他のホスト名については、汎用のプロキシ設定に頼るのではなく、アプリケーションのリモートDNS動作を確認してください。
ゲストシステムは依然として認証タイムスタンプ、ユーザー名、ジャーナルエントリを保持している可能性があります。すべての診断を盲目的に無効にするのではなく、その保持を意図的に検討してください。また、ローカルのホスト名、コミットメタデータ、コピーされた設定に識別情報がないか検査してください。Torはアプリケーションのトラフィックからそれらを除去しません。
- 専用の鍵と分離されたプロジェクトワークフローを使用してください。
- 想定されるSOCKSポートとリモートDNS動作を検証してください。
- リスナーを変更する前に、リカバリーアクセスとテスト済みの第二のログインを維持してください。
- 更新後にTorおよびSSHサービスを確認してください。
- onionの身元鍵やクライアント認証の秘密を決して共有しないでください。
長いセッションと将来のメンテナンスを実用的に保つ
長時間の管理ジョブは tmux または screen 内で実行し、接続中断でセッションが破壊されないようにします。Tor 回線やネットワーク状況は変化し得るため、コマンドを再現可能に保ち、再開方法を理解しておきましょう。保守が計画されていれば、多少の追加遅延は許容しやすくなります。
同じ onion パターンで、ローカルダッシュボードやプライベート Git サービスを前面に置くことができます。各アプリケーションには依然として認証、ソフトウェア更新、慎重な設定が必要です。プライバシー要件が求める箇所では、サポート、更新、バックアップのために保護された経路を使い続けましょう。初期設定と同じくらい一貫性が重要です。