Идея SSH на Linux

Копипаст с дополнениями.

SSH-туннель. Введение

Что это за зверь такой - SSH? Это аббревиатура означает "Secured Shell" - защищенная (безопасная) оболочка, если по-русски. Подробности можно прочитать в википедиях и прочих интернетах, но в двух словах - это защищенный протокол передачи данных, используется для удаленного управления компьютером и создания туннелей. Про последнее свойство я и хотел бы написать, т.к. с его помощью удаленный компьютер можно превратить в прокси-сервер, со всеми вытекающими.

Я буду писать команды для ОС на базе Linux и openssh. Пользователям Windows придется снести на хуй недоось-троян самостоятельно изучить аналог openssh — putty.

Покупка SSH-сервера

Есть три варианта покупки ssh-доступа:

1) купить у хакеров - дешево и большой выбор по странам, но это - самый ненадежный вариант, хосты часто дохнут, перепродаются или используются параллельно

2) хостинг-провайдеры - ну тут все понятно, покупаем VPS и делаем там, что хотим. Из минусов - один статический ip, обычно дороже других вариантов, больше остальных ебут мозг по поводу идентификационных данных и прочего деанона.

3) vpn-конторы - в последнее время стало модным включать на vpn-серверах ssh-туннелирование. Плюсы - относительно большой выбор стран, хороший аптайм, дешевле виртуальных серверов. Минусы - соседство с "серым" траффиком в лучшем случае может привлечь ненужное внимание, владельцы же таких контор зачастую весьма темные личности с неясными мотивами. Мне кажется это оптимальный вариант на "попробовать как оно ваще работает".

Пару слов о выборе страны для туннеля, при прочих равных. Для наибольшей анонимности выбирать нужно не ту страну, где "можно" заниматься тем, чем вы занимаетесь, а с наименьшим количеством точек соприкосновения между государствами. Чем напряженнее отношения, чем дальше страны находятся, чем больше различий в культурах, тем лучше. Если говорить конкретно про Россию, достаточно в новостях посмотреть, кто больше остальных ее ругает. Это мое мнение, никому не навязываю, может я не прав тут.

Собственно сам туннель, теория

Чтобы настроить локальный SOCKS5 прокси, необходимо в консоли набрать следующую команду:

ssh -D $port [email protected]$host

Параметр "-D" в данном примере говорит установить локальный прокси на порту $port, который в свою очередь выбирается произвольным образом из свободных в системе, но должен быть больше 1024 и меньше 65535. $user и $host - это данные имени пользователя и адреса сервера. После авторизации мы получаем полноценный прокси-сервер по адресу 127.0.0.1:$port

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

ssh -D 14880 [email protected]

мы получим SOCKS5 прокси по адресу 127.0.0.1:14880 в виде шифрованного туннеля до 8.8.8.8. Введя в настройках браузера SOCKS5 прокси 127.0.0.1:14880 мы получим наш внешний ip 8.8.8.8, причем в отличие от обычного SOCKS5 прокси, соединение до 8.8.8.8 будет зашифровано, то есть провайдер не увидит содержимое траффика.

Чтобы tor шел через наш прокси, нужно в конфиге torrc добавить строчку

Socks5Proxy 127.0.0.1:14880

После чего мы получим схему, известную как "VPN -> Tor".

Если же перед командой создания туннеля добавить torsocks или torify при работающем торе, то получим схему "Tor -> VPN" для всех приложений, использующих сокс-прокси на 127.0.0.1:14880:

torsocks ssh -D 14880 [email protected]

В общем-то, все готово для создания туннеля. Но тут самое время усложнить нам жизнь

Организация рабочего окружения

Можно организовывать туннель от того пользователя, от которого запущено графическое окружение. Но тогда этому пользователю необходим неограниченный доступ в сеть, что я считаю небезопасно.

Поэтому для начала создадим новую учетную запись (выполнять в консоли от root):

useradd -M -r -U -s /usr/bin/nologin --uid 1337 sshproxy

Здесь мы создаем т.н. системную учетную запись с id 1337 и одноименную группу. Параметр -M говорит не создавать домашнюю папку, можно и создать, но мне удобнее сделать по-другому: создать шифроконтейнер, в нем создать папку, к примеру sshproxy, и поменять владельца и разрешения папки:

chown sshproxy:sshproxy sshproxy

chmod 700 sshproxy

Далее, лучше всего запретить фаерволлом лезть куда не надо всем пользователям, кроме избранных. Нашему новому пользователю sshproxy необходим доступ, поэтому добавляем правило в iptables, в файле правил оно должно выглядеть примерно так:

-A OUTPUT -m owner --uid-owner 1337 -j ACCEPT

Безопасность соединения

Перед использованием туннеля необходимо обезопаситься от атаки типа человек-по-середине. После подключения к серверу и перед тем, как инициировать авторизацию, необходимо убедиться, что "разговариваем" мы именно с нужным нам сервером.

Для начала нужно сменить рабочую директорию на ту, которую мы создали в предыдущем шаге

cd /media/cryptocont/sshproxy

Теперь, поскольку окружение у нас нестандартное, нам необходимо передать дополнительный параметр ssh, -o "UserKnownHostsFile sshproxy_hosts". В итоге команды подключения и проверки хоста будут выглядеть так (помним, что нам надо подключаться от пользователя sshproxy и подставить верные значения удаленного пользователя и сервера):

sudo -u sshproxy ssh -o "UserKnownHostsFile sshproxy_hosts" [email protected]$host

Высветится примерно следующее сообщение:

The authenticity of host 'ip.ip.ip.ip' can't be established.
ECDSA key fingerprint is ff:aa:bb:cc:00:11:22:33:44:55:66:77:88:99:aa:bb.
Are you sure you want to continue connecting (yes/no)?

Жмем Ctrl-C, меняем внешний ip - перезапускаем tor или устанавливаем новую личность, опять соединяемся:

sudo -u sshproxy ssh -o "UserKnownHostsFile sshproxy_hosts" [email protected]$host

Опять Ctrl-C, меняем внешний ip - перезапускаем tor или устанавливаем новую личность, соединяемся:

sudo -u sshproxy ssh -o "UserKnownHostsFile sshproxy_hosts" [email protected]$host

Если отпечаток тот же во всех трех случаях - печатаем yes. Некоторые vpn-конторы предоставляют сразу отпечатки ключей, тогда вы сверяете то, что вам высветилось с тем, что вам дали при регистрации и если все нормально, пишете "yes". После "yes" данные о сервере запишутся в файл sshproxy_hosts, и нам больше не надо будет ничего сверять.

Для справки: часть "sudo -u sshproxy" говорит, что запускать ssh нужно от пользователя sshproxy.

Авторизация

После последнего "yes", нам предложат авторизоваться на сервер. Обычно авторизация бывает двух видов: по паролю и с помощью ключевого файла.
С паролем все понятно - когда нас просят, мы его вводим, и все, туннель готов к использованию.
С ключами же несколько сложнее. Ключ или выдадут, или его нужно будет генерировать на сервере (в интернетах расскажут, как). В общем, условимся, что он у нас есть в виде файла с названием sshproxy_key. Нам нужно положить его в нашу папку sshproxy, и максимально ограничить доступ к нему:

chown sshproxy:sshproxy sshproxy_key

chmod 400 sshproxy_key

После этого наша команда подключения к серверу преобразуется вот в такую:

sudo -u sshproxy ssh -o "UserKnownHostsFile sshproxy_hosts" -i sshproxy_key [email protected]$host

Ну вот и все. Теперь для создания туннеля необходимо от root проникнуть в директорию sshproxy и запустить команду создания туннеля с ключом или без него.
​

Homo homini lupus est