Ssh tunnel: SSH-туннели: практические примеры использования и важные функции

Содержание

Магия SSH / Хабр

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

Оглавление:

1) Local TCP forwarding
2) Remote TCP forwarding
3) TCP forwarding chain через несколько узлов
4) TCP forwarding ssh-соединения
5) SSH VPN Tunnel
6) Коротко о беспарольном доступе
7) Спасибо (ссылки)

1) Local TCP forwarding

Начнем с простого — local TCP forwarding:

Имеем удаленный сервер «host2» с неким приложением, допустим, PostgreSQL server, которое принимает TCP-соединения на порту 5432. При этом вполне логично, что на этом сервере стоит файрвол, который прямых соединений извне на порт 5432 не разрешает, но при этом есть доступ по SSH (по-умолчанию порт 22, рекомендую его изменить).

Требуется подключиться с нашего рабочего места «host1» клиентским приложением к серверу PostgreSQL на «host2».

Для этого на «host1» в консоли набираем:

host1# ssh -L 9999:localhost:5432 host2

Теперь на «host1» мы можем соединяться с PostgreSQL сервером через локальный порт 9999:

host1# psql -h localhost -p 9999 -U postgres

Если на «host1» Windows

Например, в PuTTy это делается так:
Идем по дереву настроек: Connection → SSH → Tunnels.
Далее в поле «Source port» вбиваем 9999, в «Destination» — localhost:5432, и нажимаем Add.
Не забываем после этого сохранить настройки сессии, если требуется.

Как это работает

После успешного подключения к SSH-серверу на «host2», на «host1» SSH-клиент начинает слушать порт 9999. При подключении к порту 9999 на «host1», SSH-сервер на «host2» устанавливает соединение с localhost (коим и является для себя самого «host2») на порт 5432 и передает по этому соединению данные, принятые ssh-клиентом на «host1» на порт 9999.
ВАЖНО! Все указанные на схемах стрелками соединения являются отдельными TCP-соединениями (сессиями).

Настройка SSH-сервера

Port forwarding, как правило, уже включен в настройках sshd по-умолчанию.
/etc/ssh/sshd_config:
AllowTcpForwarding yes

Мы также можем соединяться с приложением не на самом «host2», а на любой доступной ему машине:

Для этого при пробросе портов вместо «localhost» указываем имя хоста, например «host3»:

host1# ssh -L 9999:host3:5432 host2

Тут важно заметить, что «host3» должен быть известен (если это имя, а не IP-адрес) и доступен для машины «host2».

Также можно через «host1» предоставить доступ любому другому узлу (назовем его «host1A») к сервису на «host3»:

Для этого нужно вставить в команду соединения ssh IP-адрес интерфейса, на котором будет поднят локальный порт 9999:

ssh -L 0. 0.0.0:9999:host3:5432 host2

В данном примере порт 9999 будет открыт на всех доступных на «host1» IPv4 интерфейсах.

2) Remote TCP forwarding

Но что делать, если, например, «host2» не имеет белого IP-адреса, находится за NAT или вообще все входящие соединения к нему закрыты? Или, например, на «host2» стоит Windows и нет возможности поставить SSH-сервер?

Для этого случая есть Remote TCP forwarding:

Теперь нужно устанавливать ssh-соединение в обратном направлении — от «host2» к «host1». Т.е. наша административная рабочая станция будет SSH-сервером и будет доступна по SSH с «host2», а на «host2» нужно будет выполнить подключение SSH-клиентом:

ssh -R 9999:localhost:5432 host1

Если на «host2» Windows

Например, в PuTTy это делается так:
Идем по дереву настроек: Connection → SSH → Tunnels.
Далее в поле «Source port» вбиваем 9999, в «Destination» — localhost:5432, а ниже выбираем «Remote», и нажимаем Add.

Не забываем после этого сохранить настройки сессии, если требуется.

Как это работает

После успешного подключения, на «host1» SSH-сервер начинает слушать порт 9999. При подключении к порту 9999 на «host1», SSH-клиент на «host2» устанавливает соединение с localhost (коим и является для себя самого «host2») на порт 5432 и передает по этому соединению данные, принятые ssh-сервером на «host1» на порт 9999.

Также у вас возникнут дополнительные сложности с обеспечением безопасности на «host1», если вы не доверяете узлу «host2». Однако это выходит за рамки данной статьи.

И, конечно, вы каким-то образом (сами или с посторонней помощью) должны инициировать ssh-соединение со стороны «host2» вводом приведенной выше команды, а «host1» должен иметь белый IP-адрес и открытый порт SSH.

После установки ssh-соединения все работает аналогично предыдущей главе.

3) TCP forwarding chain через несколько узлов

В закрытых сетях часто бывает, что нужный нам узел напрямую недоступен. Т.е. мы можем зайти на нужный хост только по цепочке, например host1 → host2 → host3 → host4:
host1# ssh host2


host2# ssh host3

host3# ssh host4

host4# echo hello host4

Это может происходить например если эти узлы являются шлюзами, либо если на них доступны шлюзы только в соседние подсети.

В таком случае мы также можем делать TCP forwarding по цепочке:

Здесь порты 9991, 9992, 9993 выбраны для наглядности, на практике можно использовать один и тот же порт (например, 9999), если он свободен на всех узлах.

Итого нужно выполнить следующую цепочку команд:

host1# ssh -L 9991:localhost:9992 host2 host2# ssh -L 9992:localhost:9993 host3 host3# ssh -L 9993:localhost:5432 host4

Как это работает

После успешного выполнения перечисленных выше команд, на узлах выполняется следующее:

на «host1»: открывается порт 9991, при подключении к которому данные перенаправляются по ssh-соединению на порт 9992 на «host2»;
на «host2»: открывается порт 9992, при подключении к которому данные перенаправляются по ssh-соединению на порт 9993 на «host3»;
на «host3»: открывается порт 9993, при подключении к которому данные перенаправляются по ssh-соединению на порт 5432 на «host4»;

Таким образом, при соединении на порт 9991 на «host1», данные перенаправляются по цепочке на «host4» на порт 5432.

ВАЖНО! Все указанные на схемах стрелками соединения являются отдельными TCP-соединениями (сессиями).

4) TCP forwarding ssh-соединения

Иногда бывает нужно соединиться по ssh с сервером, который напрямую недоступен, а доступ возможен только по цепочке ssh-серверов (см. предыдущую главу). Теперь мы обладаем нужными знаниями чтобы сделать следующее:

host1# ssh -L 2222:localhost:2222 host2 host2# ssh -L 2222:host4:22 host3

Таким образом, на порту 2222 на «host1» у нас теперь есть форвардинг на порт SSH (22) на «host4». Можем соединиться:

host1# ssh -p 2222 localhost host4# echo hello host4

Казалось бы, зачем это нужно? Например, вот зачем:

# копируем файл на host4 host1# scp -P 2222 /local/path/to/some/file localhost:/path/on/host4 # копируем файл с host4 host1# scp -P 2222 localhost:/path/on/host4 /local/path/to/some/file # делаем еще один замечательный TCP forwarding на host4 host1# ssh -p 2222 -L 9999:localhost:5432 localhost host1# psql -h localhost -p 9999 -U postgres # обратите внимание, что порт для команды ssh задается ключем -p в нижнем регистре, # а для команды scp -P в верхнем регистре

Ну и вообще, здорово что теперь «host4» так близко 🙂

Вывод: можно делать TCP forwarding большого уровня вложенности.

Замечания про RSA fingerprint

В некоторых случаях scp не отработает, пока не зайдете сначала через ssh -p 2222 localhost и не примете RSA fingerprint удаленного сервера.

Если пользуетесь одним и тем же портом (2222) для доступа к разным удаленным серверам, то будут ошибки RSA fingerprint, который остался от предыдущего сервера. Его нужно будет удалить из ~/.ssh/known_hosts.

5) SSH VPN Tunnel

TCP port forwarding — это отличная возможность. Но что если нам нужно больше? Доступ по UDP, доступ к множеству портов и хостов, доступ к динамическим портам? Ответ очевиден — VPN. И всемогущий SSH начиная с версии 4.3 и здесь придет нам на помощь.

Забегая вперед скажу: этот функционал SSH хорошо работает если вам нужно временное решение для каких-то административных задач. Для построения постоянных VPN этот вариант далеко не самый подходящий, т. к. он предполагает TCP-over-TCP, что плохо скажется на скорости соединения.

Еще про TCP forwarding

А вот TCP port forwarding с помощью SSH, если его достаточно, во многих случаях выиграет по производительности у VPN, т. к. при TCP port forwarding передаются только данные приложения, а не исходные пакеты целиком вместе с заголовками, см. ссылку: http://blog.backslasher.net/ssh-openvpn-tunneling.html

Настройка SSH-сервера:
PermitTunnel в настройках sshd по-умолчанию выключен, его нужно включить в /etc/ssh/sshd_config:
PermitTunnel yes
или
PermitTunnel point-to-point

ВАЖНО: для поднятия нового сетевого интерфейса туннеля и на ssh-клиенте, и на ssh-сервере необходимы права суперпользователя. Можно долго спорить о том, насколько это небезопасно, но в большинстве случаев на ssh-сервере достаточно настройки:

PermitRootLogin without-password

Таким образом вы запрещаете вход root по паролю, а разрешаете только другими средствами, например, по ключу RSA, что гораздо безопаснее.

Перезапускаем sshd:
sudo service sshd restart # centos
или
/etc/init.d/ssh restart # (debian/ubuntu)

Туннель поднимается при использовании магического ключа -w:

host1# sudo ssh -w 5:5 root@host2

Где 5:5 — номер интерфейса на локальной машине и на удаленной соответственно. Здесь вас может смутить, что ifconfig не выдаст в списке интерфейса «tun5». Это потому что он в состоянии «down», а вот если вызвать «ifconfig -a» или «ifconfig tun5», то интерфейс будет виден:

host1# ifconfig tun5 tun5 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Назначаем интерфейсам IP-адреса и поднимаем их:

host1# sudo ifconfig tun5 192. 168.150.101/24 pointopoint 192.168.150.102 host2# sudo ifconfig tun5 192.168.150.102/24 pointopoint 192.168.150.101

Если есть файрвол, не забываем разрешить соединения с интерфейса tun5:

host1# # сохраняем исходные правила файрвола host1# sudo iptables-save > /tmp/iptables.rules.orig host1# sudo iptables -I INPUT 1 -i tun5 -j ACCEPT host2# # сохраняем исходные правила файрвола host2# sudo iptables-save > /tmp/iptables.rules.orig host2# sudo iptables -I INPUT 1 -i tun5 -j ACCEPT

На host1 это делать необязательно, здесь это сделано лишь для того чтобы ping работал в обе стороны.

Наслаждаемся пингом:

host1# ping 192.168.150.102 host2# ping 192.168.150.101

Если рассмотреть более ранний пример с PostgreSQL, то теперь схема будет такая:

А команда для подключения к серверу PostgreSQL будет выглядеть так:

host1# psql -h 192.168. 150.102 -U postgres

Ну а далее можно делать какой-либо из этих узлов шлюзом, если нужно обеспечить доступ не к одному узлу, а к сети. Например:

host2# # разрешаем IP forwarding host2# sudo sysctl -w net.ipv4.ip_forward=1 host2# # разрешаем IP forwarding с host1 host2# sudo iptables -I FORWARD 1 -s 192.168.150.101 -j ACCEPT host2# # разрешаем IP forwarding на host1 host2# sudo iptables -I FORWARD 1 -d 192.168.150.101 -j ACCEPT host2# # маскируем IP адрес host1 host2# sudo iptables -t nat -A POSTROUTING -s 192.168.150.101 -j MASQUERADE

host1# # Предположим, у host2 есть доступ к сети 192.168.2.x, куда нам нужно попасть с host1 host1# # Прописываем host2 как шлюз в сеть 192.168.2.x host1# sudo ip route add 192.168.2.0/24 via 192.168.150.2 host1# # Наслаждаемся доступом в сеть с host1 host1# ping 192.168.2.1

После окончания работы не забываем вернуть net. ipv4.ip_forward и файрвол в исходное состояние.

host1# sudo iptables-restore < /tmp/iptables.rules.orig host2# sudo iptables-restore < /tmp/iptables.rules.orig

Под спойлером более интересный случай с временным расшариванием Интернета

Допустим, нужно настроить сервер в закрытой сети, где доступ в Интернет запрещен, но тем не менее у вас туда есть лазейка — доступ через один ssh-сервер или цепочку ssh-серверов. Предположим, для настройки сервера вам нужен на нем доступ в Интернет. Тогда проще самостоятельно настроить временный доступ в Интернет на требующем настройки сервере, чем просить это сделать обслуживающий персонал.

Допустим, есть доступ по ssh с вашей рабочей машины host1 на сервер host2, с него — на host3, а уже оттуда — на нужный вам host4. Тогда делаем TCP forwarding для ssh (если с host1 вы сразу можете соединиться с host4, пропустите этот шаг):

host1# ssh -L 2222:localhost:2222 host2 host2# ssh -L 2222:host4:22 host3

Далее, соединяемся с host4 и поднимаем интерфейс tun5:

host1# sudo ssh -p 2222 -w 5:5 root@localhost host1# # или если host4 доступен сразу: sudo ssh -w 5:5 root@host4 host1# sudo ifconfig tun5 192. 168.150.101/24 pointopoint 192.168.150.102 host4# sudo ifconfig tun5 192.168.150.102/24 pointopoint 192.168.150.101

Смотрим таблицу маршрутизации на host4, допустим видим следующее:

host4# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0 tun5 192.168.56.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 0.0.0.0 192.168.56.254 0.0.0.0 UG 0 0 0 eth0

ВАЖНО! Далее нам скорее всего захочется сделать маршрутом по-умолчанию интерфейс tun5 со шлюзом 192.168.150.101, через который будет доступен Интернет. Поэтому на данном этапе важно точно знать, какие маршруты нужно дописать, чтобы заменить маршрут по-умолчанию. Это важно, поскольку довольно часто маршруты на отдельные сети не прописывают отдельно, а просто задают маршрут по-умолчанию (0.0.0.0/0) со шлюзом, через который и идет весь межсетевой трафик. Более того, вполне вероятно что ваше ssh-соединение с сервером также использует исходный шлюз по-умолчанию.

Для простоты в данном примере предположим, что никаких маршрутов кроме 192.168.56.0/24 серверу для нормального функционирования не нужно и что предыдущий ssh-хост host3 имеет IP-адрес из этой же сети.

Запоминаем и записываем куда-нибудь исходную маршрутную таблицу со шлюзом по-умолчанию:
host4# route -n > routes.orig

Настраиваем наш host1 для работы в качестве шлюза в Интернет для host4:

host1# # разрешаем IP forwarding host1# sudo sysctl -w net.ipv4.ip_forward=1 host1# # сохраняем исходные правила файрвола host1# sudo iptables-save > /tmp/iptables.rules.orig host1# # разрешаем IP forwarding с host4 host1# sudo iptables -I FORWARD 1 -s 192.168.150.102 -j ACCEPT host1# # разрешаем IP forwarding на host4 host1# sudo iptables -I FORWARD 1 -d 192.168.150.102 -j ACCEPT host1# # маскируем IP адрес host4 host1# sudo iptables -t nat -A POSTROUTING -s 192. 168.150.102 -j MASQUERADE

На всякий случай можно прописать серые сети на шлюз из текущего маршрута по-умолчанию

Если не прописаны:
sudo ip route add 192.168.0.0/16 via 192.168.56.254 sudo ip route add 10.0.0.0/8 via 192.168.56.254 sudo ip route add 172.16.0.0/12 via 192.168.56.254

Изменяем маршрут по-умолчанию на host4 (ОСТОРОЖНО, см. предупреждение выше!):

host4# sudo ip route replace default via 192.168.150.101 host4# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0 tun5 192.168.56.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 0.0.0.0 192.168.150.101 0.0.0.0 UG 0 0 0 tun5

Если весь Интернет нам не нужен, а только конкретные IP-адреса/маски, то можно маршрут по-умолчанию не менять, а дописать только нужные нам адреса через шлюз на tun5.

Проверяем, что есть Интернет:

host4# ping 8.8.8.8

Отлично. Осталось настроить DNS. Есть множество способов это сделать, проще всего отредактировать файл /etc/resolv.conf и добавить туда строчки:

nameserver 8.8.8.8 nameserver 8.8.4.4

После этого Интернет должен быть полностью доступен:

host4# ping ya.ru

После окончания работы не забываем вернуть все в исходное состояние:

host1# # восстанавливаем правила файрвола на host1 host1# sudo iptables-restore < /tmp/iptables.rules.orig host1# # не забудьте восстановить также значение net.ipv4.ip_forward

host2# # восстановите маршрут по-умолчанию на host4: host2# sudo ip route replace default via 192.168.56.254 host2# # и уберите добавленные ранее DNS-сервера из /etc/resolv.conf

6) Коротко о беспарольном доступе

Думаю, все уже знают что авторизация по паролю это не про нас. Но на всякий случай впихну сюда краткую инструкцию по настройке аутентификации по ключу RSA:

1. На клиентских машинах генерируем пользователю свой ключ RSA:

client1# ssh-keygen -t rsa

По-умолчанию приватный ключ сохраняется в ~/.ssh/id_rsa, а открытый — в ~/.ssh/id_rsa.pub. Приватный ключ храните как зеницу ока и никому не давайте, никуда не копируйте.
При создании ключа можно задать пароль (passphrase), которым ключ будет зашифрован.

2. Клиентские открытые ключи нужно сохранить на ssh-сервере в файле ~/.ssh/authorized_keys (~ это домашняя директория того пользователя, которым будете логиниться), каждый на отдельной строке. Для того чтобы это не делать вручную, на каждом клиенте можно воспользоваться командой:

ssh-copy-id user@sshserver

Где user — имя пользователя на сервере, sshserver — имя или IP-адрес ssh-сервера.

Права на файл ~/.ssh/authorized_keys

UPD от sabio: В случае ручного создания файла ~/. ssh/authorized_keys на ssh-сервере необходимо задать следующие права:
chmod 0700 ~/.ssh chmod 0600 ~/.ssh/authorized_keys

3. Проверьте, что можете зайти на сервер по ключу, без ввода пароля (не путать с passphrase):
ssh user@sshserver
Рекомендую не закрывать хотя бы одну активную ssh-сессию с сервером до тех пор, пока окончательно не закончите настройку и не убедитесь что все работает.

4. Отключите на SSH-сервере возможность входа по паролю в файле /etc/ssh/sshd_config:

PasswordAuthentication no

Возможность входа по открытому ключу обычно уже включена по-умолчанию:

PubkeyAuthentication yes

Я обычно также отключаю две следующие опции:

GSSAPIAuthentication no UseDNS no

В некоторых случаях это позволяет ускорить процесс соединения (например, когда на сервере нет доступа в Интернет).

5. Перезапустите sshd:
service sshd restart
или
/etc/init. d/ssh restart

В случае ошибок полезно бывает смотреть лог /var/log/secure либо использовать опции -v, -vv или -vvv для вывода детального лога соединения:
ssh -vvv user@sshserver

7) Спасибо (ссылки)

help.ubuntu.com/community/SSH_VPN
habrahabr.ru/post/87197
blog.backslasher.net/ssh-openvpn-tunneling.html

SSH-туннели: практические примеры и ключевые функции

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

Как устроены SSH-туннели

Туннель через SSH – стандарт, обеспечивающий безопасный удаленный доступ в систему и передачу файлов по защищённым сетям. Кроме того, он защищает трафик данных приложения за счёт переадресации портов, обычно это туннелирование произвольного порта TCP/IP через SSH. То есть трафик направляется на поток внутри зашифрованного SSH-соединения и не может быть перехвачен извне. SSH-туннелирование особенно актуально, если требуется обеспечить безопасность устаревших приложений, которые не поддерживают шифрование.

В рамках SSH-туннелирования устанавливается соединение между клиентом и сервером, оно зашифровывается и тем самым позволяет защитить конфиденциальность и целостность данных.

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

SSH-туннели применяются для:

Предоставления зашифрованных каналов для протоколов, использующих открытый текст
Открытия бэкдоров в частные сети
Обхода сетевых экранов

Создание и настройка SSH-туннеля

Переадресация портов SSH может осуществляться по трём типам:

Перенаправление локального порта. Соединение перенаправляется с клиентского хоста на SSH-сервер и впоследствии на порт хоста назначения.
Перенаправление удаленного порта. Соединение перенаправляется с хоста сервера на клиентский хост и впоследствии на порт хоста назначения.
Динамическая переадресация портов. В данном случае создается прокси-сервер SOCKS, который в свою очередь обеспечивает связь через ряд портов.

Переадресация локального порта

Перенаправление порта SSH-клиента (на локальном компьютере), на порт SSH-сервера (удаленного компьютера) и далее на порт, расположенный на конечном компьютере. Тот в свою очередь может являться удаленным SSH-сервером или каким-либо иным компьютером.

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

В Linux, MacOS и прочих юниксовых системах, для установки локальной переадресации портов нужно использовать следующую команду:


ssh -L [LOCAL_IP:]LOCAL_PORT:DESTINATION:DESTINATION_PORT [USER@]SSH_SERVER

Понадобятся такие параметры:

[LOCAL_IP:]LOCAL_PORT – IP-адрес и номер порта локального компьютера. Если локальный IP не указан, SSH-клиент привязывается к локальному хосту.

DESTINATION:DESTINATION_PORT – IP/имя хоста и порт машины назначения.

[USER@]SERVER_IP – Удаленный пользователь и IP-адрес сервера.

В качестве LOCAL_PORT вы можете использовать любой номер порта больше, чем 1024. Значения меньше 1024 являются привилегированными портами и могут использоваться только пользователем root. Если SSH-сервер прослушивает не 22-й порт, который стоит по умолчанию, используйте опцию -p [PORT_NUMBER].

Имя хоста назначения должно иметь разрешение с сервера SSH.

Переадресация удаленного порта

Перенаправление удаленного порта является противоположным случаю с портом локальным. Здесь можно перенаправить порт на удаленном компьютере (ssh-сервер) на порт локального компьютера (ssh-клиент), а затем на порт конечного компьютера.

Для перенаправления нужно:


ssh -R [REMOTE:]REMOTE_PORT:DESTINATION:DESTINATION_PORT [USER@]SSH_SERVER

Понадобятся такие параметры:

[REMOTE:]REMOTE_PORT – IP-адрес и номер порта удаленного SSH-сервера. Если значение REMOTE не выставлено, удаленный SSH-сервер свяжется сразу со всеми интерфейсами.

DESTINATION:DESTINATION_PORT – IP/имя хоста и порт машины назначения.

[USER@]SERVER_IP – Удаленный пользователь SSH и IP-адрес сервера.

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

Динамическая переадресация портов

Динамическая переадресация портов даёт возможность создать сокет на локальном компьютере (SSH-клиент), который выступает в качестве прокси-сервера SOCKS. Когда клиент подсоединяется к данному порту, соединение перенаправляется на удаленный компьютер(SSH-сервер), который далее идёт на динамический порт компьютера назначения.

Для создания переадресации динамического порта:


ssh -D [LOCAL_IP:]LOCAL_PORT [USER@]SSH_SERVER

Понадобятся такие параметры:

[LOCAL_IP:]LOCAL_PORT – IP-адрес и номер порта локального компьютера. Если LOCAL_IP не указан, SSH-клиент привязывается к localhost.

[USER@]SERVER_IP – Удаленный пользователь SSH и IP-адрес сервера.

Типовым примером динамической переадресации будет туннелирование трафика браузера через SSH-сервер.

Чтобы создать туннель SOCKS на порту 9090, нужно ввести следующую команду:


ssh -D 9090 -N -f [email protected]

После установки туннелирования можно настроить приложение для его применения. Перенаправление портов нужно настраивать отдельно для каждого приложения, траффик с которого вы хотите перенаправить по SSH-туннелю.

Настройка SSH-туннелирования в Windows

На Windows туннели SSH создаются с помощью клиента PuTTY. Запустите его и укажите IP-адрес SSH-сервера в поле Host name.

В разделе Connection разверните SSH и выберите Tunnels. Чтобы настроить локальную переадресацию, выберите Local, для удалённой – Remote и Dynamic для динамической переадресации портов.

При настройке локальной переадресации, введите локальный порт переадресации в поле Source Port field и хост назначения и IP-адрес в поле Destination, например, localhost:5901.
Для перенаправления удаленного порта введите порт перенапраaвления удаленного SSH-сервера в поле Source Port и целевой хост и IP-адрес в поле Destination, например localhost:3000.
При настройке динамического перенаправления введите в поле Source Port только локальный порт SOCKS.

Нажмите на кнопку Add

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

Практическое применения функций SSH-туннелей

Далее разберём, как можно использовать функции SSH.

Автоматизация копирования ключа SSH

Чтобы не копировать файлы вручную, можно автоматизировать этот процесс с помощью специальной команды. С её помощью можно копировать с вашей системы ключ по умолчанию ~/.ssh/id_rsa.pub в ~/.ssh/authorized_keys на удалённом сервере.

localhost:~$ ssh-copy-id user@remoteserver

Удалённое выполнение команд

Вы можете связать команду ssh с другими командам. Для этого вставьте название команды, которую нужно удалённо запустить, вместо последнего параметра в кавычках.

localhost:~$ ssh remoteserver "cat /var/log/nginx/access.log" | grep badstuff.php

Это позволяет выполнить grep на локальной системе после скачивания лога по ssh-каналу.

Копирование папки по SSH с локального сервера на удалённый

С помощью этой команды можно сжать папку в bzip2, а затем извлекает данные на удалённом компьютере за счёт создания там дубликата папки:


localhost:~$ tar -cvj /datafolder | ssh remoteserver "tar -xj -C /datafolder"

Редактирование текстовых файлов

Команда, которая понравится пользователям vim. Вы сможете редактировать файлы по scp всего одной командой. Файл создаётся локально в /tmp, а когда происходит его сохранение из vim, копируется обратно.

localhost:~$ vim scp://user@remoteserver//etc/hosts

Что лучше SSH или VPN

Всё зависит от целей и задач. В целом, оба варианта обеспечивают надёжное шифрование и защиту данных.

VPN сложнее в настройке, но проще в использовании, а SSH – наоборот.

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

vipnet

SSH-туннель: настройка и примеры | Soft-Setup

Использование SSH для создания туннеля — это самый простой и быстрый способ организовать защищенный шифрованный канал связи. Для организации такого туннеля потребуется один компьютер с SSH-сервером и другой с SSH-клиентом. Технология SSH есть практически на любом компьютере с операционной системой Linux. С некоторых пор Microsoft тоже внедрила SSH в свои операционные системы: сервер OpenSSH доступен на Windows Server 2019, а клиент на Windows 10.

Что такое SSH-туннель?
Если обратиться к справке SSH, то там SSH-туннель именуется как Port Forwarding (проброс портов). Такое название наиболее точно выражает суть данной технологии. SSH port forwarding позволяет послать TCP пакет с одной стороны SSH соединения на другую его сторону и произвести трансляцию заголовка по заранее определенному правилу в процессе передачи.

Особенности SSH-туннеля:

SSH работает на транспортном уровне, используя протокол TCP. Поэтому завернуть в SSH туннель UDP трафик или пингануть ICMP запросом удаленный хост не получится;
В отличии от VPN туннелей, где любой хост может инициировать сеанс, в ssh-туннеле необходимо явно задать «точку входа».

SSH-туннели не подойдут для организации полноценного VPN между двумя сетями так как они создают TCP-соединение, которое всего лишь транслирует адрес источника или назначения (пробрасывают порт) и не позволяет задействовать другие протоколы транспортного уровня (UDP, ICMP и пр.). Такое соединение не позволит взаимодействовать любому хосту одной сети с любым хостом другой сети.
Есть возможность обойти вышесказанные ограничения, путем создания программного сетевого интерфейса TUN, но здесь тоже есть свои недостатки. Об этом в конце статьи.

Содержание

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

1. Прямой SSH-туннель: подключаемся к серверу за NAT

Прямой ssh-туннель применяется для того, чтобы перенаправить соединение с заданным TCP-портом на локальном (клиентском) хосте на порт удаленного хоста (сервера). Всякий раз, когда устанавливается соединение с локальным портом или сокетом, соединение пересылается по защищенному каналу, и с удаленного компьютера устанавливается соединение либо с хост-портом, либо с сокетом Unix.

Представляйте этот туннель как проброс порта удаленного хоста через SSH на порт своего компьютера.

Практический пример:

Вам очень нужно подключится к корпоративному веб-сайту, но сделать это из сети интернет нет возможности так как на корпоративном роутере не проброшен через NAT 80 порт. Но на роутере есть ssh-сервер к которому можно подключиться из сети интернет.

Вы устанавливаете соединение SSH-сервером роутера (внешний ip 1.1.1.1), но перед логином с паролем передаете аргумент -L (local port) с правилами проброса порта (точка входа и трансляция). Например, точкой входа будет локальный порт вашего компьютера 8080, который будет транслироваться на 80 порт корпоративного веб сервера (ip 172.16.0.2).

ssh -L 127. 0.0.1:8080:172.16.0.2:80 [email protected]

После создания прямого ssh-туннеля вы сможете подключиться к недоступному через интернет корпоративному веб-сайту, который станет доступен по петлевому адресу и заданному порту http://127.0.0.1:8080.

Кстати, петлевой ip можно не указывать и сократить строку подключения до следующего вида:

ssh -L 8080:172.16.0.2:80 [email protected]

Как проходят пакеты по прямому ssh-туннелю:

На ssh-клиенте TCP-пакеты с адресом источника Src 127.0.0.1:65235 и адресом назначения Dst 127.0.0.1:8080 отправляются в сокет открытый процессом SSH 127.0.0.1:8080;
Процесс SSH переписывает адрес назначения tcp-пакета согласно заданного правила трансляции на 172.16.0.2:80 и отправляет на ssh-сервер роутера;
Процесс SSHD на роутере смотрит адрес назначение tcp-пакета и отправляет его на порт веб-сервера 172.16.0.2:80. При этом адрес источника Src 127.0.0.1:65235 роутер переписывает на свой 172.16.0.1:11505, чтобы веб сервер отправил ответный пакет роутеру, а не на свой локальный адрес 127. 0.0.1.

1.1 Прямой SSH-тунель с перенаправление на локальный порт SSH-сервера

Прямой туннель через ssh можно использовать для подключения к другому порту хоста, на котором установлен ssh-сервер. Например, у вас нет доступа к веб-интерфейсу роутера из сети интернет, но есть к порту ssh. Вы создаете ssh-сеанс с аргументом -L, а в качестве точки входа и адреса трансляции указываете сокеты соответственно 127.0.0.1:8080 и 127.0.0.1:88 (в реальности веб-интерфейсы используют порт 80).

ssh -L 127.0.0.1:8080:127.0.0.1:88 [email protected]

Таким образом веб-интерфейс роутера станет доступен на локальном сокете вашего компьютера по адресу http://127.0.0.1:8080.

1.2. Прямой SSH-туннель с предоставлением доступа другим участникам сети

Есть еще один весьма интересный способ создания прямого ssh-туннеля — это туннель с предоставление доступа другим участникам своей локальной сети. По сути, этот тот же прямой туннель, но в качестве точки входа указан не локальный адрес хоста, а его адрес в локальной сети — например, 192. 168.0.1.

ssh -L 192.168.0.1:8080:172.16.0.2:80 [email protected]

Таким образом любой участник локальной сети сможет подключиться на удаленный веб-ресурс через ssh-туннель по адресу http://192.168.0.1:8080.

Если для локальной точки входа указать адрес 0.0.0.0:8080, то доступ к туннелю можно будет получить из любой логической сети. Это может быть удобно в случае получения адреса от dhcp-сервера, так как избавляет от необходимости выяснять какой ip получен.

ssh -L 0.0.0.0:8080:172.16.0.2:80 [email protected]

2. Обратный SSH-туннель: выставляем ресурсы в Интернет

Обратный SSH-туннель применяется для того, чтобы на удаленном хосте (ssh-сервере) открыть сокет и перенаправлять соединения, устанавливаемые с этим сокетом, на порт локального хоста (ssh-клиента).

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

Практический пример:

Вы работаете дома, на удаленке, и завершили разработку веб-сайта. Коллеги с работы просят вас показать результат. Для этого вам нужно сделать так, чтобы 80 порт вашего веб-сервера стал доступен вашим коллегам.

Вы устанавливаете соединение с ssh-сервером корпоративного роутера (публичный ip 1.1.1.1) и задаете правило обратной трансляции с помощью аргумента -R (remote port). Затем указываете точку входа, находящуюся на удаленном хосте (ssh-cервере), 172.16.0.1:8080 и адрес трансляции на порт локального хоста (ssh-клиента) 127.0.0.1:

Что происходит с пакетом отправленным по обратному SSH-туннелю:

1. Источник с адресом 192.168.0.200 отправляет пакет с адресом назначения 192.168.0.1:8080, который поступив на ssh-сервер попадает в сокет, открытый процессом sshd;

2. Процесс sshd переписывает адрес и порт назначения с 192.168.0.1:8080 на 127.0.0.1:80 и отправляет и отправляет его по SSH туннелю стороне инициатору сеанса;

3. На хосте процесс ssh смотрит адрес назначения полученного пакета и переписывает адрес отправителя с 192. 168.0.200 на адрес своего loopback, затем отправляет его в локальный сокет 127.0.0.1:80, открытый процессом веб-сервера.

3. Динамический SSH-туннель: создаем SOCKS-прокси

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

Практическое применение:

Вы находитесь в кафе и подключились к публичной сети wi-fi, а доступ к ресурсу в интернете заблокирован владельцем точки wi-fi или провайдером. Чтобы обойти эти ограничение нужно создать динамический ssh-туннель до своего хоста с публичным ip-адресом.

ssh -D 8888 [email protected]

После создания туннеля необходимо указать адрес прокси сервера в настройках операционной. Подробно об этом можете прочесть в статье «Как настроить параметры прокси в Windows 10»

4. SSH-туннель Layer 3 (сетевой уровень): туннелируем udp-трафик

В начале статьи было сказано о том, что ssh-туннель базируется на транспортном протоколе tcp и поэтому отправить в такой туннель udp-трафик не получится. Однако в операционных системах семейства Linux есть возможность создавать tun-интерфейсы, которые работают на сетевом уровне модели OSI и оперируют ip-пакетами.

В организации ssh-туннеля с помощью tun-интерфейсов есть один серьезный недостаток — авторизация на ssh-сервере должна происходить под учетной записью root. Это создает уязвимость вашей компьютерной сети т.к. пароль root будет передаваться через открытую сеть Интернет.

Такой туннель, который создается с помощью учетной записи root, лучше не использовать на постоянной основе, а только в случае крайней необходимости. При этом необходимо использовать следующие методы, уменьшающие шансы раскрытия пароля root:

Использовать для root довольно сложный пароль на подобии хэша md5;
Или настроить авторизацию по ключам.

Для создания туннеля необходимо в конфигурационном файле OpenSSH разрешить туннелирование. Добавьте в файл /etc/ssh/ssh_config следующую строку:

PermitTunnel point-to-point

Для того чтобы можно было использовать парольную авторизацию root:

PermitRootLogin yes

Для подключения к ssh-серверу и создания туннеля через tun-интерфейсы используется следующая команда:

sudo ssh root@3. 3.3.3 -w 0:0

Аргумент -w создает интерфейсы tun0 на клиенте и сервере.

Затем необходимо настроить ip адреса tun интерфейсов и добавить необходимые маршруты.

На клиенте:

ifconfig tun0 10.0.0.2/30 pointopoint 10.0.0.1
ip route add 172.16.0.0/24 via 10.0.0.1

На сервере:

ifconfig tun0 10.0.0.1/30 pointopoint 10.0.0.2
ip route add 192.168.0.0/24 via 10.0.0.1

Туннели с tun-интерфейсами работают на 3 уровне модели OSI, а значит должны пропускать ICMP и UDP трафик. Поэтому проверку работоспособности туннеля можно выполнить, послав icmp-запрос на какой-либо хост из удаленной сети: ping 172.16.0.100.

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

‎App Store: SSH Tunnel — и SOCK5 прокси

Описание

Лучший инструмент для перенаправления портов SSH. Встроенный SOCKS5, URL-адрес файла PAC, 2FA OTP (Google Authenticator, Yubikey), ECDSA, ed25519, RSA, PuTTY

SSH Tunnel — это лучший и самый удобный способ управления SSH-туннелями на мобильном устройстве под управлением iOS.

Приложение позволяет вам настроить локальный прокси socks5 с частным туннелем к вашему собственному серверу.

Основные функции и особенности приложения:

— Переадресация локального порта (работает аналогично: «ssh -L 80: intra.example.com: 80 gw.example.com»)
— Динамическая переадресация портов (прокси SOCKS5)
— Пароль, приватный ключ, аутентификация 2FA (OTP)
— Поддерживаемые SSH-ключи: ECDSA, ed25519, RSA, PuTTY.
— Функция проверки отпечатков пальцев Host Key
— Статистика передачи данных подключения
— Экспорт и импорт подключений (iCloud Drive и другие сервисы)
— Защита паролем и идентификацией лица
— Предоставляет локальный URL-адрес для файла автоматической настройки прокси (PAC) (для автоматической настройки прокси-сервера WiFi)
— Таймер отключения на холостом ходу
— Расширенные возможности ведения журнала для отладки
— Добавить бесплатное приложение

Вам необходимо настроить SSH-сервер для использования этого приложения.

Преимущество SSH Tunnel — возможность полностью контролировать перенаправление трафика. Приложение позволяет вручную настраивать файл PAC (Proxy Auto-Config) с использованием специальных правил. Например, перенаправление в зависимости от сети Wi-Fi, к которой подключен телефон (домашний / рабочий), времени суток или адреса самого запрашиваемого ресурса.

Электронная почта поддержки SSH Tunnel: [email protected]

20 сент. 2020 г.

Версия 2.1.0

Настройка URL-адреса для встроенного браузера в приложении.
Улучшение совместимости с iOS 14.

Оценки и отзывы

Оценок: 13

Can’t reopen a connection without restarting my iPad

Whenever a connection closes abruptly, I can’t reopen it, because the local port remains busy. On a mac/linux machine the typical workaround is to find the dead connection using `ps aux | grep ssh` and kill the hanging ssh process, but here I have to restart the iPad or wait for the system to kill the process.
Update:
I’ve raised the score to 4 stars, because this seems to be the only app capable of maintaining an SSH tunnel in the background (almost?) indefinitely, as long as the internet connection is stable. I would’ve given it 5 starts if it were not for the aforementioned issue.

Thank you for the message, it’s a known issue, I’m working on it.
If you use this app for Dynamic port forwarding, as a workaround, you can specify ”0” in a Port field.
I apologize for this issue. Yury.

Не работает в фоне

Это «замечательное» приложение не умеет работать в фоне, что сводит его полезность к 0. Ах да, разработчик об этом «забыл» предупредить.

Hello,
It’s just not possible to maintain a background activity for such kind of apps.
But you have the options:
— Use the app with Split View on iPad
— Use an in-app browser (click globe button on the active connection page) to keep the app running in the foreground on iPhone (available since 2.0.1)
— You can use multiple iOS devices, setup Port Forwarding proxy on one and use it on another
/ Thanks, Yury

Great App Support & Quality App

I had an issue with ed25519 ssh keys so I raised a support request and I was surprised by the outcome:
— acknowledgement time was short
— resolution option was provided early
— Dev team stayed in touch for the whole time
— Dev team fixed the issue and contacted me on another option that was joining beta test program to get fixed build early
Thanks a million for Enterprise-grade Support and for treating all of your customers generously

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

Не связанные с пользователем данные

Может вестись сбор следующих данных, которые не связаны с личностью пользователя:

Данные об использовании
Диагностика

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

Информация

Провайдер: Mobibean, LLC
Размер: 39,1 МБ
Категория: Утилиты
Возраст: 4+
Copyright: © Yury Bushev
Цена: 749,00 ₽

Сайт разработчика
Поддержка приложения
Политика конфиденциальности

Поддерживается

Другие приложения этого разработчика

Как работает SSH-туннелирование

Posted by: admin октября 17th, 2017

SSH туннель или SSH Port Forwarding, как его называет man(1) ssh – это опциональный функционал протокола, который работает поверх всем знакомой обычной SSH сессии. SSH туннель позволяет послать TCP пакет с одной стороны SSH соединения на другую его сторону и произвести трансляцию IP заголовка по заранее определенному правилу в процессе передачи.

Понять, как работает SSH туннель очень просто: если представить его в виде point-to-point соединения. Так же как и в PPP, любой пакет, попавший в один конец соединения, будет передан и получен на другом конце туннеля. Дальше, в зависимости от адреса получателя заданного в IP заголовке, пакет будет либо обработан принимающей стороной туннеля (если пакет предназначается непосредственно ей), либо смаршрутизирован дальше в сеть (если адресатом является другой узел сети).

Основное отличие SSH туннеля от PPP соединения в том, что в SSH туннель можно завернуть только TCP трафик. (Примечание: есть несколько хаков, как можно передать UDP через TCP-сокет внутри SSH туннеля, но это решение выходит за рамки данной статьи).

Второе отличие состоит в том, что в point-to-point соединении входящий трафик может быть инициирован с любой стороны, тогда как для SSH туннеля необходимо явно задать «точку входа» для трафика. «Точка входа» – это параметр вида <адрес>:<порт>, указывающий какой сокет открыть для входа в туннель (с локальной или удалённой стороны SSH сессии).

Кроме точки входа дополнительно нужно указать правило вида <адрес>:<порт>, по которому должен быть переписан заголовок (точнее, адрес и порт назначения) TCP пакета в процессе передачи. Точка входа может задаваться с любого конца туннеля. За этот параметр отвечают ключи –L (local) и –R (remote). Под local и remote подразумеваются стороны туннеля с точки зрения стороны-оригинатора, то есть того хоста, который устанавливает SSH сессию.

Пока выглядит немного запутанно, поэтому давайте разберём на конкретном примере.

Прямой туннель SSH — обеспечиваем доступ к серверу за NAT

Алекс работает системным администратором в маленькой компании Qwerty Cakes, занимающейся производством яблочных пирогов. Вся сеть компании находится в одном броадкаст домене 192.168.0.0/24. Для доступа в интернет используется программный маршрутизатор на базе Linux, адрес которого 192. 168.0.1 со стороны сети компании и 1.1.1.1 со стороны сети Интернет. На маршрутизаторе поднят и работает демон OpenSSD, который доступен по сокету 1.1.1.1:22. Внутри сети на сервере с адресом 192.168.0.2 установлен внутренний корпоративный портал, на котором до завтрашнего утра Алексу нужно сделать изменения через Web интерфейс. Однако Алекс не хочет задерживаться на работе допоздна, он хочет получить доступ к порталу из дома со своего домашнего компьютера с адресом 2.2.2.2.

Алекс приходит домой и после ужина устанавливает следующее соединение с маршрутизатором компании:

Что произошло? Алекс установил SSH сессию между адресами 2.2.2.2 и 1.1.1.1, при этом открыв локальную «точку входа» в туннель 127.0.0.1:8080 на своем домашнем компьютере:

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

ssh 3153 alex 4u IPv4 9862 0t0 TCP 27.0.0.1:8080 (LISTEN)

Любой TCP пакет, который попадёт в сокет 127.0.0.1:8080 со стороны компьютера Алекса, будет отправлен по point-to-point соединению внутри сессии SSH, при этом адрес назначения в TCP заголовке будет перезаписан с 127. 0.0.1 на 192.168.0.2, а порт с 8080 на 80.

Теперь Алексу, чтобы попасть на портал своей компании, нужно всего лишь набрать в браузере:

Как проходят сетевые пакеты внутри SSH-туннеля

Давайте детально разберём, что произошло с TCP пакетом в процессе его прохождения по SSH туннелю:

1. TCP пакет с адресом источника 127.0.0.1 и адресом и портом назначения 127.0.0.1:8080 попал в сокет 127.0.0.1:8080, открытый процессом ssh;

2. Процесс ssh получил пакет, в соответствии с правилом трансляции переписал адрес и порт назначения на 192.168.0.2:80 и отправил его внутри SSH сессии удалённой стороне 1.1.1.1;

3. Процесс sshd на маршрутизаторе 1.1.1.1 получил пакет и, просмотрев адрес назначения, отправил его хосту 192.168.0.2, переписав при этом адрес источника с 127.0.0.1 на адрес собственного интерфейса 192.168.0.1, для того чтобы получатель, который ничего не знает про существование SSH туннеля, вернул пакет роутеру, а не отправил в свой же localhost 127. 0.0.1.

alex@Alex-PC:~$ ssh -L

127.0.0.1:8080:192.0.0.2:80 [email protected]

В данном примере, если бы портал или любой другой ресурс, к которому Алексу нужно получить доступ, находился на самом роутере (например, по адресу 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 сервере. Всё просто.

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-сервер на Windows.

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

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

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

Рубль

Please enable JavaScript to view the comments powered by Disqus.blog comments powered by Disqus

<<Previous

Next>>

SSH Туннели — примеры | Fullstack не просто так

У данного поста есть видео-версия: youtu.be/GBx3KEcuKFA

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

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

Первое знакомство с туннелями

Мое первое знакомство с туннелями произошло при моей попытке развернуть разработанный проект на сервере клиента. Я приехал к заказчику в офис, заранее сохранив в заметки ссылки на наши репозитории, названия докер образов и тд.

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

Я с ужасом представил, как я буду руками вбивать каждую ссылку для репозитория и понял, что на это все уйдет ни один час.

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

Решив эту задачу я стал изучать другие, более упрощенные способы, решения этой задачи. Так я познакомился с туннелями.

Основная идея туннелей

В целом суть туннеля наглядно изображена на анимации выше. Но дополню текстом:

У вас есть сервер, к которому вы хотите получить доступ, но не можете ходить на него напрямую. Назовем его сервер 1;
Между вами и целевым сервером есть сервер, который имеет доступ к целевому и к которому имеете SSH доступ вы. Назовем его сервер 2;
Вы можете зайти по SSH на сервер 2 и, через консоль, уже отправлять любые запрос на сервер 1. Также вы можете зайти по SSH на сервер 1 и двигаться дальше.

Примерно так и работает SSH-туннели. Только нам не всегда обязательно заходить на один сервер и с него уже слать запросы на следующий. Для упрощения этого процесса мы можем воспользоваться переадресацией портов (Port Forwarding).

Port forwarding на пальцах

У меня ушло какое-то количество мыслетоплива, чтобы понять суть работы переадресации портов.

Расширим ситуацию, описанную выше:

У нас есть сервер S1, к которому у нас есть доступ на любой порт;
Есть сервер S2, к 80 порту которого хотим получить доступ мы через наш S1;
Мы одной командой можем открыть на S1 80 порт, чтобы он пересылал эти запросы на 80 порт S2 и потом передавал нам ответ;
Также, например, одной командой, мы можем открыть 81 порт, который будет переадресовывать запрос на 80 порт другого сервера S3.

Именно эта «пересылка» портов и называется переадресацией портов или Port Forwarding. Теперь давайте перейдем к реальным кейсам использования туннелей.

Кейс с nginx

Рассмотрим простой кейс. У нас есть сервер, который закрыт миру, но мы имеем к нему SSH доступ. На этом сервере запущен сервер nginx, который слушает 80 порт.

Для того, чтобы получить доступ к тому, что опубликовано на 80 порту сервера, мы можем открыть туннель, который подключится к серверу, и опубликовать на локальном 80 порту. То есть, мы будем стучаться на localhost:80 и видеть ровно то, что опубликовано на 80 порту удаленного сервера. Для этого вводим следующую команду:

ssh -L 80:127.0.0.1:80 remote.server.address

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

Первым параметром идет флаг «-L» который указывает на то, что нам необходимо открыть туннель и начать слушать порт
Далее указываем интерфейс на котором мы хотим слушать (по-умолчанию localhost и в рамках данного примера он не указан). В нашем случае указываем порт 80 (на рис. «локальный порт»).
Далее указываем куда надо будет подключаться на удаленном сервере. В нашем примере 127.0.0.1, что значит, что туннель будет пробрасывать на сам же удаленный сервер. На что можно заменять это значение можно прочитать ниже.
Порт на удаленном сервере — в нашем случае это 80. Если бы nginx, например, видел бы на 8080, то мы бы указали 8080 в этом месте.
Адрес удаленного сервера. Указываем его тем же самым образом, что и при обычном подключении к SSH.

Теперь можно переходить на localhost в браузере и видеть то, что на сервере на 80 порту. В моем примере можно увидеть только ошибку nginx, которую выдает nginx-proxy на сервере

Кейс с базой данных Postgres в докере

Теперь к еще одному полезному кейсу, с которым мы сталкиваемся во время разработки, так или иначе, регулярно.

Есть я и мой ноутбук
На ноутбуке есть код моего backend приложения
В основном я работаю с локальной копией базы данных во время разработки
Мне надо подключиться к базе данных, которая находится на сервере (тестовом или боевом) в изолированной сети Docker

Когда мы говорим про работу через IDE для работы с БД, мы можем легко воспользоваться встроенным механизмом туннелей (инструкция тут). Но трудности возникать если мы хотим из кода нашего приложения подключиться к этой базе.

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

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

ssh -L 5432:postgres-db:5432

Тут ситуация аналогична предыдущей. Только вместо локального ip адреса самого сервера мы указываем ip адрес (в данном случае имя хоста postgres-db) в качестве целевого адреса.

В случае работы с Docker я использую этот контейнер, чтобы знать адреса всех контейнеров на сервере. После запуска имя хоста каждого контейнера можно получить в файле /etc/hosts. И после перезапуска ip адрес меняется, а хост остается

Дальше я уже могу указывать localhost:5432 в качестве сервера postgres в моем приложении и подключусь уже напрямую к базе данных в docker контейнере на том сервере.

Таких туннелей можно запускать сколько угодно. Все запускаются по аналогии. Например можно построить такую схему:

Есть сервера S1, S2, S3.
S1 имеет доступ к S2 и S2
Я имею доступ только к S1 через SSH на 22 порту
На серверах S2 и S3 запущены Postgres на 5432 и HTTP на 80 портах соответственно.
Я запускаю 2 туннеля и работаю с этими серверами как будто с локальными. Команды для запуска туннелей ниже:

ssh -p 22 -l 5432:s2:5432 s1
ssh -p 22 -l 80:s3:80 s1

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

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

Я работаю на своем ноутбуке и у меня крутится копия сайта клиента на 3000 порту
Нахожусь при этом в кафе с бесплатным wifi
Клиент находится у себя в офисе в закрытой сети
Я хочу показать текущую версию сайта клиента прямо со своего ноутбука
И я и клиент имеем доступ к одному серверу во внешней сети (например мой VPS)

Да, именно для такого кейса уже есть готовые решения — localtunnel или ngrok. Я сам ими пользуюсь, когда надо быстренько поднять и показать.

Для решения этого вопроса нам как раз может помочь обратный туннель (Reverse port forwarding). Чтобы клиент мог видеть сайт на своем ПК, мне необходимо запустить следующую команду:

ssh -R 0.0.0.0:3001:127.0.0.1:3000 server.ru

Давайте разберемся с каждым параметром в этой команде:

Справа налево:

Адрес сервера, который доступен и мне и клиенту
Локальный адрес и порт, который я хочу сделать доступным (localhost:3000)
Адрес и порт на общем сервере, на котором будет отображаться мой сайт с 3000 порту
Флаг, передающий SSH серверу, что я намерен открыть обратный туннель на мой локальный порт

Клиент, после запуска такого туннеля, может видеть наш сайт по адресу server.ru:3001.

Правда сделать это может быть чуть сложнее чем «просто вбить одну команду». Дело в том, что «из коробки» sshd демон не допускает подключения на внешний интерфейс.

Другими словами — то, что мы указали «0.0.0.0» как адрес для прослушивания, говорит серверу следующее: «принимай любые соединения на любой интерфейс на порт 3001, даже если запрос идет извне». Но эта настройка, обычно, выключена. Для того, чтобы внешние соединения заработали необходимо в файле /etc/ssh/sshd_config добавить строчку GatewayPorts yes

Стоит быть крайне внимательным и аккуратным с этой настройкой. Ставя её в значение yes вы открываете порт всему миру и это может стать прекрасной дырой в безопасности для злоумышленников. ВСЕГДА ЗАКРЫВАЙТЕ ТУННЕЛИ после завершения работы через них.

Для чего еще можно использовать обратный туннель

Я использовал обратные туннели, также, при отладке проектов на PHP. В случае, когда код расположен на удаленном сервере и мы работаем с кодом через SFTP, бывает необходимость отладить код, который запущен на сервере, но через локальный XDebug. Тут на помощь также приходит SSH туннель, который запускается и дает доступ удаленному серверу к нашему ПК.

Вместо заключения

На этом все. Это была короткая сводка про те туннели, которые я использую в своей работе. Есть еще классная штука — socks proxy, который также можно поднять похожей командой, но про нее, может быть, я напишу отдельный пост в свое время.

Благодарю за внимание!

Что такое туннель SSH и туннелирование SSH?

На этой странице объясняется SSH-туннелирование (также называемое SSH-переадресацией портов ), как его можно использовать для доступа во внутреннюю корпоративную сеть из Интернета и как предотвратить туннелирование SSH через брандмауэр. Туннелирование SSH — мощный инструмент, но им также можно злоупотреблять. Управление туннелированием особенно важно при перемещении сервисов в Amazon AWS или другие сервисы облачных вычислений.

Содержимое

Что такое SSH-туннель? Кто использует туннелирование SSH? Преимущества туннелирования SSH для предприятий Туннелирование SSH в корпоративном портфеле рисков Как настроить туннель SSH

Что такое туннель SSH?

Туннелирование SSH — это метод передачи произвольных сетевых данных через зашифрованное соединение SSH. Его можно использовать для добавления шифрования в устаревшие приложения. Его также можно использовать для реализации VPN (виртуальных частных сетей) и доступа к службам интрасети через брандмауэры.

SSH — это стандарт безопасного удаленного входа в систему и передачи файлов по ненадежным сетям. Он также обеспечивает способ защиты трафика данных любого данного приложения с помощью переадресации портов, в основном туннелируя любой порт TCP/IP через SSH. Это означает, что трафик данных приложения направляется внутри зашифрованного соединения SSH, чтобы его нельзя было перехватить или перехватить во время передачи. Туннелирование SSH позволяет добавить сетевую безопасность к устаревшим приложениям, которые изначально не поддерживают шифрование.

На рисунке представлен упрощенный обзор туннелирования SSH. Безопасное соединение по недоверенной сети устанавливается между клиентом SSH и сервером SSH. Это SSH-соединение зашифровано, защищает конфиденциальность и целостность и аутентифицирует взаимодействующие стороны.

Соединение SSH используется приложением для подключения к серверу приложений. При включенном туннелировании приложение связывается с портом на локальном узле, который прослушивает клиент SSH. Затем клиент SSH перенаправляет приложение через свой зашифрованный туннель на сервер. Затем сервер подключается к фактическому серверу приложений — обычно на той же машине или в том же центре обработки данных, что и сервер SSH. Таким образом, связь между приложениями защищена без необходимости изменять приложение или рабочие процессы конечного пользователя.

Кто использует туннелирование SSH?

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

Хакеры и вредоносные программы могут использовать его так же, как оставлять лазейку во внутреннюю сеть . Его также можно использовать для сокрытия следов злоумышленников путем отражения атаки через несколько устройств, допускающих неконтролируемое туннелирование.

Чтобы узнать, как настроить туннель SSH, см. этот пример. Туннелирование часто используется вместе с ключами SSH и аутентификацией с открытым ключом для полной автоматизации процесса.

Преимущества туннелирования SSH для предприятий

Туннели SSH широко используются во многих корпоративных средах, использующих мэйнфреймы в качестве серверных приложений. В этих средах сами приложения могут иметь очень ограниченную встроенную поддержку безопасности. Используя туннелирование, можно добиться соответствия стандартам SOX, HIPAA, PCI-DSS и другим стандартам без необходимости модификации приложений.

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

Tectia SSH Client/Server — это коммерческое решение, которое может обеспечить безопасное туннелирование приложений вместе с SFTP и безопасный удаленный доступ для предприятий.

Туннелирование SSH в портфеле корпоративных рисков

Как бы ни было полезно туннелирование SSH, оно также создает риски, которые должны устраняться корпоративными группами ИТ-безопасности. Соединения SSH защищены надежным шифрованием. Это делает их содержимое невидимым для большинства развернутых решений для мониторинга сети и фильтрации трафика. Эта невидимость сопряжена со значительным потенциалом риска, если она используется в злонамеренных целях, таких как эксфильтрация данных. Киберпреступники или вредоносное ПО могут использовать туннели SSH для сокрытия своих несанкционированных соединений или для извлечения украденных данных из целевой сети.

При атаке обратного туннелирования SSH злоумышленник настраивает сервер за пределами целевой сети (например, в Amazon AWS). Как только злоумышленник оказывается в целевой системе, он подключается к внешнему SSH-серверу изнутри. Большинство организаций разрешают исходящие SSH-соединения, по крайней мере, если у них есть серверы в общедоступном облаке. Это соединение SSH настроено с параметром, который включает переадресацию портов TCP с порта на внешнем сервере на порт SSH на сервере во внутренней сети. Для настройки этого обратного туннеля SSH требуется одна однострочная команда внутри, и ее можно легко автоматизировать. Большинство брандмауэров практически не защищают от него.

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

В сочетании с атаками на основе неуправляемых ключей SSH туннелирование SSH позволяет злоумышленнику использовать украденные ключи SSH для интрасети из общедоступного Интернета .

Туннельные атаки SSH также могут использоваться для скрытие источника атаки . Обычно хакеры отражают атаки на системы и устройства, которые позволяют переадресации портов SSH скрывать свои следы. Это позволяет им исследовать уязвимости, пробовать различные учетные данные для входа или запускать инструменты для атак на электронную почту, Интернет, телефонию и любые другие протоколы. Проведение атаки через дюжину случайных устройств через зашифрованные туннели, по которым также передается другой трафик, делает ее практически неотслеживаемой. Akamai задокументировала миллионы устройств IoT, которые использовались таким образом.

Для противодействия этим рискам требуется возможность мониторинга, контроля и аудита зашифрованных соединений SSH. Для предотвращения отказов требуется правильная настройка и укрепление операционных систем IoT.

Следует также отметить, что туннелирующие атаки не специфичны для SSH — грамотный программист может написать инструмент для туннелирования портов за несколько часов и запустить его на любой машине во внутренней сети. Это может сделать любой ноутбук или другое устройство во внутренней сети — ему просто нужно иметь возможность общаться с каким-то (любым) сервисом в Интернете. Такой инструмент может работать через SSL/TLS, может эмулировать HTTP или работать через UDP и использовать пакеты, которые выглядят как запросы и ответы DNS. SSH просто упрощает жизнь непрограммистам. Вы можете защититься от туннельных атак только против людей, которые могут запускать программное обеспечение внутри или подключать любое устройство к внутренней сети, разрешая только те протоколы, которые вы можете проверять через брандмауэр.

Как настроить туннель SSH

Подробные инструкции по настройке см. на странице примера конфигурации. Параметры командной строки SSH и страницы файла конфигурации сервера SSH также могут быть полезны.

Клиентская команда и конфигурация сервера

Содержание

Что такое перенаправление портов SSH, также известное как туннелирование SSH? Локальная переадресация Удаленная переадресация Открытие бэкдоров в конфигурации на стороне сервера предприятия Как предотвратить переадресацию портов SSH в обход брандмауэров Решение SSHДополнительная информация

Что такое перенаправление портов SSH, также известное как туннелирование SSH?

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

Локальная переадресация

Локальная переадресация используется для переадресации порта с клиентского компьютера на серверный. По сути, клиент SSH прослушивает соединения на настроенном порту, и когда он получает соединение, он туннелирует соединение с сервером SSH. Сервер подключается к настроенному порту назначения, возможно, на другой машине, чем SSH-сервер.

Типичные варианты использования переадресации локальных портов включают:

Сеансы туннелирования и передача файлов через серверы перехода
Подключение к службе во внутренней сети извне
Подключение к удаленному файловому ресурсу через Интернет

Довольно много организаций для всего входящего доступа по SSH через единый сервер перехода. Сервер может представлять собой стандартную систему Linux/Unix, обычно с некоторой дополнительной защитой, обнаружением вторжений и/или ведением журнала, или это может быть коммерческое решение для перехода на другой сервер.

Многие серверы перехода разрешают переадресацию входящего порта после аутентификации соединения. Такая переадресация портов удобна тем, что позволяет технически подкованным пользователям достаточно прозрачно использовать внутренние ресурсы. Например, они могут перенаправить порт на своем локальном компьютере на веб-сервер корпоративной интрасети, на порт IMAP внутреннего почтового сервера, на 445 и 139 локального файлового сервера.порты, на принтер, в репозиторий с контролем версий или почти в любую другую систему во внутренней сети. Часто порт туннелируется в порт SSH на внутренней машине.

В OpenSSH переадресация локального порта настраивается с помощью параметра -L :

 ssh -L 80:intra.example.com:80 gw.example.com

В этом примере открывается подключение к gw.example .com jump server и перенаправляет любое соединение с порта 80 на локальном компьютере на порт 80 на intra.example.com .

По умолчанию любой (даже на разных машинах) может подключиться к указанному порту на клиентской машине SSH. Однако это можно ограничить программами на одном хосте, указав адрес привязки :

 ssh -L 127.0.0.1:80:intra.example.com:80 gw.example.com

Параметр LocalForward в файле конфигурации клиента OpenSSH можно использовать для настройки переадресации без необходимости указывать ее в командной строке.

Удаленная переадресация

В OpenSSH переадресация удаленных портов SSH задается с помощью параметра -R . Например:

 ssh -R 8080:localhost:80 public.example.com

Это позволяет любому на удаленном сервере подключаться к TCP-порту 8080 на удаленном сервере. Затем соединение будет туннелировано обратно на клиентский хост, после чего клиент устанавливает TCP-соединение с портом 80 на localhost . Вместо 9 можно использовать любое другое имя хоста или IP-адрес.0112 localhost , чтобы указать хост для подключения.

Этот конкретный пример может быть полезен для предоставления кому-то снаружи доступа к внутреннему веб-серверу. Или выставить внутреннее веб-приложение в общедоступный Интернет. Это может сделать сотрудник, работающий из дома, или злоумышленник.

По умолчанию OpenSSH разрешает подключение только к удаленным переадресованным портам с узла сервера. Однако для управления этим можно использовать параметр GatewayPorts в файле конфигурации сервера sshd_config. Возможны следующие варианты:

 GatewayPorts нет

Это предотвращает подключение к переадресованным портам из-за пределов сервера.

 GatewayPorts да

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

 GatewayPorts clientspecified

Это означает, что клиент может указать IP-адрес, с которого разрешены подключения к порту. Синтаксис для этого:

 ssh -R 52.194.1.73:8080:localhost:80 host147.aws.example.com

В этом примере разрешены только подключения с IP-адреса 52. 194.1.73 к порту 8080.

OpenSSH также позволяет указать для перенаправляемого удаленного порта значение 0. В этом случае сервер динамически выделяет порт и сообщает об этом клиенту. При использовании с параметром -O forward клиент выводит выделенный номер порта на стандартный вывод.

Вскрытие бэкдоров на предприятии

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

Сотрудник также должен установить GatewayPorts yes на сервере (у большинства сотрудников дома нет фиксированных IP-адресов, поэтому они не могут ограничить IP-адрес).

Например, следующая команда открывает доступ к внутренней базе данных Postgres через порт 5432 и к внутреннему порту SSH через порт 2222.

 ssh -R 2222:d76767.nyc.example.com:22 -R 5432:postgres3.nyc .example.com:5432 aws4.mydomain.net

Конфигурация на стороне сервера

Параметр AllowTcpForwarding в файле конфигурации сервера OpenSSH должен быть включен на сервере, чтобы разрешить переадресацию портов. По умолчанию переадресация разрешена. Возможные значения для этой опции: да или все для разрешения всех переадресаций TCP, нет для запрета всех переадресаций TCP, локальный для разрешения локальных переадресаций и удаленный для разрешения удаленных переадресаций.

Другим интересным вариантом является AllowStreamLocalForwarding , который можно использовать для переадресации сокетов домена Unix. Он допускает те же значения, что и AllowTcpForwarding . По умолчанию да .

Например:

 AllowTcpForwarding удаленный AllowStreamLocalForwarding нет

Параметр конфигурации GatewayPorts , описанный выше, также влияет на перенаправление удаленных портов. Возможные значения: нет (разрешены только локальные соединения с узла сервера; по умолчанию), да (любой пользователь в Интернете может подключаться к удаленным переадресованным портам) и указанный клиентом (клиент может указать можно, если не указано).

Как предотвратить переадресацию портов SSH в обход брандмауэров

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

Проблема в том, что на практике перенаправление портов может быть предотвращено только сервером или брандмауэром. Предприятие не может контролировать все серверы в Интернете. Контроль на основе брандмауэра также может быть сложным, поскольку у большинства организаций есть серверы в Amazon AWS и других облачных сервисах, и доступ к этим серверам обычно осуществляется с помощью SSH.

Tectia SSH Client/Server от SSH — это коммерческое решение, которое может обеспечить безопасное туннелирование приложений вместе с SFTP и безопасный удаленный доступ для предприятий.

Дополнительная информация о туннелировании SSH

Что такое туннель SSH, обратный туннель SSH и переадресация портов SSH?

Хотя типичным вариантом использования SSH является безопасный доступ к удаленному серверу, вы также можете передавать файлы, перенаправлять локальные и удаленные порты, монтировать удаленные каталоги, перенаправлять графический интерфейс или даже проксировать произвольный трафик (должен ли я говорить, что SSH — это круто?) . И это лишь малая часть того, что возможно с SSH.

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

Если вы ищете современную альтернативу OpenSSH с открытым исходным кодом, оптимизированную для эластичных многооблачных сред и поддерживающую другие протоколы доступа в дополнение к SSH, обязательно ознакомьтесь с Teleport.

Теперь начнем!

Что такое туннелирование SSH?

Туннелирование SSH — это метод передачи дополнительных потоков данных в рамках существующего сеанса SSH. Туннелирование SSH помогает достичь таких сценариев использования безопасности, как удаленный доступ к веб-службе без раскрытия порта в Интернете, доступ к серверу за NAT, раскрытие локального порта в Интернете.

Как работает туннель SSH?

Когда вы подключаетесь к серверу с помощью SSH, вы получаете оболочку сервера. Это поведение по умолчанию для SSH-соединения. Под капотом ваш SSH-клиент создает зашифрованный сеанс между вашим SSH-клиентом и SSH-сервером. Но данные, передаваемые в сеансе SSH, могут быть любого типа. Например, во время доступа к оболочке передаваемые данные представляют собой двоичные потоки с подробным описанием размеров псевдотерминала и символов ASCII для запуска команд в удаленной оболочке. Однако во время переадресации порта SSH передаваемые данные могут представлять собой двоичный поток протокола, туннелируемый через SSH (например, SQL через SSH).

Рис. Сеанс SSH.

Таким образом, туннелирование SSH — это просто способ передачи произвольных данных с помощью выделенного потока данных (туннеля) внутри существующего сеанса SSH. Это может быть достигается с помощью переадресации локального порта, переадресации удаленного порта, динамической переадресации портов или путем создания туннеля TUN/TAP. давайте возьмем посмотрите, как работает перенаправление портов и варианты их использования ниже.

Переадресация локального порта

Когда используется переадресация локального порта, OpenSSH создает отдельный туннель внутри соединения SSH, который перенаправляет сетевой трафик с локального порт на порт удаленного сервера. В OpenSSH эту функцию туннелирования можно использовать, предоставив -L флаг. Внутри SSH выделяет сокет прослушиватель на клиенте на данном порту. При подключении к этому порту соединение перенаправляется по существующему каналу SSH. на порт удаленного сервера.

Переадресация локального порта — это один из способов защитить небезопасный протокол или сделать так, чтобы удаленная служба выглядела как локальная.

Когда использовать переадресацию локального порта?

Доступ к незащищенному протоколу

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

Безопасный доступ к удаленной службе

Из соображений безопасности рекомендуется привязывать службы только к локальному интерфейсу (в отличие от прослушивания на общедоступном интерфейсе). Обратная сторона именно так пользователи будут получать доступ к сервису из внешней сети. Вы можете использовать локальную переадресацию портов для доступа к службе, которая прослушивание на удаленном локальном хосте. Таким образом, соединения на локальной машине с переадресованным портом, по сути, будут на удаленную машину.

Рассмотрим пример ниже, где база данных PostgreSQL на удаленном сервере прослушивает удаленный локальный хост ( 127.0.0.1:5432 ). Ни в коем случае клиент может напрямую подключиться к этой базе данных, но может получить доступ к серверу через SSH. Таким образом, при переадресации локального порта SSH клиент подключается к удаленный сервер (с действительными учетными данными SSH) и команды SSH для переадресации локального порта клиента 5432 на локальный порт сервера 5432 . Таким образом, когда программа (в данном случае pgAdmin) подключается к порту 5432 клиента, SSH перенаправляет соединение на локальный порт 5432 удаленного сервера (работает PostgreSQL).

Рис. Перенаправление локального порта SSH.

Команда переадресации локального порта SSH для описанного выше сценария:

bash $ ssh -L 5432:127.0.0.1:5432 [email protected]

Кроме того, нет ограничений на количество переадресаций портов, которые вы хотите включить. Например, ниже SSH перенаправляет два локальных порта, 3338 и 3339 , на удаленные порты 3338 и 3339 .

bash $ ssh -L 3338:localhost:3338 -L 3339:localhost:3339 [email protected]

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

bash $ ssh -N -L 3339:localhost:3339 [email protected]

Переадресация удаленного порта (обратное туннелирование)

Также часто называемая обратным туннелированием SSH, переадресация удаленного порта перенаправляет порт удаленного сервера на порт локального хоста. Когда удаленный порт используется переадресация, сначала клиент подключается к серверу по SSH. Затем SSH создает отдельный туннель внутри существующего SSH. сеанс, который перенаправляет входящий трафик с удаленного порта на локальный хост (где было создано SSH-соединение).

Переадресация удаленного порта может быть достигнута в OpenSSH с помощью -R флаг. Внутри SSH выделяет прослушиватель сокетов на удаленном сервере на данный порт. Когда к этому порту устанавливается соединение, соединение перенаправляется по существующему каналу SSH на локальный клиентский порт. порт.

Когда использовать удаленную переадресацию портов?

Открытие службы, работающей на локальном хосте сервера за NAT, в Интернете

Рассмотрим сценарий ниже. Клиент запускает веб-сервер на порту 3000, но не может открыть этот веб-сервер для общедоступного Интернета, поскольку клиентская машина находится за NAT. С другой стороны, удаленный сервер может быть доступен через Интернет. Клиент может подключиться к этому удаленному сервер. В этой ситуации, как клиент может открыть веб-сервер на порту 9?0268 3000 в интернет? Через обратный туннель SSH!

Рис: Переадресация удаленного порта SSH

Шаги:

Запустите веб-сервер на локальном хосте клиента, порт 3000 . 2. Настройте обратный туннель с помощью команды.

bash $ ssh -R 80:127.0.0.1:3000 [email protected]

Теперь, когда пользователи из удаленного Интернета посещают порт 80 удаленного сервера как http:// , запрос перенаправляется обратно на локальный сервер клиента (порт 3000 ) через туннель SSH, где локальный сервер обрабатывает запрос и ответ.

По умолчанию туннель переадресации удаленного порта будет привязан к локальному хосту удаленного сервера. Чтобы он мог слушать на публике интерфейс (для описанного выше сценария) установите конфигурацию SSH GatewayPorts yes в sshd_config .

Альтернатива переадресации локального порта

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

Динамическая переадресация портов

Переадресация локального и удаленного портов требует определения локального и удаленного портов. Что делать, если порты заранее неизвестны или если вы хотите ретранслировать трафик в произвольное место назначения? Динамическая переадресация портов, также известная как динамическое туннелирование или прокси-сервер SSH SOCKS5, позволяет укажите порт подключения, который будет динамически перенаправлять каждый входящий трафик на удаленный сервер.

Динамическая переадресация портов превращает ваш SSH-клиент в прокси-сервер SOCKS5. SOCKS — это старый, но широко используемый протокол для запросов программ. исходящие соединения через прокси-сервер.

Когда использовать динамическую переадресацию портов?

Обход фильтров контента

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

Рис. Динамическая переадресация порта SSH

Рассмотрим случай выше. Клиент не может получить доступ к определенным веб-страницам из-за фильтрации контента, реализованной перед ним брандмауэром. Но клиент может подключиться к удаленному серверу (через SSH), который имеет неограниченный доступ в Интернет. В этом случае клиент может инициировать ssh подключение путем включения динамической переадресации портов, создавая таким образом прокси-сервер SOCKS5; клиент может указать веб-браузеру прослушивание прокси-сервера на локальном порт 6000 и получить доступ к веб-контенту с ограниченным доступом.

Команда, используемая для описанного выше сценария динамического туннелирования SSH:

bash $ ssh -D 127.0.0.1:6000 [email protected]

SSH TUN/TAP туннелирование

SSH поддерживает переадресацию туннельных устройств ТУН/ТАП). TUN/TAP — это виртуальные сетевые интерфейсы, которые можно использовать для создания туннеля. между двумя серверами. Эта установка — VPN для бедняков. Для полностью рабочего туннеля TUN/TAP с переадресацией SSH вам сначала нужно добавить tun устройства и настроить маршрутизацию между двумя серверами. Формат использования SSH TUN — 9.0268 -w local_tun[:remote_tun] . Обратитесь к этому руководство для полного настраивать. В этом сообщении блога также доступен скрипт, если вы хотите попробуйте туннелировать на своем сервере.

Бонус — туннелирование SSH через TOR

До сих пор мы обсуждали, как SSH поддерживает туннелирование внутри существующих сеансов SSH. Но сам SSH можно туннелировать через другие протоколы, такие как НОСКИ. TOR — это популярное программное обеспечение для обеспечения анонимности, которое поддерживает туннелирование любого протокола через прокси-сервер SOCKS5.

SSH уже обеспечивает безопасный способ связи по зашифрованным каналам. Если вам нужна дополнительная анонимность (скрыть происхождение сеанса SSH), вы можете использовать TOR для ретрансляции SSH-соединения. Это можно сделать с помощью торс как:

bash $ torsocks ssh [электронная почта защищена]<удаленный_сервер>

Или с помощью netcat как:

bash $ ssh -o ProxyCommand="nc -X 5 -x localhost:9050 %h %p" [электронная почта защищена ]

Вопросы безопасности при туннелировании SSH

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

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

Сообщения в блоге о кибербезопасности Teleport и технические новости

Каждые две недели мы будем рассылать информационный бюллетень с последними новостями о кибербезопасности и обновлениями Teleport.

Адрес электронной почты

Этот сайт защищен reCAPTCHA, к нему применяются Политика конфиденциальности и Условия обслуживания Google.

Заключение

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

Методы туннелирования SSH также часто используются злоумышленниками для сокрытия вредоносного сетевого трафика. Как администратор сети или безопасности, если ваша команда или разработчики используют туннель SSH, важно отслеживать шаблоны трафика, чтобы постоянно обнаруживать аномалии в обычных узоры. Это можно сделать, сначала перехватив пакеты с помощью инструментов анализа пакетов, таких как tcpdump и Wireshark и анализ трафика.

Далее — Попробуйте Телепорт. Teleport — это современный SSH-сервер с функциями оптимизирован для эластичных многооблачных сред и поддерживает другие протоколы доступа помимо SSH. Если ваши серверы разделены между различных сетях/облаках, туннелирование узла телепорта позволяет управлять безопасным удаленным доступ без необходимости открывать эти серверы для общедоступной сети.

Как настроить туннелирование SSH (переадресация портов)

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

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

Существует три типа переадресации портов SSH:

Переадресация локального порта. — Перенаправляет соединение с хоста клиента на хост сервера SSH, а затем на порт хоста назначения.
Переадресация удаленного порта. — Перенаправляет порт с хоста сервера на хост клиента, а затем на порт хоста назначения.
Динамическая переадресация портов. — Создает прокси-сервер SOCKS, который обеспечивает связь через ряд портов.

В этой статье объясняется, как настроить локальные, удаленные и динамически зашифрованные туннели SSH.

Переадресация локального порта #

Переадресация локального порта позволяет вам перенаправить порт на локальном компьютере (клиент ssh) на порт на удаленном компьютере (сервер ssh), который затем перенаправляется на порт на компьютере назначения.

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

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

В Linux, macOS и других системах Unix для создания локальной переадресации портов передайте параметр -L клиенту ssh :

 ssh -L [LOCAL_IP:]LOCAL_PORT:DESTINATION:DESTINATION_PORT [USER@ ]SSH_SERVER

Используются следующие параметры:

[LOCAL_IP:]LOCAL_PORT — IP-адрес и номер порта локальной машины. Когда LOCAL_IP опущен, клиент ssh привязывается к локальному хосту.
DESTINATION:DESTINATION_PORT — IP-адрес или имя хоста и порт целевого компьютера.
[USER@]SERVER_IP — IP-адрес удаленного пользователя SSH и сервера.

Вы можете использовать любой номер порта больше 1024 в качестве LOCAL_PORT . Порты с номерами меньше 1024 являются привилегированными портами и могут использоваться только пользователем root. Если ваш SSH-сервер прослушивает порт, отличный от 22 (по умолчанию), используйте -p [НОМЕР ПОРТА] опция.

Имя хоста назначения должно разрешаться сервером SSH.

Допустим, у вас есть сервер базы данных MySQL, работающий на машине db001.host во внутренней (частной) сети на порту 3306, который доступен с машины pub001.host , и вы хотите подключиться, используя локальную машина клиента MySQL к серверу базы данных. Для этого вы можете перенаправить соединение с помощью следующей команды:

 ssh -L 3336:db001.host:3306 [email protected]

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

Теперь, если вы укажете клиент базы данных локального компьютера на 127.0.0.1:3336 , соединение будет переадресовано на сервер db001.host:3306 MySQL через pub001.host машина, выступающая в роли промежуточного сервера.

Вы можете перенаправить несколько портов на несколько пунктов назначения с помощью одной команды ssh. Например, у вас есть другой сервер базы данных MySQL, работающий на машине db002.host , и вы хотите подключиться к обоим серверам с вашего локального клиента, вы должны запустить:

 ssh -L 3336:db001.host:3306 3337:db002 .хост:3306 пользователь@pub001.хост

Для подключения ко второму серверу используйте 127.0.0.1:3337 .

Если целевой хост совпадает с SSH-сервером, вместо указания IP-адреса или имени целевого хоста можно использовать localhost .

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

 ssh -L 5901:127.0.0.1:5901 -N -f [email protected]

Параметр -f указывает команде ssh выполняться в фоновом режиме и .0112 -N не выполнять удаленную команду. Мы используем localhost , потому что VNC и SSH-сервер работают на одном хосте.

Если у вас возникли проблемы с настройкой туннелирования, проверьте конфигурацию удаленного SSH-сервера и убедитесь, что для параметра AllowTcpForwarding не установлено значение no . По умолчанию переадресация разрешена.

Переадресация удаленного порта #

Переадресация удаленного порта противоположна переадресации локального порта. Это позволяет вам перенаправить порт на удаленном компьютере (сервер ssh) на порт на локальном компьютере (клиент ssh), который затем перенаправляется на порт на компьютере назначения.

В этом типе переадресации сервер SSH прослушивает заданный порт и туннелирует любое подключение к этому порту к указанному порту локального клиента SSH, который затем подключается к порту на целевом компьютере. Машина назначения может быть локальной или любой другой машиной.

В Linux, macOS и других системах Unix для создания удаленной переадресации портов передайте параметр -R в ssh клиент:

 ssh -R [REMOTE:]REMOTE_PORT:DESTINATION:DESTINATION_PORT [USER@]SSH_SERVER

Используются следующие параметры:

[REMOTE:]REMOTE_PORT — IP-адрес и номер порта на удаленном сервере SSH. Пустой REMOTE означает, что удаленный SSH-сервер будет связываться со всеми интерфейсами.
DESTINATION:DESTINATION_PORT — IP-адрес или имя хоста и порт целевого компьютера.
[USER@]SERVER_IP — IP-адрес удаленного пользователя SSH и сервера.

Удаленное перенаправление портов в основном используется для предоставления доступа к внутренней службе кому-то извне.

Допустим, вы разрабатываете веб-приложение на своем локальном компьютере и хотите показать предварительный просмотр своему коллеге-разработчику. У вас нет публичного IP, поэтому другой разработчик не может получить доступ к приложению через Интернет.

Если у вас есть доступ к удаленному серверу SSH, вы можете настроить переадресацию удаленного порта следующим образом:

 ssh -R 8080:127.0.0.1:3000 -N -f [email protected]

заставить ssh-сервер прослушивать порт 8080 и туннелировать весь трафик с этого порта на локальный компьютер через порт 3000 .

Теперь ваш коллега-разработчик может набрать the_ssh_server_ip:8080 в своем браузере и просмотреть ваше замечательное приложение.

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

Динамическая переадресация портов #

Динамическая переадресация портов позволяет создать сокет на локальном (ssh-клиентском) компьютере, который действует как прокси-сервер SOCKS. Когда клиент подключается к этому порту, соединение перенаправляется на удаленный компьютер (ssh-сервер), который затем перенаправляется на динамический порт на целевом компьютере.

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

В Linux, macOS и других системах Unix для создания динамической переадресации портов (SOCKS) передайте параметр -D клиенту ssh :

 ssh -D [LOCAL_IP:]LOCAL_PORT [USER@]SSH_SERVER

Используются следующие параметры:

[LOCAL_IP:]LOCAL_PORT — IP-адрес и номер порта локальной машины. Когда LOCAL_IP опущен, клиент ssh привязывается к локальному хосту.
[USER@]SERVER_IP — IP-адрес удаленного пользователя SSH и сервера.

Типичным примером динамической переадресации портов является туннелирование трафика веб-браузера через SSH-сервер.

Следующая команда создаст туннель SOCKS на порту 9090 :

 ssh -D 9090 -N -f [email protected]

После того, как туннелирование установлено, вы можете настроить свое приложение для его использования. эта статья объясняет, как настроить браузеры Firefox и Google Chrome для использования прокси-сервера SOCKS.

Переадресация портов должна быть настроена отдельно для каждого приложения, для которого вы хотите туннелировать трафик.

Настройка туннелирования SSH в Windows #

Пользователи Windows могут создавать туннели SSH с помощью клиента PuTTY SSH. Вы можете скачать PuTTY здесь .

Запустите Putty и введите IP-адрес SSH-сервера в поле Имя хоста (или IP-адрес) .
В меню Connection разверните SSH и выберите Туннели . Установите переключатель Local для настройки локального, Remote для удаленного и Dynamic для динамической переадресации портов.
- При настройке локальной переадресации введите локальный порт переадресации в поле Порт источника , а в поле Назначение введите хост и IP-адрес назначения, например, localhost:5901 .
- Для переадресации удаленного порта введите порт переадресации удаленного сервера SSH в поле 9.0112 Source Port и в Destination введите хост и IP назначения, например, localhost:3000 .
- При настройке динамической переадресации введите только локальный порт SOCKS в поле Исходный порт .
Нажмите кнопку Добавить , как показано на рисунке ниже.
Вернитесь на страницу Session , чтобы сохранить настройки, чтобы не вводить их каждый раз. Введите имя сеанса в поле Saved Session и нажмите кнопку Save .
Выберите сохраненный сеанс и войдите на удаленный сервер, нажав кнопку Открыть .
Появится новое окно с запросом имени пользователя и пароля. Как только вы введете свое имя пользователя и пароль, вы войдете на свой сервер, и туннель SSH будет запущен.
Настройка аутентификации с открытым ключом позволяет подключиться к вашему серверу без ввода пароля.

Заключение #

Мы показали вам, как настроить туннели SSH и перенаправить трафик через безопасное соединение SSH. Для простоты использования вы можете определить туннель SSH в файле конфигурации SSH. или создайте псевдоним Bash это настроит туннель SSH.

Если вы столкнулись с проблемой или хотите оставить отзыв, оставьте комментарий ниже.

сш безопасность

404: Страница не найдена

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

Что я могу сделать сейчас?

Если вы впервые посещаете TechTarget, добро пожаловать! Извините за обстоятельства, при которых мы встречаемся. Вот куда вы можете пойти отсюда:

Поиск

Узнайте последние новости.
Наша домашняя страница содержит самую свежую информацию об информационной безопасности.
Наша страница о нас содержит дополнительную информацию о сайте SearchSecurity, на котором вы находитесь.
Если вам нужно, свяжитесь с нами, мы будем рады услышать от вас.

Поиск по категории

ПоискСеть

Valmont Industries тестирует сеть как услугу для улучшения WAN
Valmont Industries нужна гибкая глобальная сеть, которую компания может модифицировать за несколько дней, а не месяцев. Мировой производитель тестирует …
Советы по подготовке к аудиту аварийного восстановления сети
Предприятия могут провести аудит своих планов аварийного восстановления сети, чтобы обеспечить тщательную защиту и подготовку. Учитывайте такие факторы, как …
Как искусственный интеллект и машинное обучение в Open RAN упрощают работу сети
Включение ИИ и машинного обучения в сети Open RAN может помочь операторам мобильной связи упростить операции и предоставить расширенные возможности 5G с высокой . ..

ПоискИТ-директор

Компаниям необходим план конфиденциальности данных, прежде чем присоединиться к метавселенной
Эксперты, выступавшие на конференции ITIF по политике в области дополненной и виртуальной реальности, отметили, что предприятиям необходимо выйти в метавселенную с сильным …
Инфляция в сфере ИТ-услуг следует более широкой тенденции рынка
ИТ-директора могут ожидать, что им придется платить больше за консультационные и профессиональные услуги, поскольку ценообразование в этом секторе продолжает повышаться …
10 примеров смарт-контрактов на блокчейне Смарт-контракты
поддерживают корпоративный блокчейн за счет автоматизации задач. Эти варианты использования демонстрируют преимущества и проблемы ИТ- …

SearchEnterpriseDesktop

Как выполнить сброс до заводских настроек на рабочем столе Windows 11
Возврат к заводским настройкам может потребоваться, если устройство имеет проблемы с производительностью или настроено на переход к новому пользователю. ИТ может выполнить этот процесс…
HP и Dell сообщают о снижении продаж ПК из-за колебания спроса со стороны бизнеса
Предприятия откладывают и сокращают заказы на настольные компьютеры и ноутбуки от HP и Dell, сообщили руководители. На рынке ПК насчитывается …
Введение в Edge Chromium против Edge
Переход на Chromium улучшил несколько аспектов браузера Microsoft Edge — от настроек конфиденциальности до надежности.

SearchCloudComputing

Упростите управление пакетами с помощью этого руководства по Azure Artifacts
Расширение службы Azure DevOps, Azure Artifacts, может помочь разработчикам управлять пакетами и обмениваться ими, чтобы оптимизировать общую…
Oracle оптимизирует расходы на AWS, поддержку многооблачных баз данных
Oracle разрешает пользователям своих баз данных получать доступ к этим сервисам в конкурирующих облаках, активно преследуя клиентов AWS в . ..
Сравните AWS Glue и Azure Data Factory
AWS Glue и Фабрика данных Azure имеют ключевые отличия, несмотря на то, что являются схожими сервисами. Узнайте, что лучше всего подходит для вашей организации …

ComputerWeekly.com

Flex Muscle Up Частная беспроводная связь 5G SA, Индустрия 4.0 в передовом производстве
Ведущий поставщик технологий связи совместно с многонациональной компанией по производству электроники объединит частную беспроводную связь 5G SA и Индустрию 4.0 …
Совет Барнета продлевает контракт Capita
Совет Барнета предоставил Capita продление контракта в рамках перехода от крупного контракта с поставщиком
.
В каталог CISA добавлено шесть новых уязвимостей
CISA добавляет шесть новых уязвимостей в свой список самых разыскиваемых, в том числе одну, появившуюся в 2010 году

SSH-туннелирование и прокси | Baeldung на Linux

1.

Введение
Одним из самых универсальных инструментов, которые есть в нашем распоряжении, является ssh . Более широко известный как предпочтительный инструмент удаленного доступа для администрирования удаленных хостов, он имеет так много дополнительных удобных функций, которые действительно полезно знать. Например, мы можем использовать ssh для передачи файлов, монтирования удаленных хостов в качестве сетевых файловых систем и генерации ключей.
В этом уроке мы углубимся в ssh возможности проксирования и туннелирования .
2. Концепции
С первых дней существования стека TCP/IP доступ к удаленному узлу был обязательным. Однако разработанные для него протоколы — telnet для интерактивного доступа и FTP для передачи файлов — не имели элементарной меры безопасности: поток данных не был зашифрован.
В результате данные, передаваемые с использованием этих протоколов, могут быть перехвачены и тщательно изучены средствами анализа сетевого трафика, такими как tcpdump и Wireshark. Поскольку имя пользователя и пароль были переданы в открытом виде, злоумышленнику легко их собрать.
Чтобы устранить эту проблему и другие ограничения, ssh реализует шифрование в своих соединениях . Таким образом, при условии, что это с соответствующей конфигурацией, надежным шифрованием и схемами обмена ключами, мы можем быть уверены, что наше сообщение не будет перехвачено на пути .
Одной из наиболее полезных и малоизвестных функций является возможность установки туннелей и прокси-серверов . Таким образом, мы можем использовать сеанс ssh для подключения других удаленных служб, которые иначе нам не видны, например, защищенных брандмауэром:
Как видно на рисунке, клиентская машина при открытии сеанса ssh дает указание серверу SSH открыть туннели, которые могут работать в обоих направлениях .
Он также может работать как прокси-сервер для протокола XWindows, позволяя нам локально открывать удаленные приложения с графическим интерфейсом, или как прокси-сервер, совместимый с SOCKS 4 или 5, позволяя клиенту получать доступ к нескольким адресатам с удаленного сайта, выдавая себя за SSH-сервер.
Еще более впечатляющим и опасным, поскольку он обеспечивает полный опыт, подобный VPN, является возможность туннелирования пакетов уровня 2 или уровня 3 с использованием устройств tun .
3. Конфигурация сервера
Прежде всего, мы должны отметить, что разрешение туннелирования через ssh соединений может быть проблемой безопасности, так как это может нарушить наши политики брандмауэра . Таким образом, необходимо соблюдать осторожность, чтобы не подвергать службы и хосты, которые мы предпочли бы держать закрытыми для нежелательного доступа . По этой причине некоторые дистрибутивы Linux по умолчанию отключают туннелирование и прокси.
3.1. Параметры SSHD
Включение sshd , демона, который обслуживает сеансы ssh, осуществляется путем редактирования файла sshd_config . Его расположение немного различается, но обычно это /etc/ssh или /etc/openssh . Соответствующие ключи конфигурации:
AllowStreamLocalForwarding : Разрешает переадресацию сокетов домена Unix. Значение по умолчанию, если оно не указано, равно 9.0865 да
AllowTcpForwarding : Разрешает переадресацию портов TCP. По умолчанию, если он опущен, разрешается. Он включает переадресацию одного TCP-порта и прокси-сервер Socks
.
DisableForwarding : Отключает все виды переадресации. Переопределить, если включено, все другие связанные параметры конфигурации
GatewayPorts : Позволяет другим хостам использовать порты, переадресованные клиенту (обратные туннели). По умолчанию только хосты, на которых запущен SSH-сервер, могут использовать обратные туннели. Отключено по умолчанию
PermitListen : Указывает адреса и порты, которые можно привязать, чтобы разрешить переадресацию портов клиентам. Это обеспечивает более точное управление, если мы включим GatewayPorts . По умолчанию используется localhost («127.0.0.1» и «::1»)
.
PermitOpen : Указывает адрес и порты, на которые может указывать переадресация TCP. По умолчанию любой пункт назначения включен
PermitTunnel : Указывает, разрешена ли переадресация устройств tun . По умолчанию нет
X11Forwarding : Указывает, разрешена ли переадресация X11. По умолчанию нет
X11UseLocalhost : принудительно разрешает пересылку X11 только с адреса обратной связи узла SSH-сервера. Если он отключен, другие хосты в сети SSH-сервера могут использовать его. По умолчанию верно
3.2. Другие конфигурации
Другие конфигурации на хосте могут повлиять на способность ssh к пересылке и прокси. AppArmor и SELinux может блокировать некоторые из этих параметров. Кроме того, некоторые конфигурации брандмауэра хоста могут ограничивать возможность подключения к внешним службам и из них (см. наш учебник по iptables ). Обратите внимание, что для привязки прослушиваемых портов до 1024 по умолчанию требуются привилегии root.
И, конечно же, промежуточные брандмауэры должны разрешать трафик SSH, обычно через порт TCP/22, но мы можем использовать и другие порты, изменив значение по умолчанию в файле sshd_config .
4. Прямые TCP-туннели
4.1. Однопортовый
Прямой или прямой туннель TCP — это туннель, следующий в направлении соединения SSH от клиента к серверу SSH . В нашем вводном руководстве по SSH кратко описан этот тип переадресации. Чтобы создать прямой туннель TCP, мы должны использовать параметр -L в командной строке:
ssh -L [bind_address:]port:host:hostport [[электронная почта защищена]]remote_ssh_server
Дополнительный bind_address назначает локальный интерфейс клиента для прослушивания подключений. Если мы его опустим, ssh связывается только с петлевыми интерфейсами. Мы также можем использовать «0.0.0.0» или «::» для привязки на всех интерфейсах. Итак, если мы введем следующую команду:
ssh -L 0.0.0.0:8022:10.1.4.100:22 [электронная почта защищена]
У нас было бы открыто SSH-соединение с хостом на IP-адресе 10.1.4.20 и туннель, прослушивающий клиентский порт 8022, указывающий на SSH-адрес на хосте 10.1.4.100.
Таким образом, если соединение поступает на клиентский порт 8022, оно будет переадресовано на хост и порт назначения с использованием IP-адреса SSH-сервера, что выглядит точно так же, как обычная локальная сеть между ними.
Точно так же для переадресации локальных сокетов (несколько менее обычных) мы можем использовать:
ssh -L local_socket:host:hostport [[электронная почта защищена]]remote_ssh_server
Или мы можем использовать:
ssh -L local_socket:remote_socket [[электронная почта защищена]]remote_ssh_server
4.
2. Динамический или многопортовый
Особым случаем прямых туннелей TCP является возможность прокси-сервера Socks. Используя эти параметры, клиент SSH прослушивает указанный порт привязки и действует как прокси-сервер SOCKS 4 или 5 .
Любые подключения по протоколу SOCKS к порту привязки будут перенаправлены на сервер SSH с использованием его собственного IP-адреса. Для этого мы будем использовать:
ssh -D [bind_address:]порт [[электронная почта защищена]]remote_ssh_server
Обратите внимание, что в этом случае нам даже не нужно указывать хост и порт назначения для переадресации. Все входящие соединения, совместимые с SOCKS, на указанный порт будут проходить через туннель.
Чтобы использовать его, мы должны, конечно, настроить приложение, которое будет использовать туннель, для использования прокси-сервера по привязанному адресу и порту, указанным в командной строке. Например, после выдачи:
ssh -D 8080 [электронная почта защищена]
Мы можем настроить браузер на клиентском хосте для использования нашего прокси-сервера SOCKS на 127. 0.0.1, порт 8080. Таким образом, мы можем просматривать веб-страницы, как если бы мы использовали браузер, установленный на сервере SSH, расположенном по адресу 10.1.4.100.
А что делать, если клиентское приложение не поддерживает SOCKS-проксирование? Мы можем использовать такие решения, как proxychains или tsocks , которые перехватывают системные вызовы сокетов и заставляют соединения проходить через прокси-сервер SOCKS.
5. Обратные туннели
5.1. Однопортовый
Обратные прокси-серверы или прокси-серверы обратного вызова позволяют нам выполнять трюки, аналогичные приведенным выше, но в обратном направлении . Мы можем открывать службы в наших собственных локальных сетях для хостов на удаленной стороне сеанса SSH. Синтаксис команды очень похож на прямую переадресацию:
.
ssh -R [bind_address:]port:host:hostport [[электронная почта защищена]]remote_ssh_server
Это создает обратный туннель. Он перенаправляет любое соединение, полученное на удаленном SSH-сервере, на bind_address:port в локальную клиентскую сеть host:hostport . Если мы опустим параметр bind_address , он привязывается только к петлевым интерфейсам.
Точно так же, используя сокеты, мы можем использовать три разных синтаксиса:
ssh -R remote_socket:host:hostport [[электронная почта защищена]]remote_ssh_server
ssh -R remote_socket:local_socket [[электронная почта защищена]]remote_ssh_server
ssh -R [bind_address:]порт:local_socket [[электронная почта защищена]]remote_ssh_server
5.2. Динамический или многопортовый
Наконец, мы можем открыть прокси-сервер SOCKS на удаленном хосте, направленном в сеть клиента, как мы можем сделать с прямой переадресацией . Мы можем сделать это, только опустив локальный хост и порт назначения:
.
ssh -R [bind_address:]порт [[электронная почта защищена]]remote_ssh_server
Это открывает порт на удаленном SSH-сервере, который будет служить SOCKS-сервером для локальной клиентской сети, потенциально нарушая любые правила исходящего трафика, которые в противном случае применялись бы к удаленному SSH-серверу.
6. Туннели X Windows
Одним из особых случаев обратного туннелирования является возможность туннелирования соединений X11. Таким образом, приложения с графическим интерфейсом, работающие на удаленной стороне SSH-соединений, могут использовать локальную сторону, на которой запущены X-серверы, для раскрытия своих пользовательских интерфейсов.0030 .
SSH устанавливает необходимые туннели. Кроме того, он устанавливает переменные среды DISPLAY, необходимые клиентским приложениям X на сервере SSH. Таким образом, они будут знать, как правильно подключить X-сервер локального клиента.
Существует два вида переадресации X11 с применением ограничений X11 Security Extension (см. xhost и xauth для справки):
ssh -X [[электронная почта защищена]]remote_ssh_server
Или создание туннеля в доверенной среде, которая не будет применять расширение безопасности X11:
ssh -Y [[электронная почта защищена]]remote_ssh_server
7.
Множественные туннели и множественное переключение хостов
Мы можем создать столько туннелей, сколько нам нужно, смешивая типы и направления. Этого можно добиться, добавив дополнительные параметры в командную строку:
.
ssh -X -L 5432::5432 -R 873:<локальный сервер RSYNC>:873 [[электронная почта защищена]]remote_ssh_server
Это открывает прямую переадресацию на удаленный сервер PostgreSQL, обратный 9 туннель на локальный сервер.0865 rsync и позволяет приложениям с графическим интерфейсом передаваться на наш локальный X-сервер.
И мы также можем использовать SSH-туннели для доступа к более дальним SSH-серверам, создавая к ним туннели, пронизывающие столько слоев брандмауэра, сколько нам нужно , создавая туннель для каждого соединения, пока мы не сможем достичь желаемой точки:
ssh -L 8022::22 [электронная почта защищена] ssh -L 8023::22 -p 8022 [электронная почта защищена] ssh -p 8023 [электронная почта защищена]
Эта последовательность создает на каждом этапе туннель к следующему серверу из server1 и server2 , пока туннель, открытый на локальном порту 8023, не позволит нам достичь server3 .
8. Файлы конфигурации
В сложных сценариях создание нескольких туннелей в командной строке может оказаться сложной задачей, поскольку это может привести к очень длинным командным строкам.
Вот почему одна из самых замечательных функций ssh позволяет использовать любые параметры командной строки в файлах конфигурации . Мы можем использовать глобальный ssh клиентский файл конфигурации (расположенный в /etc/ssh/ssh_config или /etc/openssh/ssh_config) или используйте специальный файл конфигурации нашего пользователя, который находится в ~/.ssh/config. Если он не существует, что является значением по умолчанию, нам придется создать новый.
В этих файлах мы можем указать конфигурации по умолчанию для каждой часто используемой конечной точки, включая туннели пересылки и прокси:
хост 10.1.4.100 ФорвардX11 да Локальный Форвард 0.0.0.0:5432 10.1.4.200:5432 локальный хост RemoteForward: 8022 локальный хост: 22 пользователь
Это позволит подключиться к удаленному серверу SSH на 10. 1.4.100, используя пользователя « baeldung », что позволяет:
Обратный туннель X Windows
Прямое туннелирование с локального порта 5432 на удаленный хост 10.1.4.200, порт 5432
Туннель обратного/обратного вызова через порт 8022 в петлевых интерфейсах сервера SSH к нашему локальному клиентскому хосту
Доступно множество других параметров, таких как сжатие, переадресация проверки подлинности Kerberos и многие другие. Кроме того, спецификация хоста допускает подстановочные знаки.
9. Постоянные туннели
Кстати, туннель SSH существует только до тех пор, пока поддерживается соединение SSH. Даже если мы сможем настроить частоту и время ожидания для поддержки активности сеанса, чтобы облегчить обнаружение потери соединения, было бы неплохо полностью автоматизировать создание и повторное подключение сеанса SSH.
Для этого удобна программа autossh . Эта утилита может автоматически создавать и воссоздавать сеансы SSH. Если мы добавим ключи аутентификации, как показано в нашем руководстве по ключам SSH, туннели будут открываться без вмешательства пользователя, пока работает autossh . Его синтаксис:
.
autossh [-V] [-M порт[:echo_port]] [-f] [SSH_OPTIONS]
-V: Показать autossh версии
-M: Создает прямой туннель на порту , зацикленный на обратный echo_port . Он обеспечивает живой механизм проверки. Однако с недавним OpenSSH мы можем добиться аналогичных результатов, используя 9Параметры 0865 ServerAliveInterval и ServerAliveCountMax в файле sshd_config
-f: принудительно запускает autossh в фоновом режиме перед запуском ssh
SSH_OPTIONS : параметры, которые мы будем использовать для запуска ssh
Таким образом, чтобы установить постоянное соединение, мы можем использовать:
autossh -X -L 5432::5432 -R 873:<локальный сервер RSYNC>:873 [[электронная почта защищена]]remote_ssh_server
Если мы определили конфигурацию хоста, командная строка будет намного проще:
autossh -f [хост]
10.
Заключение
В этой статье показано несколько полезных трюков, которые мы можем сделать с ssh , чтобы улучшить нашу доступность к удаленным хостам или с них, используя его возможности туннелирования .
Тем не менее, мы всегда должны помнить, что ssh доступ к хосту расширяет поверхность его кибератаки . Таким образом, использование любого вида туннелирования может увеличить риски, упрощая горизонтальное перемещение по сети наших серверов SSH.
Наконец, есть еще более продвинутый тип туннелирования: туннелирование устройств tun . Это еще более опасно, поскольку действует как полноценная VPN (виртуальная частная сеть). Этот тип туннеля связывает два удаленных сегмента сети, в которых расположены конечные точки.
Мы можем использовать его для создания туннелей уровня 2, которые ведут себя так, как если бы обе стороны находились в локальной сети или туннелях уровня 3. В этом случае каждая сторона имеет свою собственную IP-подсеть, и конечные точки SSH должны быть настроены для маршрутизации трафика между ними.
No related posts.

Ssh tunnel: SSH-туннели: практические примеры использования и важные функции

Магия SSH / Хабр

1) Local TCP forwarding

2) Remote TCP forwarding

3) TCP forwarding chain через несколько узлов

4) TCP forwarding ssh-соединения

5) SSH VPN Tunnel

6) Коротко о беспарольном доступе

7) Спасибо (ссылки)

SSH-туннели: практические примеры и ключевые функции

Как устроены SSH-туннели

Создание и настройка SSH-туннеля

Переадресация локального порта

Переадресация удаленного порта

Динамическая переадресация портов

Настройка SSH-туннелирования в Windows

Практическое применения функций SSH-туннелей

Автоматизация копирования ключа SSH

Удалённое выполнение команд

Копирование папки по SSH с локального сервера на удалённый

Редактирование текстовых файлов

Что лучше SSH или VPN

SSH-туннель: настройка и примеры | Soft-Setup

1. Прямой SSH-туннель: подключаемся к серверу за NAT

1.1 Прямой SSH-тунель с перенаправление на локальный порт SSH-сервера

2. Обратный SSH-туннель: выставляем ресурсы в Интернет

3. Динамический SSH-туннель: создаем SOCKS-прокси

4. SSH-туннель Layer 3 (сетевой уровень): туннелируем udp-трафик

‎App Store: SSH Tunnel — и SOCK5 прокси

Описание

Оценки и отзывы

Can’t reopen a connection without restarting my iPad

Не работает в фоне

Great App Support & Quality App

Не связанные с пользова­телем данные

Информация

Поддерживается

Другие приложения этого разработчика

Вам может понравиться

Как работает SSH-туннелирование

SSH Туннели — примеры | Fullstack не просто так

Первое знакомство с туннелями

Основная идея туннелей

Port forwarding на пальцах

Кейс с nginx

Кейс с базой данных Postgres в докере

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

Для чего еще можно использовать обратный туннель

Вместо заключения

Что такое туннель SSH и туннелирование SSH?

Содержимое

Что такое туннель SSH?

Кто использует туннелирование SSH?

Преимущества туннелирования SSH для предприятий

Туннелирование SSH в портфеле корпоративных рисков

Как настроить туннель SSH

Клиентская команда и конфигурация сервера

Содержание

Что такое перенаправление портов SSH, также известное как туннелирование SSH?

Локальная переадресация

Удаленная переадресация

Вскрытие бэкдоров на предприятии

Конфигурация на стороне сервера

Как предотвратить переадресацию портов SSH в обход брандмауэров

Что такое туннель SSH, обратный туннель SSH и переадресация портов SSH?

Что такое туннелирование SSH?

Как работает туннель SSH?

Переадресация локального порта

Доступ к незащищенному протоколу

Безопасный доступ к удаленной службе

Переадресация удаленного порта (обратное туннелирование)

Открытие службы, работающей на локальном хосте сервера за NAT, в Интернете

Шаги:

Альтернатива переадресации локального порта

Динамическая переадресация портов

Обход фильтров контента

SSH TUN/TAP туннелирование

Бонус — туннелирование SSH через TOR

Вопросы безопасности при туннелировании SSH

Сообщения в блоге о кибербезопасности Teleport и технические новости

Не связанные с пользователем данные