Учимся использовать SSH туннелирование для безопасного серфинга. Выбор типа туннеля Прокси-Сервер: прямой или обратный

От редактора AnswIT:

В данном примере, если бы портал или любой другой ресурс, к которому Алексу нужно получить доступ, находился на самом роутере (например, по адресу 192.168.0.1:80), то команда выглядела бы следующим образом:

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [email protected]

Если сервис доступен по адресу localhost (например, локальный SQL сервер), то и к нему
можно получить доступ:

alex@Alex-PC:~$ ssh -L
127.0.0.1:13306:127.0.0.1:3306 [email protected]

Конструкции вида -L 127.0.0.1:80:127.0.0.1:80 могут выглядеть, на первый взгляд, довольно странными. Но в них нет ничего сложного, если помнить, что решение о
маршрутизации пакета принимается на удалённой стороне туннеля. Нужно помнить основное правило: вторая пара
<адрес>:<порт> обрабатывается удалённой стороной туннеля .
Поэтому пакет с адресом назначения 127.0.0.1 в правиле трансляции будет обработан второй стороной SSH сессии, и никак иначе.

Как вы уже, наверное, догадались, точку входа в туннель можно создавать не только на loopback интерфейсе. Если туннель нужно сделать доступным не только для локального хоста, но и для других участников сети, то в качестве адреса сокета можно указать реальный адрес интерфейса.

alex@Alex-PC:~$ ssh -L
10.0.0.5:8080:192.0.0.2:80 [email protected]

Компьютер Алекса Alex-PC имеет два сетевых интерфейса с адресами 2.2.2.2 и 10.0.0.5. В процессе установления сессии ssh откроет сокет 10.0.0.5:8080 на компьютере Alex-PC. Теперь Алекс может получить доступ к порталу 192.168.0.2:80 со своего ноутбука с адресом 10.0.0.4 и со всей
своей домашней сети 10.0.0.0/24.

Обратный SSH-туннель — выставить свои ресурсы в интернет

Как я уже говорил, точку входа в туннель можно открывать не только со стороны оригинатора ssh сессии, но и с удалённой стороны, то есть с той, к которой мы устанавливаем ssh сессию. Для этого вместо параметра -L используется параметр -R. Для чего это нужно?
Например, для того, чтобы можно было опубликовать локальный сервис для удалённого доступа.

На ноутбуке Алекса запущен Web сервер apache доступный
по адресу 127.0.0.1 с тестовой копией портала компании. Алексу нужно дать доступ к Web серверу своим
коллегам для проведения тестирования интерфейса. Вообще, для подобных целей Алексу неплохо было бы реализовать более надёжную тестовую песочницу. Но так как наш Алекс не более чем виртуальный персонаж этой статьи, он для
демонстрации работы SSH туннеля устанавливает
сессию между своим ноутбуком и маршрутизатором Linux. А с помощью параметра -R открывает порт 8080 на
внутреннем интерфейсе маршрутизатора с адресом 192.168.0.1, который ссылается на сокет 127.0.0.1:80 его тестового Web сервера.

Как видите, на маршрутизаторе процесс sshd открыл локальный сокет 8080

alex@Router:~$
sudo lsof -nPi | grep 8080

sshd
17233 alex 9u IPv4
95930 0t0 TCP 192.168.0.1:8080 (LISTEN)

Давайте посмотрим, что произойдёт с TCP пакетом, отправленным с компьютера 192.168.0.200 в сторону тестового портала, опубликованного на 192.168.0.1:8080:
1. TCP пакет с адресом источника 192.168.0.200 и адресом и портом назначения 192.168.0.1:8080 попадёт в сокет 192.168.0.1:8080, открытый процессом sshd;

2. Процесс sshd, получив пакет, в соответствии с правилом трансляции перепишет адрес и порт назначения с 192.168.0.1:8080 на 127.0.0.1:80 и отправит его внутри SSH сессии стороне-оригинатору 2.2.2.2;

3. Процесс ssh на ноутбуке Алекса, получив пакет и просмотрев адрес его назначения, перепишет адрес отправителя с 192.168.0.200 на адрес своего loopback, и отправит его в локальный сокет 127.0.0.1:80, открытый процессом apache.

Как видите, правила трансляции очень простые. Хост, который открывает сокет для туннеля, занимается трансляцией адреса и порта назначения согласно правилу трансляции. Хост с противоположной стороны туннеля производит подмену адреса и порта источника согласно своей таблице маршрутизации. Таблица маршрутизации необходима, во-первых, для того чтобы отправить пакет в нужную сторону, а, во вторых, для того чтобы произвести
подмену адреса источника на адрес интерфейса, с которого будет отправлен пакет.
Одно важное замечание, которое я оставил на конец статьи.
Если при открытии точки входа в туннель используется localhost вместо адреса реального интерфейса, то его можно опустить, сократив, таким образом, команду с

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [email protected]

alex@Alex-PC:~ssh -L
8080:192.0.0.1:80 [email protected]

Эта важная особенность синтаксиса пригодится нам в следующем примере.

Двойное туннелирование

Давайте посмотрим на чуть более сложный пример. Пользователю SQL-Tester, находящемуся за NAT, нужно получить доступ к базе данных на SQL сервере, который тоже находится за NAT. SQL-Tester не может установить
соединение напрямую к серверу, так как в NAT серверной сети нет соответствующих трансляций. Однако от обоих хостов можно установить SSH сессию с промежуточным
сервером 3.3.3.3.

С SQL сервера устанавливаем SSH соединение с сервером 3.3.3.3 и открываем на loopback интерфейсе сервера
3.3.3.3 порт 13306, ссылающийся на локальный сервис SQL, запущенный на локальном сокете 127.0.0.1:3306 SQL сервера:

dbuser@SQL-server:~$ ssh -R 13306:127.0.0.1:3306
[email protected]

Теперь с клиентского хоста SQL-Tester устанавливаем соединение с 3.3.3.3 и открываем порт 3306 на loopback интерфейсе клиента, который, в свою очередь, ссылается на 127.0.0.1:13306 на сервере
3.3.3.3, который… ссылается на 127.0.0.1:3306 на SQL сервере. Всё просто J

tester@SQL-Tester:~$ ssh -L
3306:127.0.0.1:13306 [email protected]

Динамический туннель — SSH как Socks-прокси

В отличие от туннелей с явным указанием правил трансляции, динамический туннель работает совсем по другому принципу. Вместо указания однозначного сопоставления вида адрес:порт для каждого адреса и порта назначения, вы
открываете сокет на локальной стороне SSH сессии, который превращает ваш хост в прокси-сервер, работающий по протоколу SOCKS4/SOCKS5. Давайте разберем
пример:

Создаём сокет динамического туннеля 127.0.0.1:5555 на хосте client внутри сессии SSH к серверу 2.2.2.2

user@client:~$ ssh -D 5555 [email protected]

Проверяем, что порт открыт

user@client:~$ sudo lsof -nPi | grep 5555

ssh
7284 user 7u
IPv4 0x74fcb9e03a5ef5b1 0t0 TCP 127.0.0.1:5555 (LISTEN)

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

Теперь весь трафик браузера будет идти через SOCKS прокси внутри шифрованного соединения SSH
между хостами 1.1.1.1 и 2.2.2.2.

Как использовать SSH в Microsoft Windows?

Прочитав статью, вы возможно, решите, что все преимущества SSH туннелей доступны только
пользователям Unix-like систем. Однако это не так. Практически все для Windows работающие по протоколу SSH имеют поддержку туннелирования.

С некоторых пор, имеется возможность использовать Windows не только в качестве клиента SSH. Есть возможность .

В каких случаях использовать SSH-туннели?

Конечно же, для создания постоянных туннелей на боевых серверах нужно использовать специальное программное обеспечение. Но для быстрого решения задачи по пробросу портов, траблшутинга, получения быстрого удалённого доступа да и вообще решения конкретной задачи “здесь и сейчас” зачастую хорошим подспорьем будет использование SSH туннелей.

С их помощью можно выстраивать целые сети, туннели внутри туннелей, комбинировать типы туннелей. Это может позволять быстро получать доступ туда, куда, казалось бы попасть невозможно.

SSH -туннелирование может помочь не только в вопросах, когда необходимо передать не шифрованный трафик по шифрованному соединению, но и тогда, когда у вас закрыт доступ к ресурсу в сети, но доступ необходим.

Рассмотрим создание и настройку по нескольким вариантам.

И так, у нас имеется сервер, назовём его host-1 . К нему у нас есть полный доступ только по SSH — но нам необходимо открыть Tomcat , работающий на порту 8082 — к которому нас никак пропустить не могут.

Рассматривать вариант будем с настройкой Windows и Putty .

Открываем SSH -соединение к нужному серверу, логинимся.

Указываем такие параметры:

Source port: любой неиспользуемый порт в вашей системе;
Destination port: 127.0.0.1:8082

Жмём Add , потом Apply .

Переходим в настройки браузера, и устанавливаем параметры прокси:

Теперь остаётся в браузере открыть страницу http://localhost:3002 — и попадаем на страницу Tomcat на сервере host-1 .

Если туннель не работает — проверьте на сервере, включена ли пересылка пакетов. В файле /etc/ssh/sshd_config найдите и раскоментируйте строку:

AllowTcpForwarding yes

И перезапустие SSHd:

# service sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ]

Ещё один пример — у нас есть тот же внешний сервер, с которого есть нормальный доступ к любым ресурсам в Сети. А вот с рабочего места у нас доступ к и закрыт.

Выполняем похожие действия, но с небольшими отличиями. Настройки в Putty :

Source port — оставляем прежний, но вместо Local — выбираем Dynamic . Нажимаем Add , Apply .

Переходим к настройкам браузера:

Обратите внимание, что тип прокси тут не HTTP — а SOCKS .

Наслаждаемся доступом к любимым сайтам.

И более интересный случай.

Имеем прежний host-1 . Кроме него — второй сервер, назовём его host-2 . Кроме этого — у нас есть машина с Windows , которой необходимо предоставить доступ к ресурсу TeamCity на сервере host-1 на порту 8111. При этом — доступ с Windows -машины у нас есть только к серверу host-2 , и только на 22-ой порт.

Для начала — поднимаем туннель между host-1 и host-2 . Выполняем на host-1 :

$ ssh -f -N -R host-2:8082:localhost:8111 username@host-2

Так мы открываем туннель, который локально (на host-1 ) смотрит на порт 8111 , а с другой стороны — машина host-2 , на которой открывается порт 8082 , и ждёт входящих соединений. При получении пакетов на порт 8082 (при чём — только по интерфейсу lo0 ! это важно) — он будет их перенаправлять на машину host-1 порт 8111 .

Что касается интерфейса lo0 . При установлении SSH -туннеля, даже при указании внешнего IP машины — соединение поднимается только с localhost , т.е. 127.0.0.1 .

Посмотрим на host-2 :

$ netstat -anp | grep 8082 tcp 0 0 127.0.0.1:8082 0.0.0.0:* LISTEN -

Что бы изменить это — необходимо отредактировать файл конфигурации демона sshd — /etc/ssh/sshd_config и изменить параметр:

#GatewayPorts no

Но сейчас мы этого делать не будем, это просто заметка.

Продолжим. Переходим к настройке Putty на нашей Windows -машине. Тут всё просто — пользуемся примером 1 из этой статьи, только меняем порт на нужный (в скриншоте, кстати, он и есть). Подключаемся Putty к хосту host-2 , настраиваем tunnel . В браузере меняем настройки proxy — и получаем необходимое, указываем адрес http://localhost:3002:

SSH довольно чувствителен к потерям пакетов, поэтому туннели могут часто обрываться.

Что бы избежать этого — можно либо поиграться с параметрами в файле настроек sshd — /etc/ssh/sshd_config:

#TCPKeepAlive yes #ServerAliveInterval #ServerAliveCountMax

Либо — воспользоваться утилитой autossh.

SSH туннелирование пригодится для обхода неких ограничений установленных брандмауэром или же просто для создания безопасного туннеля передачи данных. Кроме прямого SSH туннелирования можно также сделать проброс данных с локального порта через SSH туннель на некий порт некой удалённой машины или наоборот.

Как в случае прямого SSH туннелирования так и с пробросом порта, на одной из сторон всегда должен быть установлен рабочий SSH сервер! SSH туннелирование даёт возможность бродить по сети от имени того компьютера, к которому был организован SSH туннель. Например если у нас имеется доступ к SSH где-то в Зимбабве, то при помощи SSH туннеля мы можем лазить по сети от имени Зимбабве:)

Прямое SSH туннелирование

Что имеется ввиду под "Прямое SSH туннелирование "? Прямое SSH туннелирование это когда SSH клиент запускается в режиме sock-proxy (опция -D ) и соединившись с удалённой машиной по SSH протоколу передает через неё (удалённую машину ) TCP трафик, например сессия прямого SSH туннеля с удалённой машиной через консольный SSH клиент (OpenSSH ) в Windows:

C:\OpenSSH\bin> ssh -D 4444 -p 28666 user@ remotehost.com The authenticity of host "remotehost.com (96.172.128.114)" cant be establishe d. RSA key fingerprint is 5e:ea:62 :5f:fc:3b:b2:38 :d6:ba:6b:aa:65 :3f:d4:35 . Are you sure you want to continue connecting (yes/ no) ? y Please type "yes" or "no" : yes Warning: Permanently added "remotehost.com,96.172.128.114" (RSA) to the list o f known hosts. user@ remotehost.com password: Last login: Thu Feb 7 03:34 :45 2013 from 108.95.46.202 [ user@ remotehost ~] $

Запуская SSH клиент с опцией -D 4444 мы повелеваем ему после запуска прослушивать локальный порт 4444 и после подключения к удалённому хосту remotehost.com, на удалённый порт -p 28666 и с именем пользователя user, отправлять наш TCP трафик к месту назначения от своего имени - т.е. от имени remotehost.com с ИП 96.172.128.114.

Проброс порта через SSH туннель на порт удалённой машины

В этом случае, после подключения по SSH протоколу с удалённой машиной [email protected], данные с локального порта через SSH туннель удаленной машины будут переданы будут переданы дальше на некий порт некой удалённой машины, например прокси-серверу. Выглядит это примерно так:

ssh -L [ bind_address:] port:host:hostport -p 28666 user@ remotehost.com

Аналогично предыдущему примеру с той лишь разницей, что конечной точкой пересылающей/принимающей наш TCP трафик будет не [email protected], а некий host:hostport

Есть также вариант проброса TCP трафик с удалённого порта удалённой машины [email protected] на локальный порт локальной машины или ещё куда-нибудь.

ssh -R [ bind_address:] port:host:hostport -p 28666 user@ remotehost.com

В консольных ssh клиентах для Unix подобных ОС есть ещё одна полезная опция -C (Requests compression of all data ) для сжатия данных, которая отсутствует в ssh клиенте (OpenSSH ) для Windows, но есть в PLINK.EXE от PuTTY .

В качестве SSHD для Windows можно предложить WinSSHD , а в качестве консольного SSH клиента под Windows OpenSSH соответственно или на худой конец PLINK.EXE от PuTTY .

SSH тунель в PuTTY

Для использования в PuTTY SSH туннелирования в настройках " Сonnection -> SSH -> Tunnels " введите:

Source port: 4444 Destination: localhost:4444

Отметьте пункт " Dynamic " и нажмите " Add ". В " Session " укажите нужное " Host Name " имя хоста, укажите SSH протокол и сохраните настройки выбрав в " Saved Sessions " подходящее имя, ну, например, " HostName aka ssh tunnel on 4444 " и сохраните " Save ", после чего двойным кликом на этом имени установите соединение.

Когда SSH-соединение будет установлено, мы сможем использовать свой браузер через локальны прокси на порту 4444. Зайдите на любую веб-страницу, где определяется ваш IP адрес и убедитесь в том, что определяется не ваш реальный IP адрес, а IP адрес удаленной машины.

Вложенные SSH туннели

Допускаются вложенные SSH туннели, например:

ssh -L [ bind_address:] port:host:hostport -p 28666 user@ remotehost1.com \ ssh -L [ bind_address:] port:host:hostport -p 28666 user@ remotehost2.com ssh -L 192.168.0.2:8080 :127.1 :9999 user@ 8.8.8.8 \ ssh -L 127.1 :9999 :127.1 :80 user2@ 10.1.1.2

В этом примере (рисунок ниже ) мы бросаем данные с порта 8080 компьютера "А" (192.168.0.2 ), на локальный хост и порт 9999 компьютера "Б" (8.8.8.8 ), а сразу после подключения к компьютеру "Б" (8.8.8.8 ) запускаем на нём ssh клиент, принимаем данные (127.1:9999 ) и бросаем их дальше на локальный хост 127.1:80 компьютера внутренней сети 10.1.1.2.

Реверс сокс-прокси. По идее офицеры службы безопасности, которые озабочены запретом Интернета на машине 10.1.1.2, должны повыдёргивать на попе все волосы, ибо приведённая ниже команда должна организовать доступ к сети Интернет для машины 10.1.1.2 через сокс-прокси, который запущен на машине «А».

ssh -D 8080 -R 127.1 :8080 :127.1 :8080 user@ 8.8.8.8 \ ssh -R 127.1 :8080 :127.1 :8080 user@ 10.1.1.2

Конфигурация SSHD

Для гарантированного обхода ограничений фаервола можно в конфигурации SSHD демона /etc/ssh/sshd_config открыть сразу несколько портов , т.е. SSHD будет принимать запросы сразу по нескольким портам, например.

Автор: Jayson Broughton
Дата публикации: 28 марта 2012 г.
Перевод: Алексей Жбанов
Дата перевода: 28 сентября 2012 г.

"Если мы видим свет в конце туннеля, то это свет приближающегося поезда" (Роберт Лоуэлл)

Ну да, еще одна неплохая цитата. Эта статья посвящена туннелям через SSH или, как мне больше нравится называть их, "VPN для бедных". Вопреки распространенному среди сисадминов мнению, эти туннели могут быть весьма полезны как для технических специалистов, так и для обычных пользователей. Я говорю "вопреки распространенному мнению", поскольку обратные туннели и туннели с HTTP-трафиком внутри могут обходить файерволы и фильтры содержимого. Но эта статья не о том, как нарушать корпоративную политику пользования Интернетом, она о том, как с помощью SSH-туннелей сделать свою жизнь чуть легче.

Итак, почему SSH-туннели вместо VPN? Вообще-то я использую дома и то, и другое. Если вы читали мои статьи на jaysonbroughton.com, то знаете, что я использую OpenVPN с трехступенчатой аутентификацией (логин, сертификат и одноразовый пароль). Но если я хочу проверить один из моих серверов из дома с помощью Android-устройства или компьютера, на котором у меня нет прав администратора (эти права нужны для моего OpenVPN-клиента) или же подключиться по VNC к ноутбуку моей супруги, чтобы решить ее проблему, то в этом случае я заменяю использование VPN на SSH.

Я дам здесь лишь самые основы: расскажу, как создавать туннели, объясню синтаксис команд, приведу примеры обратных туннелей и причины для использования каждого из них. Кратко коснусь файла ssh_config; более подробно он будет рассмотрен в будущем.

Итак, с чем мы будем работать? Я использую Debian в виртуальном окружении, поэтому ваши реалии могут отличаться от моих. В данном случае я использовал OpenSSH_5.3p1 в качестве сервера и различные OpenSSH-клиенты 5 версии. Перед тем, как углубиться в туннели, хочу сказать следующее: если вам хочется использовать SSH-туннели для шифрования HTTP или обратные SSH-туннели для обхода корпоративного файервола, удостоверьтесь, что вы не нарушаете никаких правил вашей компании. Нечего и говорить о том, что ваши системные администраторы начнут на вас охотиться, как только обнаружат такие проделки; сам будучи системным администратором, я получаю невыразимое удовольствие, отлавливая подобных индивидуумов. По крайней мере, предупредите их, чтобы они не были застигнуты врасплох. LinuxJournal.com и я не несут никакой ответственности за ваши нарушения вашей же корпоративной политики:-) Ну, а теперь перейдем к делу.

Создать SSH-туннель довольно просто. А вот решить, что с ним делать, может оказаться немного труднее. Поэтому я приведу несколько примеров, прежде чем мы вдадимся в детали. Я в свое время немного попутешествовал - это было на прежнем месте работы и до того, как у меня родились дети. В поездках мне доводилось останавливаться в самых странных гостиницах (думаю, вы с такими знакомы), оснащенных еще более странными беспроводными точками доступа. Захотите ли вы в гостинице подключиться к точке доступа, у которой SSID написан с орфографическими ошибками? Или в аэропорту, где вы обнаруживаете сразу несколько открытых точек? Если я нахожусь не дома, я пущу HTTP-трафик через туннель между своим устройством на Android (с root-доступом) и домашним сервером. Если же я работаю на ноутбуке, то открою SSH-туннель и пущу HTTP-трафик через Socks5 с тем, чтобы он весь был зашифрован средствами SSH. Я не доверяю открытым точкам доступа настолько, насколько могу. Что еще добавить? Мне приходилось "заворачивать" в туннели SMTP-трафик, когда я попадал в такие места, где блокировались исходящие SMTP-пакеты. То же самое мне приходилось делать и с POP3, с которого я недавно перешел на IMAPS. Другие примеры SSH-туннелей включают в себя проброс приложений X11 и сеансов VNC. Ранее я также упоминал обратные туннели. Они представляют собой... ну, вы сами понимаете - туннели, направленные в обратную сторону. В этом случае вы подключаетесь откуда-либо, где нет сервера SSH, к внешнему SSH-серверу. Потом, зарегистрировавшись на этом сервере, в том числе и локально, вы можете восстановить это подключение. Какая в этом польза, говорите? Ну, например, VPN-сервер вашей компании "упал" или работает только с VPN-клиентами под Windows, но вам совершенно не хочется тащиться с ноутбуком домой, чтобы проверить, работает ли тот или иной процесс. Придя домой, вы можете установить обратный туннель. В этом случае вам следует подключиться с сервера "Икс" к вашей домашней машине. Прибыв домой, вы восстанавливаете подключение к серверу "Икс", таким образом обходя файервол или VPN, и проверяете работу процесса без необходимости подключения по VPN. Я поступаю так очень редко, так как, на мой взгляд, подключение к серверу минуя файервол или VPN - это "плохое кунг-фу" и может использоваться лишь в самом крайнем случае.

Итак, вы получили несколько примеров SSH-туннелей, а теперь посмотрим, как это все делается.

Перед тем, как мы углубимся в работу на клиенте, немного отредактируем файл sshd_config на сервере. В /etc/ssh/sshd_config я обычно вношу некоторые изменения. Но не забудьте перед началом редактирования сделать его резервную копию на случай, если что-то пойдет наперекосяк.

Cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig # Используем протокол SSH версии 2 Protocol 2 # Включаем режим Privileged Separation для большей безопасности UsePrivilegeSeparation yes # Запрещаем вход от имени root PermitRootLogin no # Запрещаем пустые пароли PermitEmptyPasswords no # Включаем перенаправление X11 X11Forwarding yes X11DisplayOffset 10 # Терпеть не могу сообщений Motd PrintMotd no # Оно живее всех живых! TCPKeepAlive yes

Не забудьте, что если вы внесли какие-либо изменения в sshd_config, то вам нужно будет перезапустить сервис sshd для того, чтобы эти изменения вступили в силу.

А теперь перейдем к ключам. Нет-нет, не тем ключам, которые у вас отобрал папа, когда вы разбили мамину машину, а к ключам командной строки SSH.

Типичный SSH-туннель без перенаправления X выглядит примерно так:

Ssh -N -p 22 [email protected] -L 2110:localhost:110

Здесь ключи означают следующее:

N - не выполнять команд на удаленной машине
-p 22 - подключаться на внешний порт 22. Я обычно использую другой внешний порт, чтобы избавиться от атак "кулхацкеров" на мой SSH-сервер
[email protected] - имя_пользователя@имя_сервера (или IP-адрес)
-L 2110:localhost:110 - информация о привязке портов. Означает следующее: порт_клиента:имя_сервера:порт_сервера. В данном примере мы перенаправляем 110 порт сервера на 2110 порт вашей машины

Хотите еще немного примеров?

Проброс POP3 и SMTP через SSH:

Ssh -N -p 2022 [email protected] -L 2110:localhost:110 -L 2025:localhost:25

Проброс Google Talk через SSH (ключ -g позволяет удаленным машинам подключаться к проброшенным локальным портам):

Ssh -g -p 2022 -N [email protected] 5223:talk.google.com:5223

Практически все, что передается в виде простого текста, можно обезопасить с помощью SSH-туннелей

Шифрование HTTP-трафика

Еще одна вещь, понятная без лишних слов. Но если в вашей компании действует какая-либо политика относительно ИТ, проверьте, не нарушаете ли вы ее. Я пускаю HTTP-трафик через SSH в тех случаях, когда не доверяю точке доступа. Под Android я использую приложение SSHTunnel, а на ноутбуке - такую команду:

Ssh -D 5222 [email protected] -N

После подключения настройте свой браузер или другую программу, способную использовать прокси на адрес localhost:5222. Таким образом будет создан динамический проброс порта и весь трафик пойдет через SSH-сервер, одновременно шифруясь и обходя фильтрование по содержимому

Перенаправление сеансов X и VNC

Ssh -X -p 2022 [email protected]

Вы угадали, -X пробрасывает X. Но учтите, что это работает только на клиентских машинах с Linux. Если вы вдруг оказались вынуждены работать в Microsoft Windows, а вам нужен SSH-туннель, просто установите пакет Cygwin/X (http://x.cygwin.com/). Я лично не пробовал с ним работать, но, насколько я понимаю, он предоставляет возможность запускать удаленные X-приложения, находясь в Windows.

При пробросе сеансов VNC будьте внимательны. Если на клиенте, с котрого вы подключаете туннель, работает VNC-сервер, скажем, на порту 5900, удостоверьтесь, что вы не указали этот порт в качестве перенаправляемого, иначе вы подключитесь к самому себе. Вообще же VNC пробрасывается точно так же, как и любой другой сервис:

Ssh -p 2022 [email protected] -L 5900:localhost:5900

В данном примере вы подключаетесь по SSH на внешний порт 2022 сервера mylinuxserver.com от имени пользователя bob. Локальный порт 5900 пробрасывается на порт 5900 на сервере. После установления соединения вы можете открыть свой VNC-клиент и направить его на localhost:0 для подключения к удаленной машине. Если вы пробросили порт 5901, указывайте "localhost:1" и так далее.

Обратные SSH-туннели

Ну, вот и настало время для моей любимой разновидности SSH-туннелей. Разумеется, получать доступ к какому-либо сервису через SSH - это здорово, "гонять" веб-трафик по зашифрованным SSH-туннелям - тоже, но самое приятное удивление можно испытать от обратных туннелей. Как я уже говорил ранее, ими приходится пользоваться в ситуации, когда имеется машина без SSH-сервера, а вы испытываете необходимость получить к ней доступ в дальнейшем (через несколько минут, часов или дней), но при этом не хотите или не можете воспользоваться VPN. Вам следует соединиться с SSH-сервером с этой машины, а затем установить обратный SSH-туннель, подключившись к этому соединению. Для чего я это применяю? Время от времени - для того, чтобы поработать с удаленным сервером или просто для того, чтобы помочь друзьям и родственникам по VNC через SSH. В последнем случае они запускают Putty с сохраненными настройками сеанса и подключаются к моему SSH-серверу от имени пользователя, не имеющего никаких прав. После создания туннеля я могу зайти по VNC на их машины. И все, им не нужно настраивать файервол или разбираться с LogMeIn или другими подобными сайтами.

Итак, для создания обратного SSH-туннеля необходимо выполнить следущие действия:

На клиентской машине:

Ssh -R remoteport:localhost:22 username@servername

На стороне сервера:

Ssh -p 2048 localhost

И вот вам обратный туннель! Вуаля!

Для любителей наглядности пользователи daddoo и nerdboy4200 с канала #linuxjournal подготовили схему последовательностей сообщений с помощью пакета mscgen (http://www.mcternan.me.uk/mscgen/). Да, это пакет с открытым исходным кодом и он обладает потрясающими возможностями. Я попробовал свои силы и создал схему для этой заметки, но то, что за короткое время сделали daddoo и nerdboy, заставило меня устыдиться [своей неумелости - прим. пер.] .

Заключение

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

Помимо своей основной функции, протокол SSH предоставляет администратору массу полезных инструментов, в этой статье речь пойдёт о создании VPN-туннеля с помощью SSH .
SSH-туннелирование - самый простой и быстрый способ получить туннель к Linux-серверу, т.к. пакет OpenSSH на нём, скорее всего, уже установлен, к тому же, полученный туннель не будет иметь проблем с NAT.

Такой туннель является простым, но не является надёжным, т.к. использует TCP-соединение и не содержит встроенных механизмов для восстановления соединения после разрыва.
SSH-туннель лучше использовать для тестирования (например, если вам нужно передавать UDP-пакеты на удалённый сервер, проброс портов по SSH в этом случае не поможет), а для постоянных туннелей использовать протоколы, специально разработанные для этого, такие как OpenVPN, PPTP, L2TP, IPSec, GRE и т.д. (Все примеры команд в статье верны для CentOS 6)

Установка и настройка

Устанавливаем пакет OpenSSH из репозиториев, если он всё ещё не установлен:

yum install openssh openssh-server openssh-clients

Для того, чтобы сервер разрешал использование туннелей, нужно включить в файле настроек OpenSSH-сервера (обычно /etc/ssh/sshd_config) опцию PermitTunnel и перезапустить OpenSSH-сервер (service sshd restart).

PermitTunnel yes

В конце файла настроек сервера могут идти разделы настроек для определённых хостов, пользователей, групп пользователей и т.д.
Подобные разделы будут начинаться строками

Host ...
или
Match ...

Опцию PermitTunnel нужно добавлять до описанных разделов.

Использование SSH-туннелей

Для всех примеров будет использоваться OpenSSH-сервер доступный по адресу 192.168.1.100.

Простой SSH-туннель

Для создания самого простого SSH-туннеля можно выполнить команду

sudo ssh -w 7:7 -l root 192.168.1.100

За создание туннеля отвечает опция

W <номер_локального_интерфейса>:<номер_удалённого_интерфейса>

Вместо номера локального и/или удалённого интерфейса можно использовать значение «any», тогда будет создан следующий по порядку незанятый TUN-интерфейс.

После прохождения аутентификации sudo и SSH на локальном и на удалённом хостах должен появиться отключенный интерфейс tun7.

Для использования туннеля нужно включить интерфейсы и настроить на них IP-адреса из одной подсети, например, так:

# на локальном хосте
# на удалённом хосте

Теперь с локального хоста будет доступ на удалённый хост по адресу 10.255.255.1 через шифрованный туннель (при условии того, что файрволы локального и удалённого хостов пропустят эти соединения).

Большим недостатком данной схемы является необходимость доступа к удалённому серверу по SSH с правами суперпользователя (т.к. для создания TUN-интерфейса требуются права суперпользователя), при этом многие системные администраторы предпочитают запрещать root-доступ по SSH для большей безопасности. Устранение этого недостатка описано в следующем пункте.

SSH-туннель с правами непривилегированного пользователя

Для того, чтобы создать SSH-туннель с правами непривилегированного пользователя, нужно предварительно создать TUN-интерфейс, принадлежащий этому пользователю (для создание TUN-интерфейса в любом случае понадобятся права суперпользователя на удалённом хосте).
Для создания TUN-интерфейса в более старых дистрибутивах Linux используется инструмент tunctl (должен быть доступен из репозиториев дистрибутива), в более новых дистрибутивах этот функционал включен в пакет iproute2. Для определения того, каким способом нужно создавать TUN-интерфейс на вашем хосте, выполните команду

Если команда выдаст ошибку

Object "tuntap" is unknown, try "ip help".

Значит нужно использовать инструмент tunctl, предварительно установив его (yum install tunctl), в противном случае, команда должна выдать список TUN/TAP-интерфейсов на хосте.

Переходим к настройке .

Создаём непривилегированного пользователя на удалённом хосте:

useradd ssh_tunnel

Создаём TUN-интерфейс, принадлежащий этому пользователю

С помощью tunctl:

tunctl -n -t tun7 -u ssh_tunnel -g ssh_tunnel

С помощью iproute2:

ip tuntap add dev tun7 mode tun user ssh_tunnel group ssh_tunnel

Подключение SSH-туннеля выполняется аналогично предыдущему примеру:

# на локальном хосте
sudo ssh -w 7:7 -l ssh_tunnel 192.168.1.100
ifconfig tun7 up 10.255.255.2 pointopoint 10.255.255.1
# на удалённом хосте
ifconfig tun7 up 10.255.255.1 pointopoint 10.255.255.2

Создание пользователя только для SSH-туннелирования

В данном пункте будет рассмотрен запрет использования консоли непривилегированным пользователем в то время, как SSH-туннелирование для этого пользователя будет разрешено. Установить для пользователя оболочку «/bin/false» или «/sbin/nologin» не получится, т.к. в этом случае пользователь вообще не сможет установить SSH-соединение.

Для ввода описанных ограничений нужно добавить в конец файла настроек OpenSSH-сервера (/etc/ssh/sshd_config) указанные ниже строки и перезагрузить OpenSSH-сервер (service sshd restart)

Match User ssh_tunnel
X11Forwarding no
AllowTcpForwarding yes
AllowAgentForwarding no
GatewayPorts no
ForceCommand echo "This account can only be used for tunneling"; cat

Ограничение в этом примере вводится для созданного ранее пользователя ssh_tunnel. Параметр ForceCommand заставляет пользователя автоматически выполнять команду «echo "This account can only be used for tunneling"; cat» сразу после подключения. Это не даст пользователю использовать консоль нормальным образом, т.к., если убить процесс cat нажатием Ctrl+C, SSH-соединение будет разорвано.