Як керувати VPS через Tor

Ви придбали анонімний сервер, оплатили Monero та пропустили перевірку ID. Потім ви підключаєтеся до нього через SSH зі своєї домашньої IP-адреси через відкритий інтернет — і тихо передаєте своєму інтернет-провайдеру, транзитній мережі та будь-кому, хто спостерігає за сервером, чітку лінію, що веде від вашого обличчя до машини. Якщо ви хочете керувати сервером через Tor, мета проста: ніколи не дозволяйте жодному пакету в клірнеті пов'язати ваше реальне місцезнаходження з сервером, яким ви керуєте. Цей посібник охоплює практичні способи доступу до VPS та керування ним повністю через мережу Tor, а також витоки, які тихо це руйнують.

Tor дає вам два корисні примітиви для адміністрування. Ви можете маршрутизувати вихідний SSH через Tor як клієнт, щоб ваша реальна IP-адреса ніколи не торкалася сервера. Або ви можете опублікувати сам SSH-демон як onion-сервіс, щоб сервер не мав відкритого порту керування в клірнеті. Більшість обережних операторів використовують обидва способи разом. Ми почнемо з найпростішої конфігурації та перейдемо до найнадійнішої.

Чому взагалі керувати сервером через Tor

Анонімне надання послуг покриває лише вхідні двері. Якщо ви реєструєтеся без KYC та оплачуєте анонімний VPS без KYC, оплачений Monero, провайдер не має жодного імені чи картки, прив'язаних до вашого акаунта — але в момент, коли ви входите з домашнього з'єднання, ви створюєте новий постійний слід. Ваш провайдер бачить повторні з'єднання з конкретною IP-адресою дата-центру. Журнали автентифікації сервера фіксують вихідну адресу кожної сесії. Зіставте їх — і анонімність, за яку ви заплатили, зникає.

Маршрутизація трафіку керування через Tor закриває цю прогалину. Ваш інтернет-провайдер бачить лише те, що ви використовували Tor; він не бачить, до якого сервера ви зверталися. VPS бачить вихідний вузол Tor (або точку зустрічі для onion-SSH), але ніколи вашу адресу. Особа, яку ви не вказували у формі реєстрації, залишається прихованою в мережі, сесія за сесією.

Модель загроз, викладена прямо

Tor захищає мережевий шлях. Він не очищає машину, обліковий запис або ваші операційні звички. Перш ніж почати, чітко визначте, від чого ви насправді захищаєтеся: від пасивного спостерігача у вашій локальній мережі, від здатності провайдера співвіднести вашу IP-адресу керування з сервером та від журналів, які переживуть сесію. Tor вирішує всі три проблеми. Він не захистить вас, якщо ви вставите своє справжнє ім'я хоста в конфігурацію, повторно використаєте SSH-ключ, який уже пов'язаний з вашим ім'ям деінде, або запустите інструмент із витоками, який вирішує DNS поза тунелем. Будьте чесні з моделлю загроз — і ви зробите правильний вибір нижче.

Метод 1 — SSH через Tor за допомогою torsocks

Найшвидший спосіб пропустити одну команду через Tor — це torsocks, обгортка, яка змушує мережеві виклики програми йти через локальний SOCKS-проксі Tor (зазвичай 127.0.0.1:9050). Встановіть клієнт Tor на своїй робочій станції, переконайтеся, що демон запущено, а потім додайте префікс до вашої SSH-команди:

torsocks ssh [email protected]

Ключова деталь — DNS. Наївний ssh hostname спочатку вирішує ім'я на вашій машині через звичайний резолвер — це класичний витік, який повідомляє вашому провайдеру, до якого хоста ви збираєтеся звернутися, ще до того, як Tor побачить з'єднання. torsocks перехоплює getaddrinfo і також пропускає резолвінг через Tor, тому запит ніколи не потрапляє у ваш локальний резолвер. Підключення до сирої IP-адреси повністю уникає пошуку імені і є найбезпечнішою звичкою. У будь-якому разі перевірте: якщо ви бачите DNS-запит для імені хоста вашого сервера у власній мережі, тунель не виконує свою роботу.

Метод 2 — ProxyCommand у вашому SSH-конфігу

Для всього, що ви робите більше одного разу, вбудуйте Tor у ~/.ssh/config, щоб не забути обгортку. Використовуючи netcat із SOCKS-проксі, блок для хоста виглядає так:

Host ghost
  HostName 203.0.113.10
  User admin
  ProxyCommand nc -x 127.0.0.1:9050 -X 5 %h %p
  IdentitiesOnly yes
  IdentityFile ~/.ssh/ghost_ed25519

Тепер ssh ghost завжди з'єднується через SOCKS5-порт Tor, а %h/%p передаються проксі — отже, розв'язання імен відбувається на вихідному вузлі, а не на вашому сервері. Встановіть IdentitiesOnly yes, щоб ваш клієнт не розсилав усі ключі з вашого агента на сервер (це і відбиток пальця, і невеликий витік). Дайте кожному анонімному серверу окремий ключ, який не асоціюється з вашою реальною особою деінде, і вимкніть автентифікацію за паролем на стороні сервера, щоб вгадані облікові дані були марними.

Один нюанс, про який варто знати: Tor додає затримку, і кожне нове коло — це свіжий випадковий вихід, тому інтерактивний ввід може здаватися повільним, а довгоживучі сесії іноді обриваються при ротації кола. Запуск вашої роботи всередині tmux або screen на сервері означає, що обрив кола коштує вам перепідключення, а не втрати сесії.

Метод 3 — опублікувати SSH як onion-сервіс

Найнадійніша позиція повністю усуває порт керування в клірнеті. Замість того, щоб відкривати порт 22 в інтернет і захищати його брандмауером, ви запускаєте onion-сервіс Tor на VPS, який пересилає на 127.0.0.1:22. Тоді SSH-демон прив'язується лише до localhost; нічого не відповідає на публічній IP-адресі. Ви отримуєте доступ до нього за адресою .onion, через Tor, наскрізно.

На сервері додайте onion-сервіс у ваш torrc, вказавши локальний SSH-порт:

HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 127.0.0.1:22

Перезапустіть Tor, прочитайте згенерований файл hostname для вашого v3 .onion і підключіться з клієнта, який маршрутизує через Tor:

torsocks ssh [email protected]

Це дає дві великі переваги. По-перше, немає відкритого SSH-порту, який інтернет міг би сканувати, підбирати паролі або знімати відбитки — автоматичним атакам на порт 22 просто немає по чому вдарити. По-друге, розташування сервера приховано від клієнта, а розташування клієнта — від сервера; зустріч відбувається всередині Tor. Дотримуйтеся актуальної, авторитетної документації Tor Project щодо onion-сервісів, а не старого блогу, оскільки точні директиви torrc та формати ключів змінюються між версіями. Для панелі адміністрування, приватної панелі керування або віддаленого Git-репозиторію застосовується той самий шаблон — опублікуйте порт localhost як onion і отримуйте до нього доступ через Tor. Наш посібник із запуску Tor-прихованого сервісу на анонімному VPS глибше розглядає цей аспект.

Onion-сервіси з автентифікацією клієнта: підвищення планки

Звичайна onion-адреса є невгаданою, але не справді приватною — будь-хто, хто дізнається .onion, може дістатися до запрошення входу. Tor підтримує авторизацію клієнта, коли onion навіть не завершить рукостискання, якщо клієнт не пред'явить попередньо розподілений ключ. Додайте публічний ключ вашого клієнта до каталогу authorized_clients сервісу, і onion стане невидимим для всіх інших: немає ключа — немає з'єднання, немає запрошення. Для кінцевої точки керування, до якої торкаєтеся лише ви, це перетворює «безпеку через невгадану адресу» на справжній криптографічний бар'єр.

DNS-витоки та деталі, які руйнують усе

Найпоширеніший спосіб, яким люди витікають, думаючи, що вони анонімні, — це DNS. Якщо будь-яка частина вашого робочого процесу вирішує ім'я сервера поза Tor, ви розкрили свою ціль. Віддавайте перевагу підключенню за IP або .onion; коли вам потрібно використовувати ім'я хоста, переконайтеся, що резолвінг проксіюється (torsocks, ProxyCommand або налаштування SOCKS на рівні застосунку з увімкненим віддаленим DNS). Пояснення EFF про те, що Tor приховує, а що ні — хороша перевірка реальності щодо того, де закінчується захист.

Ще кілька пасток, які варто назвати:

• Кореляція за часом. Вхід у систему за жорстким графіком з однієї ідентичності Tor — це патерн. Рідко має значення для адміністративної роботи, але знайте, що він існує.
• Журнали автентифікації на сервері. Навіть через Tor ваш VPS записує метадані підключення. На сервері, яким ви керуєте, налаштуйте, що зберігають SSH та системний журнал. Поєднайте керування через Tor із VPS без логів, щоб мінімізувати операційний рівень з обох боків.
• Змішані сесії. Не керуйте анонімним сервером в одному терміналі, поки інше вікно на тій самій машині зв'язується з обліковими записами, пов'язаними з вашим ім'ям. Тримайте анонімний робочий процес ізольованим — виділена віртуальна машина або окремий профіль користувача — це дешева страховка.
• Годинник і локаль. Копіювання та вставлення часових міток, імен хостів або вашого локального імені користувача в конфігурації та повідомлення коммітів тихо повторно прив'язує вашу особу. Видаліть їх.

Підтримання анонімного управління в довгостроковій перспективі

Анонімність — це не одноразове налаштування; це дисципліна, якої ви дотримуєтесь сесія за сесією. Ланцюг тримається лише тоді, коли тримається кожна ланка: анонімна реєстрація без KYC, оплата Monero, щоб не було карткового обліку, виділений SSH-ключ, не пов'язаний з вашим ім'ям, DNS, який ніколи не виходить за межі тунелю, та адміністрування виключно через Tor або автентифікований onion. Розірвіть будь-яку ланку — і інші вас не врятують. Збережіть їх усі — і в ланцюгу просто не буде точки, де ваша справжня особа та ваш сервер зустрічаються.

HushVPS є законно в офшорній юрисдикції та мінімізує дані, а не є беззаконною зоною. Керування власною машиною через Tor — це звичайна практика приватності; наша політика прийнятного використання все ще забороняє CSAM, шкідливе ПЗ та ботнет-інфраструктуру, спам і DDoS.