途中の中継で SSH を横取りされない（Tor 出口リレー 333 件の傍受事例）
SSH は「初回のホスト鍵を確かめずに受け入れる」「パスワードでログインする」の 2 つがそろうと、経路上の中継に認証情報を抜かれる。ホスト鍵は事前に固定し、サーバー側はパスワード認証を止めて鍵認証にする。
何が起きたか
- 当時の Tor 出口リレー約 3,000 件のうち 333 件（約 1 割）が、22 番ポートへの SSH 接続を本来の宛先ではなく 12 台の傍受用サーバーへ転送していた。
- 研究者が出口リレーごとに接続してホスト鍵を調べたところ、約 12 件で偽のホスト鍵を検出。300 件超は同じ傍受サーバー群への転送だった。
- 利用者が偽のホスト鍵を受け入れてパスワードでログインすると、攻撃者は認証情報と入力したコマンドを取得できる。おとりのサーバーに入った攻撃者は Paramiko（Python の SSH ライブラリー）で接続し、権限を調べた後に Perl 経由でバックドア Ebury を入れようとした。
- 一部の出口設定は暗号化メールのポートを拒否し、平文でも使えるメールのポートだけを通していた。平文メールの収集も狙いと推測されている。
Tor に限らず、公衆 Wi-Fi や信用できないプロキシ・VPN 経由でも同じ形の攻撃は成り立つ。
利用者側の対策
- ホスト鍵を事前に固定する。 接続先のフィンガープリントを別経路（管理画面、構成管理、DNS の SSHFP など）で確認し、
known_hostsに登録してから接続する。初回の「yes」を反射的に押さない。 StrictHostKeyChecking yesを基本にする（未登録の鍵では接続しない）。少なくとも鍵の変更警告（REMOTE HOST IDENTIFICATION HAS CHANGED）が出たら接続を止める。- 組織なら SSH 証明書（ホスト証明書）で検証する。
@cert-authorityをknown_hostsに置けば、個別の鍵を配らなくても正しいホストか確かめられる。 - 信用できない経路で管理用の SSH を使わない。Tor 経由が必要なら、接続先を onion サービスにするほうが出口リレーを通らずに済む。
サーバー側の対策
sshd_configでPasswordAuthentication no、KbdInteractiveAuthentication noとし、公開鍵認証だけにする（報告者の推奨）。パスワードを抜かれる経路そのものがなくなる。- 鍵認証なら、中継が偽サーバーに誘導しても秘密鍵そのものは渡らない（ただしエージェント転送
ForwardAgentは信用できないホストに対して無効にしておく）。
リレー・サーバー運営者向け（Tor Project の案内）
侵害が疑われるリレーは停止し、消去前にディスクとログを保全する。そのうえで再インストール、リレーの識別鍵の再生成、ホスト上にあった認証情報の更新を行う。