Как подключиться к VPS через Tor

Anonymity · 8 мин чтения

Коротко: SSH через Tor можно направить в двух направлениях: настроить клиент на локальный SOCKS-прокси Tor, чтобы скрыть свой IP от сервера, либо опубликовать SSH-порт VPS как onion-сервис Tor, чтобы у самого сервера вообще не было SSH-порта, доступного из открытого интернета. Оба подхода можно комбинировать, чтобы ни один конец сессии никогда не касался открытого интернета. Ожидайте заметно более высокую задержку по сравнению с прямым подключением, поэтому используйте это как метод административного доступа для интерактивной работы в шелле, а не как транспорт для передачи больших файлов.

Две разные задачи, обе называются «SSH через Tor»

Люди, ищущие доступ к vps через tor, обычно пытаются решить одну из двух разных задач, и настройка зависит от того, какая именно применима. Первая — на стороне клиента: вы хотите скрыть свой собственный IP-адрес от сервера, от любого, кто наблюдает за вашей локальной сетью, и от любого, кто позже потребует у VPS-провайдера логи соединений через повестку. Вторая — на стороне сервера: вы хотите, чтобы у самого VPS вообще не было SSH-порта, доступного из публичного интернета, чтобы его нельзя было найти сканером портов, атаковать ботом для подбора учётных данных или геолокировать по прослушивающей службе.

Эти задачи не исключают друг друга. Значительная часть путаницы на форумах про ssh через tor возникает из-за смешения «я хочу скрыть, кто подключается» и «я хочу скрыть, к чему подключаются». Этот гайд охватывает оба случая, начиная с более простой настройки на стороне клиента, затем переходя к подходу с onion-сервисом для сервера, а затем — к тому, как усилить результат и какую производительность реально ожидать.

Анонимность на стороне клиента: ваш SSH-клиент маршрутизируется через Tor, поэтому сервер (и любой, кто логирует его входящие соединения) видит выходной узел или релей Tor, а не ваш реальный IP
Анонимность на стороне сервера: sshd доступен только через onion-адрес Tor, поэтому публичного IP:порта для SSH вообще не существует

Способ 1: направить SSH-клиент через SOCKS-прокси Tor

Запущенный клиент Tor (демон Tor, не обязательно Tor Browser) предоставляет локальный SOCKS5-прокси, по умолчанию на 127.0.0.1:9050. Любое приложение, поддерживающее SOCKS, можно настроить на него, а сам SSH не поддерживает SOCKS нативно, поэтому нужен небольшой мост. Два распространённых подхода — torsocks, который оборачивает команду и направляет её TCP-соединения через прокси, и запись ProxyCommand в конфиге SSH, которая прогоняет соединение через SOCKS-совместимый netcat.

Самая быстрая проверка: установите tor, убедитесь, что он запущен, затем выполните torsocks ssh user@ваш-ip-vps. Если соединение установлено, ваша SSH-сессия теперь маршрутизируется через трёхузловую цепочку Tor. Для чего-то используемого ежедневно добавьте блок Host в ~/.ssh/config вместо того, чтобы каждый раз печатать torsocks, используя строку ProxyCommand вроде nc -X 5 -x 127.0.0.1:9050 %h %p (с OpenBSD netcat) или connect -S 127.0.0.1:9050 %h %p (с инструментом connect-proxy). Тогда простая команда ssh myhost будет работать и всегда проходить через Tor без необходимости помнить об обёртке.

Убедитесь, что Tor действительно запущен и слушает на 9050, прежде чем разбираться с самим SSH
torsocks ssh user@host — самый быстрый способ проверки; ProxyCommand в ~/.ssh/config — устойчивый способ использования изо дня в день
Этот метод скрывает ваш IP от VPS и от любого, кто читает его логи авторизации, но сам SSH-порт по-прежнему открыт в публичный интернет

Способ 2: опубликовать SSH как onion-сервис Tor на VPS

Если цель — полностью убрать собственный IP-адрес VPS из картины для административного доступа, серверу нужно запустить Tor и предоставлять sshd только как скрытый сервис. Установите tor на VPS, затем добавьте две строки в torrc: HiddenServiceDir, указывающую на директорию, в которую Tor может писать, и HiddenServicePort 22 127.0.0.1:22, что указывает Tor перенаправлять соединения, приходящие на порт 22 onion-адреса, на локально прослушивающий sshd. Перезапустите Tor, и при первом запуске он сгенерирует в этой директории длинное случайное имя хоста .onion.

Критически важно, что этот шаг устраняет открытость только в том случае, если sshd также настроен на привязку к 127.0.0.1, а не к публичному интерфейсу VPS (ListenAddress 127.0.0.1 в sshd_config, затем перезапуск sshd). Пропуск этого шага оставляет SSH доступным как через onion-адрес, так и напрямую по публичному IP, что сводит на нет весь смысл. После этого подключайтесь со стороны клиента через torsocks ssh user@вашдлинныйхост.onion — при сканировании портов VPS для SSH не появится ни публичного IPv4-, ни IPv6-адреса.

Добавьте HiddenServiceDir и HiddenServicePort 22 127.0.0.1:22 в torrc, затем перезапустите Tor
Привяжите сам sshd только к 127.0.0.1 — onion-сервис перед всё ещё публичным портом ничего не скрывает
Прочитайте сгенерированный файл hostname внутри HiddenServiceDir, чтобы получить .onion-адрес для подключения
Подключайтесь через torsocks ssh user@вашvps.onion; голый IP больше не будет работать для SSH вообще

Усиление аутентификации, когда SSH отвечает только на .onion

Скрытие порта не заменяет усиление защиты входа. Используйте пары ключей ed25519, полностью отключите парольную аутентификацию (PasswordAuthentication no) и отключите вход под root по SSH (PermitRootLogin no). Если ключ, который вы используете для доступа к этому VPS, — тот же самый, что и для повседневных аккаунтов, анонимность, полученная от onion-сервиса, подрывается в тот момент, когда отпечаток этого ключа всплывает в утечке данных или в сканировании Shodan/Censys, привязанном к вашему имени где-то ещё, — генерируйте выделенный ключ для анонимной инфраструктуры.

Одна вещь незаметно перестаёт работать в такой настройке: инструменты на основе IP, вроде fail2ban. Поскольку соединения приходят на sshd через локальный процесс Tor, исходный адрес, который логирует sshd, — 127.0.0.1 для каждой попытки входа, успешной или нет, — атакующего IP для блокировки просто нет. Это не пробел, который нужно закрывать обходным путём: аутентификация только по ключу без резервного пароля уже устраняет риск подбора, который fail2ban призван смягчать. Просто не ожидайте, что его логи будут содержательны в такой конфигурации.

Аутентификация только по ключу, ed25519, без резервного пароля
Выделенная пара ключей на каждый анонимный сервер, никогда не переиспользуемая с личной машины
PermitRootLogin no и учётная запись без root с sudo для реальной работы
Не полагайтесь на fail2ban или разрешающие списки IP, когда трафик приходит через Tor — исходный IP в логах всегда loopback

Как выглядит производительность на самом деле

Стандартная цепочка Tor состоит из трёх релеев, а соединение через onion-сервис накладывает друг на друга две трёхузловые цепочки сквозь весь путь (одна от клиента в сеть Tor, другая от сети Tor к скрытому сервису), поэтому задержка кругового пути обычно находится где-то между несколькими сотнями миллисекунд и парой секунд, с периодическими скачками при перестройке цепочки. Интерактивная работа — редактирование конфигов, просмотр логов, перезапуск службы — вполне удобна при такой задержке. Задайте ServerAliveInterval в конфиге SSH, чтобы простаивающие сессии не обрывались из-за дополнительного хопа, и ожидайте случайные зависания, пока Tor выбирает новую цепочку.

Что работает плохо — это пропускная способность. scp, rsync или что угодно, перемещающее гигабайты, будет ползти по сравнению с прямым соединением, потому что цепочки Tor оптимизированы для низкой задержки при интерактивности через множество коротких потоков, а не для устойчивой пропускной способности. Для реальной передачи данных — резервных копий, крупных загрузок — используйте прямой зашифрованный канал (обычный SSH/rsync по публичному IP или туннель WireGuard) и резервируйте путь через Tor конкретно для административного доступа к шеллу, где скрытие соединения важнее скорости.

Ошибки, которые незаметно разрушают анонимность, которую вы пытались получить

Большинство сбоев здесь не экзотические — это небольшие пробелы в конфигурации, оставляющие приоткрытой боковую дверь. Обратите внимание на следующее, прежде чем доверять настройке:

Ни одно из этого не требует продвинутых инструментов, чтобы избежать, — нужно лишь один раз проверить фактически прослушиваемые порты и поведение DNS, а не полагаться на то, что одна лишь конфигурация Tor сделала всю работу.

sshd всё ещё привязан к публичному интерфейсу наряду с onion-сервисом, поэтому «скрытый» порт также находим обычным сканированием портов
Разрешение имён хостов вне Tor (случайный DNS-запрос или приложение, игнорирующее SOCKS-прокси для DNS) раскрывает, к какому хосту вы собираетесь подключиться, ещё до начала соединения через Tor
ProxyCommand, который молча откатывается к прямому соединению, если Tor не запущен, — настройте его на отказ по умолчанию, а не на пропуск, чтобы мёртвый демон Tor означал отсутствие соединения, а не случайное подключение через открытую сеть
Переиспользование SSH-ключа, приглашения терминала или истории шелла, которые привязывают эту сессию обратно к неанонимной личности где-то ещё

Сравнение методов доступа по SSH
Метод	Что скрывает	Типичная дополнительная задержка	Сложность настройки
Прямой SSH через открытую сеть	Ничего сверх собственного шифрования SSH	Отсутствует	Отсутствует
Клиент через SOCKS-прокси Tor	Ваш IP-адрес — от сервера и его логов	Умеренная — примерно одна цепочка Tor, ~300 мс-1 с	Низкая — torsocks или строка ProxyCommand
SSH, опубликованный как onion-сервис Tor	Публичный IP VPS; отсутствие открытого SSH-порта в интернете	От умеренной до высокой — добавляется цепочка на стороне сервера	Средняя — изменения в torrc и sshd_config
Комбинация обоих: клиент через Tor, сервер как onion-сервис	Оба конца соединения полностью остаются вне открытой сети	Самая высокая — две независимые трёхузловые цепочки	Средняя

Частые вопросы

Ослабляет ли SSH через Tor шифрование SSH?+

Нет. SSH согласовывает собственный сквозной зашифрованный канал независимо от транспорта, который его несёт. Tor добавляет поверх собственный слой шифрования цепочки, поэтому трафик шифруется дважды, а не один раз чем-то более слабым.

Слишком ли медленен SSH через Tor для реальной администрации?+

Для интерактивных сессий в шелле — редактирования файлов, просмотра логов, перезапуска служб — дополнительная задержка заметна, но приемлема. Для массовой передачи данных, например резервных копий или крупных загрузок, используйте вместо этого прямое соединение или WireGuard, а путь через Tor резервируйте для административного доступа.

Можно ли использовать fail2ban, если SSH доступен только через onion-сервис?+

Не осмысленно. Соединения приходят на sshd от локального процесса Tor, поэтому каждая попытка входа логируется как пришедшая с 127.0.0.1. Вместо этого полагайтесь на аутентификацию только по ключу без резервного пароля, поскольку это устраняет риск подбора, для смягчения которого предназначен fail2ban.

Нужен ли мне VPN в дополнение к Tor для доступа к VPS?+

Обычно нет. Добавление коммерческого VPN перед Tor в основном переносит доверие на провайдера VPN, не добавляя реальной защиты для этого случая. Один только Tor для SSH-сессии или туннель WireGuard, когда задержка важнее маршрутизации через сеть Tor, покрывает практические сценарии.

Нужно ли запускать Tor на обоих концах или только на моём ноутбуке?+

Достаточно, чтобы Tor работал только у вашего клиента, чтобы скрыть ваш IP от сервера (Способ 1). Чтобы скрыть и IP сервера, VPS также должен запускать Tor, с sshd, опубликованным как onion-сервис (Способ 2) — эти две настройки независимы и могут использоваться отдельно или вместе.

Готовы уйти в оффшор?

Без KYC, без почты — только анонимный ключ и крипта. Разворачивается за ~55 секунд.

Настроить VPS →