Туннели ssh: ТОП-20 трюков и советов для работы с SSH-туннелями

23.03.202029.09.2020 No Comments

Содержание

ТОП-20 трюков и советов для работы с SSH-туннелями

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

Клиентский конфиг располагается по пути: ~/.ssh / config и может выглядеть так:

Host *
     Port 2222

Host proglibserver
     HostName proglibserver.dev.io
     User author
     Port 2112
     IdentityFile /home/test/.ssh/ proglibserver.private_key

В данном примере две директивы:

одна сообщает, что на все хосты ходим через порт 2222;
а вторая – что нужно использовать конкретное имя пользователя, порт и ключ для узла proglibserver.

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

ssh -v -p 2200 -C author@proglibserver

— C: использование компрессии. Если ожидается большой текст, этот ключ может улучшить ситуацию, сжимая данные на лету.
proglibserver: имя удаленного сервера.
author@: – это логин. При попытке подключиться без логина, система подставит учетку, под которой вы находитесь на родительской машине.
— p 2200: порт удаленной машины (22 обычно не используется, т. к. это дефолтное значение). Для подключения к другому порту используется ключ -p.
— v: вывод на экран дебага (пригодится при сбоях аутентификации). Можно совмещать с другими ключами для получения нужного эффекта.

Все параметры, кроме имени хоста, являются необязательными.

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

Копирование публичного ключа

Эта команда выполняет то, что вы обычно делаете вручную – копирование ~/.ssh/id_rsa.pub из вашей системы в ~/.ssh/authorized_keys на proglib-сервере:

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

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

При подключении просто добавьте в конце команду, которую нужно выполнить на удаленном хосте:

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

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

Ниже пример другого способа копирования ключа на удаленный сервер:

localhost:~$ cat ~/.ssh/id_rsa.pub | ssh proglibserver 'cat >> .ssh/authorized_keys'

Проброс портов

В процессе проброса открывается порт в локальной ОС и подключается к порту на другом конце туннеля.

localhost:~$ ssh  -L 7777:127.0.0.1:90 user@proglibserver

Порт 7777 слушается на localhost и пробрасывается на 90 порт proglibserver. 127.0.0.1 – это localhost удаленного сервера.

Локальная папка на удаленной машине

Используя sshfs, можно примонтировать локальный каталог на удаленную машину:

localhost:~$ sshfs user@proglibserver:/media/data ~/data/

Динамическая настройка проброса портов

Вы глубоко «закопались» в сети, манипулируя SSH-туннелями, логинились полдюжины раз, и вам нужно получить порт на рабочем ПК, проброшенный с удаленной машины в рамках текущей сессии? Как это сделать, смотрите на примере ниже:

localhost:~$ ~C
ssh> -h
Commands:
      -L[bind_address:]port:host:hostport    Request local forward
      -R[bind_address:]port:host:hostport    Request remote forward
      -D[bind_address:]port                  Request dynamic forward
      -KL[bind_address:]port                 Cancel local forward
      -KR[bind_address:]port                 Cancel remote forward
      -KD[bind_address:]port                 Cancel dynamic forward
ssh> -L 1445:remote-win2k3:445
Forwarding port.

Обратный прокси в работе с SSH-туннелями

В данном примере устанавливается SOCKS прокси (весь трафик в туннеле будет идти от нашего localhost).

localhost:~$ ssh -v -R 0.0.0.0:1999 192.168.1.100 user@proglibserver

Траблшутинг

Если в процессе создания туннеля возникают трудности, используйте netstat для проверки привязки порта к интерфейсу. В нашем примере указано 0.0.0.0, но в случае, если не указан параметр GatewayPorts в sshd_config, все будет слушаться на 127.0.0.1.

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

Проксирование трафика SSH-туннелями через SOCKS

SSH Proxy – очень мощный и интересный инструмент. Но есть небольшой побочный эффект – источником трафика будет выступать машина, на которой запускается прокси. Например:

localhost:~$ ssh -D 8888 user@proglibserver

localhost:~$ netstat -pan | grep 8888

tcp        0      0 127.0.0.1:8888       0.0.0.0:*               LISTEN      23880/ssh

Мы запускаем сервер на порту 8888, а второй командой проверяем, слушается ли порт. Немного изменив команду, мы даем возможность другим приложениям подключаться к нашему прокси:

localhost:~$ ssh -D 0.0.0.0:8888 user@proglibserver

Чтобы проксирование заработало в браузере Chrome, выполните следующие шаги:

перейдите в Настройки -> Дополнительные -> Система -> Настройки прокси-сервера;
укажите IP и порт.

Вы можете это сделать одной строкой:

localhost:~$ google-chrome --proxy-server="socks5://192.168.1.10:8888"

Использование других приложений с прокси-сервером

Существует много приложений, использующих SOCKS. Браузер – простой и самый популярный пример. Некоторые приложения придется «по хитрому» настроить для использования прокси-сервера, а другим может быть необходима «вспомогательная» программа, работающая по протоколу SOCKS. Примером этого является proxychains. С помощью этого инструмента можно использовать Microsoft RDP через SOCKS.

localhost:~$ proxychains rdesktop $RemoteWindowsServer

Копирование файлов через SCP

Для копирования в SSH-клиенте есть два инструмента: scp и sftp.

localhost:~$ scp image.png author@proglibserver:/home/santa/image _2.png

После выполнения команды копируется файл image.png в папку /home/santa и переименовывается в image _2.png.

sftp author@proglibserver

Удаленный tcpdump и просмотр в Wireshark

Эта команда пригодится для удаленного графического анализа дампа:

localhost:~$ ssh root@ proglibserver 'tcpdump -c 1000 -nn -w - not port 22' | wireshark -k –i

Удаленный запуск GUI-приложения

Существует возможность запускать GUI-приложения удаленно. Это реально при наличии установленного пакета X11 и YES для X11Forwarding в файле sshd_config. Запустить можно любой софт. В примере используется консоль VMware:

localhost:~$ ssh -X proglibserver vmware

rsync и копирование файлов

Если вам часто нужно делать бекапы больших папок и файлов, то rsync будет удачным выбором. Этот инструмент умеет восстанавливать неудачный сеанс передачи и копировать только отличия между двумя временными точками:

localhost:~$ rsync -az /home/testuser/data proglibserver:backup/

SSH через Tor

Команда из примера ниже проксирует SSH-сессию при помощи инструмента torsocks через сеть Tor (9050 порт):

localhost:~$ torsocks ssh user@proglibserver

К применению tor, как и обратного прокси, стоит подходить со всей ответственностью, понимая, какие проблемы безопасности ОС могут всплывать и предоставлять пути движения трафика.

Двойной проброс портов

Можно пробрасывать порт на удаленный сервер через свою машину:

localhost:~ $ ssh-L 0.0.0.0:8888:20.20.20.20:70 user@proglibserver

Эта команда перенаправляет трафик с proglib-сервера на 20.20.20.20 (proglib-сервер будет выступать источником всего трафика).

Потоковое видео с использованием VLC + SFTP

Используйте опцию VLC Медиа | Открыть URL, чтобы указать адрес файла sftp: / / location. Если установлена защита, то появится запрос на ввод сведений для проверки подлинности.

sftp://proglibserver //media/uploads/myvideo.mkv

SSH на образ EC2

Чтобы подключаться к вашему EC2-образу Amazon (ключ -i), необходимо использовать приватный ключ. Скачайте его в админке Amazon и поменяйте права (chmod 400 key.pem). Держите этот ключ в надежном месте или положите его в ~/.ssh/.

localhost:~$ ssh -i ~/.ssh/my-ec2-key.pem ubuntu@my-ec2-public

«Прыжки» через хосты

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

localhost:~$ ssh -J host1,host2,host3 [email protected]

Использовать эту возможность можно после установки «YES» для параметра ProxyJump в ssh_config.

Reverse-SSH туннель

В этом примере рассматривается создание порта на удаленном сервере, который подключается обратно к локальному порту на нашем localhost (или другой ОС).

localhost:~$ ssh-v-R 0.0.0.0:1999:127.0.0.1: 902 192.168.1.100 user@ proglibserver

Установленное соединение с proglibserver по порту 1999 перенаправится в порт 902 нашего клиента.

Копирование папки

Данная команда сжимает папку (ключ -j) и извлекает ее, создавая дубликат:

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

Редактирование файлов через SCP

В локальной системе во время выполнения команды в папке /tmp создается файл, а затем копируется на сервер, как только редактирование завершилось:

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

Оригинал

SSH-туннели — пробрасываем порт / Хабр

Не всегда есть возможность, да и не всегда надо, строить полноценный туннель с интерфейсной парой адресов. Иногда нам нужно лишь «прокинуть» вполне определённые порты.

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

Итак. По-порядку.

Строим туннель из сети в мир.

$ ssh -f -N -R 2222:10.11.12.13:22 [email protected]

теперь введя на хосте 99.88.77.66:

$ ssh -p2222 localhost

мы попадём на хост 10.11.12.13.

Таким-же образом можно получить доступ к любому другому ресурсу, например:

$ ssh -f -N -R 2080:10.11.12.14:80 [email protected]

Введя на хосте 99.88.77.66:

$ w3m -dump http://localhost:2080

получим дамп web-ресурса на 10.11.12.14.

Строим туннель из мира в сеть.

$ ssh -f -N -L 4080:192.168.0.10:80 [email protected]

Аналогично, вводим на своём хосте:

$ w3m -dump http://localhost:4080

и получаем доступ к web-ресурсу узла 192.168.0.10, который находится за хостом 88.77.66.55.

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

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

Чтобы не утруждать себя дополнительным монотонным вбиванием команды на поднятие туннеля и мониторингом этого процесса, автоматизируем его. Смело вводим:

$ crontab -e

и создаём расписание примерно следующего вида:

TUNCMD1='ssh -f -N -R 2222:10.11.12.13:22 [email protected]'
TUNCMD2='ssh -f -N -R 2080:10.11.12.14:80 [email protected]'

*/5 * * * * pgrep -f "$TUNCMD1" &>/dev/null || $TUNCMD1
*/5 * * * * pgrep -f "$TUNCMD2" &>/dev/null || $TUNCMD2

Сохраняемся. Проверяем по

$ crontab -l

что расписание принято.

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

$ man 1 ssh

По практическому опыту — cron-задания на перезапуск абсолютно недостаточно.

Разве что соединение абсолютно стабильно. В реальной жизни встречается в 0% случаев.

Даже соединённые напрямую кабелем две сетевые карты легко могут потерять n-ное количество пакетов и tcp-соединение «упадёт».

Клиент и сервер будут пребывать в святой уверенности, что всё в порядке, просто вторая сторона ничего не передаёт.

Нужен keepalive.

Примерно так:

TCPKeepAlive yes
ServerAliveInterval 300
ServerAliveCountMax 3

Интервал и счётчик — по вкусу.

Добавлять их надо либо в /etc/ssh_config, либо в ~/.ssh/config, либо прямо в команде через опцию -o.

В принципе, судя по man ssh_config, первую из опций можно и опустить. но, на всякий случай, пусть будет.

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

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

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

Друзья попросили написать об этом статью. Но поскольку подобные описания уже существуют, то не было смысла переписывать это ещё раз. Была найдена вот эта отличная статья иженера компании «Белтел» — Сергея Герасимова. При перепечатке она подверглась незначительной редактуре для удобства восприятия, и дополнена моими комментариями.

Эта статья, практически рассказывает об SSH на пальцах.

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

SSH — это магия, друзья!

Зачем нужен SSH?

Каждый системный администратор или сетевой инженер хоть раз в своей практике сталкивался с ситуацией, когда нужно получить доступ из публичной сети Интернет к ресурсам своей рабочей сети, скрытой за NAT и защищённой фаерволом.
Конечно, для решения этой задачи можно настроить шифрованный site-to-site туннель или PPTP.

Или же воспользоваться сторонним приложением для организации удалённого доступа, например TeamViewer. Однако есть более простое решение, на реализацию которого уйдет буквально одна минута. К тому же, это решение не требует никакого стороннего программного обеспечения, кроме включённого по умолчанию в 90% Linux/Unix дистрибутивов пакета OpenSSH.

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

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

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 сервере. Всё просто J

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

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

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

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

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

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

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

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

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

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

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

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

putty

SecureCRT

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

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

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

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

безопасно через сервер / Хабр

Доброго времени суток. Попробуем дополнить и расширить статью SSH-туннели — пробрасываем порт. Рассмотренными примерами мы убьем сразу 2 задачи:
1. Межсетевая коммуникация через промежуточный сервер, когда между сетями пути нет.
2. Создание безопасного соединения через не доверенную сеть.
Предположим, что у нас есть unix like машина в сети, с запущенным sshd.
Первый вариант создания криптотуннеля это соединение, условно которое можно назвать точка-точка. В частности, при соединении сервером на стороне клиента открывается локальный порт, обращения на который будут передаваться удаленной машине через установленный криптотуннель. Что бы было понятно рассмотрим пример:

Наша машина: IP 10.0.0.2

Сервер: IP 10.0.0.1 (внешняя сеть там же где и мы) и 192.168.0.1 (внутренняя сеть, где находится целевой хост)

Целевой хост: 192.168.0.10

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

ssh -L локальный_порт:удаленный_хост:удаленный_порт сервер

То есть
ssh -L 12345:192.168.0.10:80 192.168.0.1

Если соединение установлено успешно, то на нашей машине открылся локальный порт 12345, при обращении на который мы попадем на веб сервер (80й порт) 192.168.0.10. Попробовать можно введя в браузере

http://localhost:12345

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

Рассмотрим второй вариант. Находясь в не доверенной сети (например в Интернет кафе или чужих контролируемых сетях) мы хотим воспользоваться сервисом, который принципиально не имеет шифрования. Будь то http (конфиденциальна не только переписка, но и учетная запись), icq, pop3 или любое подобное. Для этого, мы сначала устанавливаем соединение с нашим сервером, открывая тем самым криптотуннель, и работаем уже через него. В данном случае открытый у нас локальный порт будет работать аналогично socks5. Рассмотрим установку соединения:

ssh -D локальный_порт сервер

Как очевидно, все довольно просто. Далее уже легко настроить наши клиенты на работу через открытый socks на localhost.

В GNOME это можно сделать нажав Система-> Праметры -> Параметры прокси-сервера:

Отдельно можно легко в параметрах подключения настроить браузер, icq и многое другое.

Естественно, воспользоваться такой возможностью можно в Windows. Аналогичные соединения можно установить через клиент ssh putty:

Заставить в Windows работать большинство приложений через socks умеет widecap

И несколько советов:

1. Еще немного повысить уровень безопасности в некоторых случаях можно воспользовавшись не чужим ПО (в смысле с чужого компьютера), а используя возможность X forwarding в том же sshd. Но это отдельная тема. Скажу только что в роле X сервера в Windows может выступать Xming

2. Не забывайте про возможность Firefox и Chrome режима приватного просмотра.

Успехов.

Учимся использовать SSH туннелирование для безопасного серфинга

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

Туннелирование можно реализовать с помощью ssh-команды в Linux, Mac OS и операционных системах семейства UNIX. Для пользователей Windows, где нет встроенной ssh-команды, мы предлагаем бесплатный инструмент PuTTY. Он умеет подключаться к SSH-серверам. Он также поддерживает SSH-туннелирование.

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

Чтобы сделать это, вы устанавливаете SSH-соединение с SSH-сервером и говорите клиенту передать трафик с указанного порта на локальном ПК. Например, с порта 1234 на адрес сервера базы данных и его порт внутри офисной сети. Когда вы пытаетесь получить доступ к БД через порт 1234 на вашем ПК («localhost») трафик автоматически «туннелируется» по SSH-соединению и отправляется на сервер БД.

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

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

ssh -L local_port:remote_address:remote_port [email protected]

Предположим, что офисный сервер находится по адресу 192.168.1.111. У вас есть доступ к SSH-серверу через адрес ssh.youroffice.com, и имя вашего аккаунта на SSH-сервере — bob. В таком случае необходимая команда будет выглядеть следующим образом:

ssh -L 8888:192.168.1.111:1234 [email protected]

Запустив эту команду, вы попадете на офисный сервер баз данных через порт 8888 на localhost. Если у СУБД есть веб-интерфейс, можно вписать в адресную строку браузера http://localhost:8888. Если у вас инструмент командной строки, которому необходим сетевой адрес базы данных, то направьте его на localhost:8888. Весь трафик, отправленный на порт 8888 на ПК, будет перенаправлен на 192.168.1.111:1234 внутри офисной сети:

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

ssh -L 8888:localhost:1234 [email protected]

При попытке подключиться к БД через 8888 порт на вашем ПК, трафик будет передаваться с помощью SSH-подключения. Когда он достигнет системы, в которой работает SSH, SSH-сервер отправит его на порт 1234 на «localhost», принадлежащий тому же ПК, на котором запущен SSH-сервер. То есть, «localhost» в приведённой выше команде означает «localhost» с перспективы удалённого сервера:

Чтобы сделать это в PuTTY на Windows, выберите опцию Connection > SSH > Tunnels. Далее опцию «Local». В поле «Source Port» укажите локальный порт. В поле «Destination» введите целевой адрес и порт в формате удалённый_адрес:удалённый_порт.

Например, если нужно настроить SSH-тоннель, как это сделано выше, то введите 8888 в качестве порта-источника и localhost:1234 в качестве целевого адреса. После этого нажмите «Add» и затем «Open», чтобы открыть SSH-подключение. До подключения SSH туннелирования нужно ввести адрес и порт самого SSH-сервера в разделе «Session»:

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

Если есть доступ к удалённому SSH-серверу, можно подключиться к этому SSH-серверу и использовать дистанционное перенаправление портов. Ваш SSH-клиент укажет серверу перенаправлять трафик с определённого порта – скажем, 1234 – на SSH-сервере на указанный адрес и порт на вашем ПК или внутри локальной сети. Когда кто-то подключается к порту 1234 на SSH-сервере, этот трафик автоматически «туннелируется» по SSH-соединению. Любой, кто подключается к SSH-серверу, сможет получить доступ к серверу, запущенному на вашем ПК. Это достаточно эффективный способ обхода фаерволов.

Чтобы воспользоваться дистанционным туннелированием IP, используйте ssh-команду с аргументом —R. Синтаксис здесь будет практически таким же, как и в случае с локальным перенаправлением:

ssh -R remote_port:local_address:local_port [email protected]

Предположим, что нужно создать серверное приложение, прослушивающее порт 1234 на вашем ПК. Оно доступно через порт 8888 на удалённом SSH-сервере. Адрес SSH-сервера ssh.youroffice.com, а ваше имя пользователя на SSH-сервере bob. Значит, команда будет следующей:

ssh -R 8888:localhost:1234 [email protected]

Затем кто-то может подключиться к SSH-серверу через порт 8888, и это подключение будет туннелировано на серверное приложение, запущенное на порте 1234 ПК, с которого вы подключались:

Чтобы сделать это в PuTTY для Windows, выберите опцию Connection > SSH > Tunnels. Далее – опцию «Remote». В поле «Source Port» укажите удалённый порт. В поле «Destination» введите целевой адрес и порт в формате локальный_адрес:локальный_порт.

Например, если нужно настроить SSH-тоннель, как это сделано выше, то укажите 8888 в качестве порта-источника и localhost:1234 в качестве целевого адреса. После этого нажмите «Add» и затем «Open», чтобы открыть SSH-подключение. До подключения нужно будет ввести адрес и порт самого SSH-сервера в разделе «Session».

После этого пользователи смогут подключаться к порту 8888 на SSH-сервере и их трафик будет передаваться на порт 1234 на вашей локальной системе:

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

Нужно включить опцию «GatewayPorts» в sshd_config на удалённом SSH-сервере, если хотите изменить эти настройки.

Также существует «динамическое перенаправление портов», которое работает по тому же принципу что прокси или VPN-сервер. SSH-клиент создаёт SOCKS-прокси, который можно настраивать под собственные приложения. Весь трафик, отправляемый через прокси, будет отправляться через SSH-сервер. Принцип здесь схож с локальным перенаправлением – берётся локальный трафик, отправленный на определённый порт на вашем ПК, и перенаправляется через SSH-соединение на удалённый адрес.

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

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

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

Чтобы воспользоваться динамическим перенаправлением, запустите ssh-команду с аргументом —D:

ssh -D local_port [email protected]

Предположим, что у вас есть доступ к SSH-серверу по адресу ssh.yourhome.com, а ваш логин на SSH-сервере – bob. Нужно использовать динамическое перенаправление для того, чтобы открыть SOCKS-прокси по порту 8888 на текущем ПК. Тогда команда для SSH туннелирования будет выглядеть следующим образом:

ssh -D 8888 [email protected]

После этого можно настроить браузер или другое приложение на использование локального IP-адреса (127.0.0.1) и порта 8888. Весь трафик этого приложения будет перенаправляться через туннель:

Чтобы сделать это в PuTTY для Windows, выберите опцию Connection > SSH > Tunnels. Далее – опцию «Dynamic». В поле «Source Port» укажите локальный порт.

Например, если вам нужно настроить SOCKS-прокси на порт 8888, то введите 8888 в качестве порта-источника. После этого нажмите «Add» и затем «Open», чтобы открыть SSH-подключение.

После этого можно настроить приложение на подключение через SOCKS-прокси на вашем локальном ПК (то есть, по IP-адресу 127.0.0.1, который ведёт на ваш локальный ПК) и указать корректный порт для работы:

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

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

телеграм канал. Подпишись, будет полезно!

SSH VPN over Internet (SSH tun туннелирование) / Хабр

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

Для решения этой задачи, лучше всего подходит технология Vitual Private Network (VPN). Но с помощью чего реализовать эту технологию?

— Я выбрал SSH.

Дело в том, что OpenSSH начиная с версии 4.3, поддерживает tun туннелирование. Этим я и воспользовался…

Схематически это будет выглядеть следующим образом:

Для начала необходимо установить OpenSSH на сервере. У меня Ubuntu Server, и я это делаю так:

sudo aptitude install openssh-server

Хотя, скорее всего, он уже установлен. У меня — точно установлен 😉

Взглянем на более подробную схему, и обсудим её.

Как видно из рисунка, рабочий компьютер имеет IP 172.16.0.1 с маской 255.255.255.0 и шлюзом по умолчанию 172.16.0.254, а в качестве DNS указан IP 8.8.8.8

Компьютер Work: IP address: 172.16.0.1 Netmask: 255.255.255.0 Default Gateway: 172.16.0.254 DNS: 8.8.8.8

Таблица маршрутизации клиента (Work):

  172.16.0.0    0.0.0.0       255.255.255.0   U  1    0 0 eth0
  169.254.0.0   0.0.0.0       255.255.0.0     U  1000 0 0 eth0
  0.0.0.0       172.16.0.254  0.0.0.0         UG 0    0 0 eth0

169.254.0.0 — это zeroconf маршрут.

Для организации туннеля, в конфигурационном файле OpenSSH необходимо разрешить туннелирование. В /etc/ssh/sshd_config нужно добавить строку PermitTunnel point-to-point и перезагрузить OpenSSH сервер service ssh restart

Нюансы:

Дело в том, что для того что-бы организовать туннель, на сервер необходимо авторизироваться под учётной записью root, что не есть хорошо! Поэтому есть два варианта решения проблемы:

1. Ставим на root сложный пароль вида md5 хэша.

2. Настраиваем авторизацию по ключам.

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

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

Подключение к серверу и создание туннеля делается при помощи команды sudo ssh [email protected] -w 0:0

Обязательно делать через sudo или root-а. Будут создаваться tun устройства, что требует привилегий.

Ключ -w создаст tun0 устройства на сервере и клиенте, объединив их между собой.
Вот описание из man-а.
-w local_tun[:remote_tun] Requests tunnel device forwarding with the specified tun(4) devices between the client (local_tun) and the server(remote_tun)
Настройка tun устройств.
На сервере ifconfig tun0 10.0.0.1/30 pointopoint 10.0.0.2
На клиенте ifconfig tun0 10.0.0.2/30 pointopoint 10.0.0.1

Можно протестировать при помощи ping (с компьютера клиента):

    user@host:~$ ping 10.0.0.1 -c 2
    PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
    64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=5.80 ms
    64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=8.61 ms

    --- 10.0.0.1 ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1001ms
    rtt min/avg/max/mdev = 5.800/7.209/8.618/1.409 ms

Сейчас необходимо весь трафик пустить через tun0, для этого требуется просто указать tun0 шлюзом по умолчанию, но при этом потеряется связь с сервером (Home Server) и DNS сервером. Поэтому прежде чем удалить текущий шлюз по умолчанию (172.16.0.254) обязательно нужно добавить маршруты к серверу и DNS серверу в таблицу маршрутизации. Что можно сделать следующим образом:
route add -host 74.125.87.104 gw 172.16.0.254 route add -host 8.8.8.8 gw 172.16.0.254
После чего удаляем текущий шлюз по умолчанию (172.16.0.254) и указываем в качестве шлюза IP адрес, который мы назначили на интерфейсе tun0 сервера (10.0.0.1)
route del default route add default gw 10.0.0.1
Выполнив вышеуказанные действия таблица маршрутизации клиента (Work) принимает следующий вид:

    74.125.87.104  172.16.0.254 255.255.255.255  UGH 0     0 0 eth0
    8.8.8.8        172.16.0.254 255.255.255.255  UGH 0     0 0 eth0
    10.0.0.0       0.0.0.0      255.255.255.252  U   0     0 0 tun0
    172.16.0.0     0.0.0.0      255.255.255.0    U   1     0 0 eth0
    169.254.0.0    0.0.0.0      255.255.0.0      U   1000  0 0 eth0
    0.0.0.0        10.0.0.1     0.0.0.0          UG  0     0 0 tun0

Теперь весь трафик, который направляется в неизвестные подсети, а неизвестные все, кроме адресов 8.8.8.8 и 74.125.87.104, направляется через 10.0.0.1, то есть через ШИФРОВАННЫЙ SSH туннель. Но сервер ничего с ним, трафиком, не делает. Потому что необходимо настроить NAT для клиента. Для этого добавляем правило в iptables
iptables -t nat -A POSTROUTING -s 10.0.0.2 -j MASQUERADE
Включаем в ядре ip forward-инг
sysctl -w net.ipv4.ip_forward=1
Не забываем сделать так, что бы он включался при загрузке системы…
mcedit /etc/sysctl.conf

P.S> mcedit — текстовый редактор. Можно использовать любой другой.

Находим закомментированную строку net.ipv4.ip_forward=1 и раскомментируем её.

Всё, mission complete, теперь весь трафик направляется через ssh туннель и NATится в Internet. Туннель шифрованный, трафик до сервера защищён!

Создание SSH-туннелей с помощью PuTTY

В данной статье будет описано как строить SSH–туннели с помощью PuTTY.

1. Локальный проброс порта

Рассмотрим следующую ситуацию. Мы находимся внутри корпоративной сети, у нашего компьютера адрес 192.168.0.2, доступ во внешний мир полностью закрыт (то есть никакого NAT–а, proxy и т.п.). Влиять на политику ограничения доступа у нас возможности нет, но зато есть SSH–доступ на один из серверов с маршрутизируемым IP–адресом, который доступен из Интернета. Внутренний адрес этого сервера, пусть будет для примера 192.168.0.3. Структура сети изображена на рисунке:

Предположим, что нам очень нужно подключиться, к примеру, по SSH на некоторый удалённый сервер с IP–адресом 212.212.212.212 где–то далеко в Интернет. Для этого запускаем PuTTY, создаём SSH–подключение к серверу 192.168.0.3 (далее по тексту SSH–сессия 1), идём в пункт Tunnels:

и указываем, что локальный порт 2222 нашего компьютера должен быть поставлен в соответствие порту 22 на сервере с IP–адресом 212.212.212.212. Далее жмём кнопку «Open», авторизуемся на сервере 192.168.0.3. Затем создаём ещё одно подключение (далее по тексту SSH–сессия 2), но уже на localhost, порт 2222 и жмём кнопку «Open»:

В результате SSH–сессия 2 будет туннелироваться (т.е. будет установлена внутри ранее установленной SSH–сессии 1). Для удалённого сервера 212.212.212.212 всё будет выглядеть так, как будто к нему подключается 111.111.111.111:

2. Удалённый проброс порта

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

Здесь уже у нас есть возможность подключаться через SSH напрямую к 212.212.212.212 благодаря наличию NAT–а. А вот 212.212.212.212 подключиться на 192.168.0.2 без специальных ухищрений, понятное дело, не сможет, т.к. 192.168.0.2 не подключён к Интернет непосредственно. Предположим, что пользователю, сидящему под X–ами на 212.212.212.212 нужно через remote desktop попасть на наш компьютер 192.168.0.2. Для этого в SSH–сеансе подключения с 192.168.0.2 на 212.212.212.212 нужно изменить настройки в разделе Tunnels следующим образом:

В результате после успешной авторизации на 212.212.212.212 можно увидеть следующее:

#lsof -i -nP | grep 3333
sshd  18598   avz   11u  IPv4 592868957   TCP 127.0.0.1:3333 (LISTEN)

То есть sshd ожидает подключений на TCP–порт 3333, которые затем по SSH–туннелю будут перенаправлены на 192.168.0.2 порт 3389. И юзер сидящий за 212.212.212.212 сможет с помощью rdesktop увидеть наш рабочий стол:

3. Socks–proxy

В этом случае мы можем использовать сервер с SSH–демоном как промежуточный (proxy). Схема сети как в случае #1 (без NAT и штатных прокси):

Чтобы заставить PuTTY исполнять роль socks–прокси, нужно параметры SSH–сессии с 192.168.0.2 на 192.168.0.3 изменить следующим образом:

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

C:\>netstat -ano | find "1080"
  TCP    127.0.0.1:1080     0.0.0.0:0      LISTENING       2392
C:\>tasklist | find /i "2392"
putty.exe                2392 Console        0             5420 КБ

То есть putty, выполняющийся с PID–ом 2392, начинает слушать порт 1080, ожидая подключений. Далее бёрем любое приложение, умеющее работать с SOCKS–прокси, например Firefox, и указываем ему использовать наш прокси:

Теперь все запросы от браузера будут проходить через сервер 192.168.0.3. В логах веб–сайтов, по которым мы таким образом будем ходить, будет отображаться внешний IP–адрес нашего сервера — 111.111.111.111.

P.S. Из help–файла Putty 0.58:

Question A.10.3: What does «PuTTY» mean?

It’s the name of a popular SSH and Telnet client. Any other meaning is in the eye of the beholder. It’s been rumoured that «PuTTY» is the antonym of «getty», or that it’s the stuff that makes your Windows useful… 🙂

avz.org.ua

Как создавать туннели SSH

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

Эти примеры работают из командной строки Linux или терминала macOS. То же самое можно сделать в Windows, используя такие приложения, как putty или mobaXterm.

Перенаправление локального порта ssh

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

Прокси-сервер к удаленному серверу

На изображении выше синий хост не может подключиться к http://192.168.0.3 , но может подключиться к 192.168.0.2 по ssh. Следующая команда ssh, выполняемая на синем узле , позволит синему узлу достичь красного узла.

Теперь синий хост может открыть браузер, перейти по адресу http: // localhost: 8080 и получить веб-страницу, размещенную на 192.168.0.3.

Перенаправление локального порта

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

Команда на синем хосте будет:

Теперь, когда синий хост открывает браузер и переходит на http: // localhost: 8080 , они смогут увидеть все, что есть у красного сервера на порту 80.

Синтаксис перенаправления локального порта

Этот синтаксис для создания локального туннеля переадресации портов ssh следующий:

  ssh -L : :

Перенаправление удаленного порта SSH

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

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

Синий хост инициирует туннель ssh следующим образом:

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

Зеленый хост теперь может использовать ssh для синего хоста следующим образом:

Использование опции -N

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

Автош

Команда autossh используется для добавления постоянства вашим туннелям. Его задача — убедиться, что ваше ssh-соединение установлено, а если нет, создать его.

Вот команда autossh, которую вы можете узнать.

Параметр -i /home/blueuser/.ssh/id_rsa указывает использовать сертификат для аутентификации этого ssh-соединения. Прочтите этот пост, чтобы узнать больше о сертификатах ssh.

Теперь, когда ваш туннель выходит из строя, он автоматически пытается повторно подключиться и продолжать попытки, пока не добьется успеха. Чтобы сделать его постоянным после перезагрузки, добавьте команду ssh в качестве задания cron.

Статьи по теме

SSH Tunnel

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

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

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

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

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

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

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

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

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

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

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

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

туннелей SSH — сценарии OS X

Пока в этой серии сообщений о ssh на macOS:

Пожалуйста, подумайте о поддержке Scripting OS X, купив одну из моих книг!

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

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

SSH-туннели с двумя компьютерами

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

Вы можете использовать переадресацию портов ssh или «туннелирование» для получения доступа к другим службам через ssh .

Представьте, что вы хотите использовать общий доступ к экрану для подключения к удаленному компьютеру Mac ( remote.example.com ). Совместное использование экрана в macOS использует порт VNC 5900 для подключения к удаленному Mac. Поскольку сам VNC по своей природе небезопасен (Mac Screen Sharing добавляет несколько вещей, чтобы сделать его более безопасным), этот порт заблокирован многими брандмауэрами.

Однако у меня есть ssh доступ к remote.example.com . Итак, как мне сказать обеим системам «туннелировать» трафик совместного использования экрана через ssh ?

(При тестировании не забудьте включить доступ «Совместное использование экрана» или «Удаленное управление» (например, удаленный рабочий стол Apple) на панели «Общий доступ» в Системных настройках на удаленном компьютере Mac.)

Туннель начинается на моем локальном компьютере и заканчивается на remote.example.com на порте 5900 (где служба совместного использования экрана прослушивает удаленный компьютер Mac).

Для начальной точки также нужен номер порта, и я могу свободно выбирать.Номера портов ниже 1000 и выше 49000 зарезервированы для системы и требуют привилегий root. Есть также много номеров, которые обычно используются определенными службами (например, 5900 для VNC / общего доступа к экрану) и, возможно, уже используются. Я выберу 5901 для локального порта.

Чтобы подключить локальный порт 5901 к порту 5900 на удаленном Mac, используйте следующую команду:

  $ ssh -N -L локальный хост: 5901: локальный хост: 5900 remote.example.com

(Вы можете просто попробовать это со вторым Mac или виртуальной машиной в сети, даже без брандмауэра.)

Синтаксис этой команды менее чем очевиден. Разобьем на части:

Параметр -N сообщает ssh , что мы не хотим вызывать удаленную оболочку или запускать удаленную команду.

Параметр -L создает настройку переадресации локального порта. Эта опция принимает параметр из трех или четырех частей, разделенных двоеточиями : . Первая пара ( localhost: 5901 ) — начальная точка туннеля. Вторая пара ( localhost: 5900 ) — это удаленная конечная точка туннеля.

Второй локальный хост разрешен как на удаленном хосте , поэтому это означает порт 5900 на удаленном хосте.

Последний параметр указывает удаленный хост, к которому нужно подключиться, remote.example.com .

Эти команды говорят ssh подключиться к remote.example.com и установить туннель, который передает трафик с порта 5901 на моем компьютере на порт 5900 на удаленном компьютере.

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

  $ ssh -N -L 5901: локальный: 5900 remote.example.com

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

Итак, когда вы открываете приложение общего доступа к экрану (из / System / Library / CoreServices / Applications / ) и подключаетесь к localhost: 5901 , весь трафик будет перенаправлен ssh на порт 5900 на удаленном Mac.

Вы также можете использовать команду open для подключения к совместному использованию экрана:

  $ открыть vnc: // localhost: 5901

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

Когда вы закончите сеанс совместного использования экрана, вы можете завершить туннельный процесс ssh в Терминале с помощью ctrl-C.

Вы также можете использовать порт ssh для использования удаленного хоста в качестве шлюза или «хоста перехода» к третьему компьютеру.Представьте, что вы хотите использовать общий доступ к экрану для подключения к secundus.example.com за брандмауэром, и у вас есть только ssh -соединение с primus.example.com . Вы можете указать primus указать конечную точку туннеля ssh на secundus с помощью:

  $ ssh -N -L 5902: secundus.example.com: 5900 primus.example.com

Примечание: secundus.example.com или любой другой хост или IP-адрес, который вы вводите, будет разрешен как на удаленном узле .Таким образом, вы можете использовать здесь IP-адреса NAT или имена хостов .local , даже если они не имеют смысла в сети, в которой находится ваш рабочий Mac. (Хотя они или должны иметь смысл на удаленном хосте, иначе вы получит ошибку.)

В следующих примерах локальный IP-адрес 192.168.1.200 или имя хоста Bonjour Secundus.local будут разрешены на удаленном узле, даже если они не работают на моем локальном компьютере:

  $ ssh -N -L 5902: 192.168.1.200: 5900 primus.example.com
$ ssh -N -L 5902: Secundus.local: 5900 primus.example.com

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

Имейте в виду, что хотя соединение от начальной точки (на вашем Mac) к хосту primus защищено ssh , соединение от primus к secundus - нет.

`Обнаружение HTTP-хостов`

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

Например, я хотел использовать переадресацию портов ssh , чтобы получить доступ к веб-интерфейсу моего домашнего маршрутизатора. Я могу использовать «Back to My Mac» для ssh в одном из iMac дома и подумал, что должно быть легко подключиться к маршрутизатору с помощью туннеля ssh :

  $ ssh -N -L 8080: 192.168.1.1: 80 mac.example.com

Похоже, это сработало, но всякий раз, когда я пытался указать браузеру на localhost: 8080 , он не мог подключиться к веб-странице. Проблема здесь в , а не в туннеле ssh , а в веб-сервере на маршрутизаторе. В рамках запроса http браузер отправляет запрошенное имя домена на веб-сервер. Это позволяет веб-серверам размещать разные страницы для разных доменов. В этом запросе браузер сообщил маршрутизатору, что ему нужна веб-страница для localhost , и маршрутизатор ответил: «Я не обслуживаю страницы для этого хоста»… (Ваш маршрутизатор может вести себя иначе.)

С curl я мог убедить маршрутизатор обслуживать мне страницу с:

  curl -H "Хост: 192.168.1.1" http: // localhost: 8080

Однако, поскольку навигация по веб-интерфейсу маршрутизатора с curl исключена, мне пришлось найти другое решение.

`Тоннель Всё!`

Что, если бы я мог отправлять всего трафика через iMac дома?

командой

  $ ssh -N -D 9001 удал.example.com

Я могу создать туннель со своего компьютера (через порт 9001) на удаленный Mac, который действует как прокси-сервер SOCKS. Затем я могу установить прокси-сервер Socks на localhost: 9001 на вкладке прокси на панели «Сеть» в Системных настройках. Возможно, вы захотите создать новое сетевое расположение для этой настройки. Затем весь сетевой трафик будет безопасно маршрутизироваться через туннель ssh на мой домашний Mac, где он может подключиться к маршрутизатору.

Это также может служить временным решением VPN.

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

`Сводка`

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

Предыдущий пост: Передача файлов с помощью ssh

`Связанные`

.

`Добро пожаловать в документацию sshtunnel! - sshtunnel 0.0.8 документация`

sshtunnel находится на PyPI, поэтому просто запустите:

или

 установка conda -c conda-forge sshtunnel

, чтобы он был установлен в вашей среде.

Для установки из исходников клонируйте репо и запуск:

`Тестирование пакета`

Для запуска тестов вам в первую очередь потребуется tox и запустить:

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

 ------------------------------------------------- ---------------------

                            |
------------- + | + ---------- +
    МЕСТНЫЙ | | | УДАЛЕННЫЙ | : 22 SSH
    КЛИЕНТ | <== SSH ========> | СЕРВЕР | : 8080 веб-сервис
------------- + | + ---------- +
                            |
                         ФЕЙЕРВОЛЛ (открыт только порт 22)

-------------------------------------------------- --------------------

Рис. 1 : Как подключиться к службе, заблокированной брандмауэром, через туннель SSH.

Если это разрешено SSH-сервером, также возможно получить доступ к частному серверу. (с точки зрения REMOTE SERVER ) не виден непосредственно с снаружи (перспектива МЕСТНЫЙ КЛИЕНТ ).

 ------------------------------------------------- ---------------------

                            |
------------- + | + ---------- + + ---------
    МЕСТНЫЙ | | | УДАЛЕННЫЙ | | ЧАСТНЫЙ
    КЛИЕНТ | <== SSH ========> | СЕРВЕР | <== local ==> | СЕРВЕР
------------- + | + ---------- + + ---------
                            |
                         ФЕЙЕРВОЛЛ (открыт только порт 443)

-------------------------------------------------- --------------------

Рис. 2 : Как подключиться к ЧАСТНОМУ СЕРВЕРУ через туннель SSH.

API позволяет либо инициализировать туннель и запустить его, либо использовать с context, который позаботится о запуске и остановке туннеля:

`Пример 1`

Код, соответствующий Fig1 выше, следует, учитывая, что адрес удаленного сервера pahaz.urfuclub.ru , аутентификация по паролю и случайно назначенная локальная привязка порт.

 из sshtunnel import SSHTunnelForwarder

сервер = SSHTunnelForwarder (
    'пахаз.urfuclub.ru ',
    ssh_username = "пахаз",
    ssh_password = "секрет",
    remote_bind_address = ('127.0.0.1', 8080)
)

server.start ()

print (server.local_bind_port) # показать назначенный локальный порт
# работать с `SECRET SERVICE` через` server.local_bind_port`.

server.stop ()

`Пример 2`

Пример переадресации порта на частный сервер, недоступный напрямую, при условии защищенной паролем аутентификации pkey служба SSH удаленного сервера прослушивание порта 443, и этот порт открыт в брандмауэре ( Fig2 ):

 импорт парамико
из sshtunnel импортировать SSHTunnelForwarder

с SSHTunnelForwarder (
    (REMOTE_SERVER_IP, 443),
    ssh_username = "",
    ssh_pkey = "/ var / ssh / rsa_key",
    ssh_private_key_password = "секрет",
    remote_bind_address = (PRIVATE_SERVER_IP, 22),
    local_bind_address = ('0.0,0.0 ', 10022)
) как туннель:
    client = paramiko.SSHClient ()
    client.load_system_host_keys ()
    client.set_missing_host_key_policy (paramiko.AutoAddPolicy ())
    client.connect ('127.0.0.1', 10022)
    # делаем некоторые операции с клиентской сессией
    client.close ()

print ('ФИНИШ!')

`Пример 3`

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

 из sshtunnel import SSHTunnelForwarder
от времени импортный сон

с SSHTunnelForwarder (
    ('localhost', 2222),
    ssh_username = "бродяга",
    ssh_password = "бродяга",
    remote_bind_address = ('127.0,0.1 ', 3306)
) как сервер:

    печать (server.local_bind_port)