wwwoldi.ru

About Me

Dashy

Hello word I am dashy Guy

Разное

Ssh туннель обратный: 🌑 Обратный туннель SSH — Information Security Squad

alexxlab
No Comments

Содержание

Туннели через SSH — Записная книжка IT-шника — ЖЖ

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

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

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

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

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

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

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

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

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

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig

# Используем протокол SSH версии 2
Protocol 2

# Включаем режим Privileged Separation для большей безопасности
UsePrivilegeSeparation yes

# Запрещаем вход от имени root
PermitRootLogin no

# Запрещаем пустые пароли
PermitEmptyPasswords no

# Включаем перенаправление X11
X11Forwarding yes
X11DisplayOffset 10

# Терпеть не могу сообщений Motd
PrintMotd no

# Оно живее всех живых!
TCPKeepAlive yes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ssh -D 5222 [email protected] -N

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

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

Припоминаете, что вы добавили «X11Forwarding yes» в sshd_config? Это-то и позволяет пробрасывать сеансы X.

ssh -X -p 2022 [email protected]

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

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

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

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

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

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

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

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

    ssh -R remoteport:localhost:22 username@servername

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

    ssh -p  remoteport  localhost

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

Как работает 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

Обратный туннель для доступа по RDP с использованием putty и icinga2 / Хабр

Не всегда есть возможность организовать единую локальную сеть в силу разных обстоятельств, но есть необходимость в удаленном доступе по протоколу RDP к хостам за натом с серым ip, например небольшой удаленный филиал с каналом связи через сотовую связь. Да, конечно можно поднять что-то вроде openVPN или воспользоваться TeamViewer, но опять же такие варианты не всегда приемлемы. Будем использовать icinga2, putty, SSH сервер и пару скриптов на powershell.


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

Установка SSH сервера:

sudo apt-get install openssh-server

Создание пользователя без доступа к шелу:

sudo useradd -d /dev/null -s /dev/null ssh_user
sudo passwd ssh_user

На всякий случай изменим порт по умолчанию с 22 на 2201. Это можно сделать изменив параметр Port в файле /etc/ssh/sshd_config.

Создаем туннель. На удаленном сервере (к которому в итоге мы хотим подключиться) необходимо каким-то способом выполнить команду:

plink.exe -batch -P 2201 -N -C -v -R 33899:localhost:3389 [email protected] -pw password

А на компьютере администратора выполнить команды:

plink.exe -P 2201 -N -C -v -L 3379:localhost:33899 [email protected] -pw password
mstsc.exe /v localhost:3379

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

Самое простое решение это создать задачу в планировщике которая каждые n минут будет опрашивать какой то ресурс в интернете на наличие определенного флага к действию и при обнаружении этого флага создавать туннель с отправкой email на наш адрес. Мы же сделаем все изящнее, воспользуемся системой мониторинга которая у нас установлена, например такой как icinga2. В этом случае удаленному серверу с установленным агентом можно будет просто послать команду на создание туннеля в нужный нам момент времени.

Если вы еще не сталкивались с этой системой мониторинга, рекомендую посмотреть:

Создадим сервис в icinga2 для создания туннеля:

apply Service "create-rdp-tunnel" {
    enable_active_checks = false
    max_check_attempts = 2
    assign where host.name == NodeName
    ignore where host.vars.os == "Linux"
    check_command = "powershell"
    vars.ps_command = "c:\\ProgramData\\icinga2\\Scripts\\icinga2\\create_rdp_tunnel.ps1"
}

Теперь нужно распространить скрипт создания туннеля и файл plink.exe на агенты. В предыдущей статье было описано как это можно сделать с помощью icinga2.Скрипт создания туннеля

<#
icinga2scripts
Version 1.0
Description: Скрипт для Icinga 2 - Создание ssh туннеля с удаленным хостом
Pavel Satin (c) 2016
[email protected]
#>
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8

$returnStateOK = 0
$returnStateWarning = 1
$returnStateCritical = 2
$returnStateUnknown = 3


$portnum = "338" + (Get-Random -minimum 10 -maximum 99).ToString()


$tunnelcmd = "c:\ProgramData\icinga2\Scripts\icinga2\plink.exe"
$tunnelarg = "-batch -P 2201 -N -C -v -R " + $portnum + ":localhost:3389 [email protected] -pw password"


$regSSHkey = "HKCU:\Software\SimonTatham\PuTTY\SshHostKeys"
$regSSHname = "rsa2@2201:222.222.222.222"
$regSSHval = "0x10001,0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"

if (!(Test-Path $regSSHkey -PathType Any)) {
	New-Item -Path $regSSHkey -Force | Out-Null
	New-ItemProperty -Path $regSSHkey -Name $regSSHName -Value $regSSHval -PropertyType String -Force | Out-Null
} else {
	New-ItemProperty -Path $regSSHkey -Name $regSSHName -Value $regSSHval -PropertyType String -Force | Out-Null
}


$process = (start-process $tunnelcmd -argumentlist $tunnelarg -PassThru)

Start-Sleep -s 5

if ($process.HasExited) {
    Write-Host "Failed to start plink. The process is closed with the code: " $process.ExitCode
    [System.Environment]::Exit($returnStateCritical)
} else {

    #Отправка pushover сообщения
    $uri = "https://api.pushover.net/1/messages.json"
    $parameters = @{
        token = "API_TOKEN"
        user = "API_USER"
        message = "Создан туннель на порту: $portnum с узлом: $env:computername"
    }
    
    $pushoverreq = $parameters | Invoke-RestMethod -Uri $uri -Method Post

    Write-Host "OK - The tunnel is created. Port number: $portnum"
    Write-Host "To connect:"
    Write-Host "plink.exe -P 2201 -N -C -v -L 3379:localhost:$portnum [email protected] -pw password"
    [System.Environment]::Exit($returnStateOK)
}

В скрипте учтен такой момент как запрос на сохранение ssh ключей удаленного сервера. Если на удаленном сервере ни разу не выполнялось подключение к вашему SSH серверу, putty будет выдавать предупреждение при подключении, а plink вообще откажется подключаться.
Что бы избежать этого, нужно подключиться к SSH серверу с любой другой машины, выдернуть из реестра кэшированные ключи (HKCU:\Software\SimonTatham\PuTTY\SshHostKeys) и изменить переменную $regSSHval в скрипте. Скрипт создает подключение к псевдослучайному номеру порта, что поможет избежать конфликтов при множестве соединений. Так же скрипт отправляет push сообщение с помощью сервиса pushover.net.

Отправим команду агенту на создание туннеля. Это можно сделать через веб-интерфейс или в консоли нашего сервера мониторинга:

/bin/echo "[`date +%s`] SCHEDULE_FORCED_SVC_CHECK;ИмяНоды;create-rdp-tunnel;`date +%s`" >> /var/run/icinga2/cmd/icinga2.cmd

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

<#
icinga2scripts
Version 1.0
Description: Скрипт для Icinga 2 - Запуск RemoteDesktop через туннель
Pavel Satin (c) 2016
[email protected]
#>

$returnStateOK = 0
$returnStateWarning = 1
$returnStateCritical = 2
$returnStateUnknown = 3

#Windows Balloon
[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
$objNotifyIcon = New-Object System.Windows.Forms.NotifyIcon 

if ($args[0] -eq $null) {

    $objNotifyIcon.Icon = "C:\Scripts\images\icinga.ico"
    $objNotifyIcon.BalloonTipIcon = "Error" 
    $objNotifyIcon.BalloonTipText = "Параметр с именем хоста не передан! Работа скрипта завершена."
    $objNotifyIcon.BalloonTipTitle = "Подключение через туннель"
 
    $objNotifyIcon.Visible = $True 
    $objNotifyIcon.ShowBalloonTip(30000)

    Start-Sleep -s 10
    $objNotifyIcon.Visible = $false
    $script:objNotifyIcon.Dispose()
    exit
}

$rdpHost = $args[0]

$plinkPath = "C:\Scripts\bin\"

add-type -TypeDefinition  @"
        using System.Net;
        using System.Security.Cryptography.X509Certificates;
        public class TrustAllCertsPolicy : ICertificatePolicy {
            public bool CheckValidationResult(
                ServicePoint srvPoint, X509Certificate certificate,
                WebRequest request, int certificateProblem) {
                return true;
            }
        }
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy

$user = "icinga"
$pass= "password"
$secpasswd = ConvertTo-SecureString $pass -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential($user, $secpasswd)
$apiurl = "https://222.222.222.222:5665/v1/objects/services/" + $rdpHost + "!create-rdp-tunnel?attrs=last_check_result"

$apireq = Invoke-WebRequest -Credential $credential -Uri $apiurl -Method Get -UseBasicParsing -ContentType "text/plain; charset=Windows-1251"

$outputresult = $apireq | ConvertFrom-Json | Select -expand Results | Select -expand attrs | Select -expand last_check_result 
$strOutput = $outputresult.output
$indxPlink = $strOutput.IndexOf("plink")

$portnum = "339" + (Get-Random -minimum 10 -maximum 99).ToString()

$strOutput2 = $strOutput.Substring($indxPlink, $strOutput.Length - $indxPlink)

$cmdArgs = "/C " + $strOutput2.Replace("3379", $portnum)
$mstscArgs = "/v localhost:$portnum"

#Запуск процессов
Start-Process cmd.exe $cmdArgs
Start-Process mstsc.exe $mstscArgs

$objNotifyIcon.Icon = "C:\Scripts\images\icinga.ico"
$objNotifyIcon.BalloonTipIcon = "Info" 
$objNotifyIcon.BalloonTipText = "Устанавливаем подключение к $rdpHost"
$objNotifyIcon.BalloonTipTitle = "Подключение через туннель"
 
$objNotifyIcon.Visible = $True 
$objNotifyIcon.ShowBalloonTip(30000)

Start-Sleep -s 30
$objNotifyIcon.Visible = $false
$script:objNotifyIcon.Dispose()
Ссылки

→ Putty
→ Используем powershell скрипты в icinga2

Создание SSH-туннеля. Часть первая. Категория: ОС Linux • Разное


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


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


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


За TCP Port Forwarding отвечает опция AllowTcpForwarding в файле конфигурации SSH-сервера. По умолчанию она имеет значение yes, так что дополнительные настройки не нужны.

Проброс локального соединения на удаленную машину


Синтаксис команды: 

$ ssh -L [ЛокальныйАдрес:]ЛокальныйПорт:АдресНазначения:ПортНазначения Пользователь@УдаленныйСервер
         \_____________  _____________/ \_____________  _____________/              \______  _____/
                       \/                             \/                                   \/
                   точка входа                пункт назначения                        точка выхода


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

Проброс удаленного соединения на локальную машину


Для совершения обратного действия нужно выполнить команду с ключом -R: 

$ ssh -R [УдаленныйАдрес:]УдаленныйПорт:АдресНазначения:ПортНазначения Пользователь@УдаленныйСервер
         \_____________  _____________/ \_____________  _____________/
                       \/                             \/               точка выхода — хост, где
                   точка входа                пункт назначения         выполняется эта команда


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


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

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


У меня физический компьютер с двумя виртуальными машинами. На физической машине — Windows 10 и установлены web-сервер Apache и сервер БД MySQL. На виртуальной машине ssh-server — Ubuntu 18.04 и установлен SSH-сервер. На виртуальной машине web-server — Ubuntu 18.04 и установлен web-сервер Apache и сервер БД MySQL.

  • Физическая машина TKMCOMP, ОС Windows 10, ip-адрес 192.168.110.2

  • Виртуальная машина ssh-server, ОС Ubuntu 18.04, ip-адрес 192.168.110.8

  • Виртуальная машина web-server, ОС Ubuntu 18.04, ip-адрес 192.168.110.12



Все машины находятся в одной локальной сети — для удобства проведения экспериментов с построением туннелей. Хотя с практической точки зрения нужен компьютер с белым ip-адресом и с установленным ssh-сервером — который будет посредником между двумя компьютерами с серыми ip-адресами.


На виртуальной машине web-server работает web-сервер Apache — если на физическом компьютере открыть в браузере страницу http://192.168.110.12, то увидим дефолтную страницу Apache:



На физической машине TKMCOMP тоже работает web-сервер Apache — если открыть в браузере страницу http://127.0.0.1, то увидим вывод php-функции phpinfo():



На виртуальной машине ssh-server необходимо открыть порт для ssh-соединений. У меня это — 2222: 

$ sudo ufw allow 2222/tcp
Правило добавлено
Правило добавлено (v6)
$ sudo ufw status verbose
Состояние: активен
Журналирование: on (low)
По умолчанию: deny (входящие), allow (исходящие), disabled (маршрутизированные)

В                          Действие    Из
----------------------------------------------------
2222/tcp                   ALLOW IN    Anywhere
2222/tcp (v6)              ALLOW IN    Anywhere (v6)

Проброс локального соединения на удаленную машину


Открываем на физической машине PowerShell и выполняем команду: 

> ssh -p 2222 -L 127.0.0.1:8080:192.168.110.12:80 [email protected]
  • точка входа в туннель — физическая машина TKMCOMP, интерфейс localhost

  • точка выхода из туннеля — виртуальная машина ssh-server, интерфейс localhost

  • пункт назначения tcp-пакетов — виртуальная машина web-server




Теперь у нас есть туннель от 192.168.110.2 до 192.168.110.8: пакеты от физической машины попадают в туннель и будут получены виртуальной машиной ssh-server. А поскольку пункт назначения 192.168.110.12 — пакеты будут направлены дальше в сеть, к виртуальной машине web-server.


На физической машине открываем в браузере страницу http://127.0.0.1:8080 — и видим дефолтную страницу Apache:


Проброс удаленного соединения на локальную машину


Открываем на физической машине PowerShell и выполняем команду: 

> ssh -p 2222 -R 127.0.0.1:8080:127.0.0.1:80 [email protected]
  • точка входа в туннель — виртуальная машина ssh-server, интерфейс localhost

  • точка выхода из туннеля — физическая машина TKMCOMP, интерфейс localhost

  • пункт назначения tcp-пакетов — физическая машина TKMCOMP (пакеты предназначены ей)




Теперь у нас есть туннель от 192.168.110.8 до 192.168.110.2: пакеты от виртуальной машины ssh-server попадут в туннель и будут получены физической машиной. Откроем на виртуальной машине ssh-server браузер и наберем в адресной строке http://192.168.110.8:8080 или http://127.0.01:8080. Мы видим вывод функции phpinfo() от web-сервера физической машины:



Однако, если мы откроем браузер на виртуальной машине web-server и наберем в адресной строке http://192.168.110.8:8080 — то ничего не увидим:



Пакеты от виртуальной машины web-server придут на сетевой интерфейс enp0s3 виртуальной машины ssh-server. А перенаправляются в туннель только те пакеты, которые пришли на интерфейс обратной петли loopback. Чтобы это исправить, нужно изменить настройки ssh-сервера — отредактировать файл конфигурации /etc/ssh/sshd_config: 

GatewayPorts yes
$ sudo systemctl restart ssh



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


Обновляем страницу http://192.168.110.8:8080 на виртуальной машине web-server:



Поиск:
CLI • Linux • SSH • Ubuntu • Windows • Команда • Туннель • Сервер • Клиент • Порт • Конфигурация • Настройка

Проброс портов через SSH-туннель в Windows

В этой статье мы покажем, как использовать встроенный в Windows OpenSSH сервер для проброса портов через SSH туннель (SSH туннелированние). Перенаправление портов в SSH позволяет туннелировать (пробрасывать) порты приложений с локального компьютера на удаленный сервер и наоборот. Ранее проброс портов через SSH туннель использовался только в среде Linux/Unix , но теперь вы можете воспользоваться этим возможностями и в Windows. Рассмотрим на практическом примере, как на Windows Server через SSH сервер с открытым портом TCP 22 пробросить RDP подключение.

Чаще всего проброс портов через SSH применяется в сценариях, когда нужно подключиться к удаленному компьютеру, который защищен межсетевым экраном. Например, у вас имеется сервер c Windows, на котором открыт только SSH порт (TCP 22). Все остальные порты блокируются аппаратным межсетевым экраном или брандмауэром Windows. Ваша задача подключиться к рабочему столу этого Windows сервера с помощью клиента RDP. Казалось бы, невозможная задача, т.к. порт RDP 3389 блокируется брандмауэром. Однако вы можете воспользоваться технологией проброса портов через ssh-тунель.

Чаще всего используются следующие сценарии проброса SSH:

  • Local TCP forwarding — проброс локального порта на удаленный сервер;
  • Remote TCP forwarding — проброс удаленного порта на локальный компьютер;
  • Двойной SSH туннель – позволяет соединить между собой через SSH сервер компьютеры без выделенных белых IP адресов или находящиеся за NAT (если не подходит решение с OpenVPN)

RDP доступ через SSH туннель (local TCP forwarding)

В этом режиме вы создаете на своем компьютере локальный TCP порт, подключения к которому перенаправляются через SSH туннель на указанный порт удаленного сервера. В этом примере мы создадим локальный порт 8888, при подключении к которому выполняется перенаправление с этого порта на RDP порт 3389 удаленного компьютера. Общая схема подключения выглядит так:

Для создания SSH туннеля с помощью встроенного SSH клиента (встроен в Windows 10 1809 и Windows Server 2019), выполните команду:

ssh -L 8888:192.168.1.90:3389 [email protected]

Чтобы SSH туннель работал в фоновом режиме, нужно добавит параметр –f.

Теперь, чтобы подключится к удаленному компьютеру через SSH туннель, вам нужно подключится RDP-клиентом mstsc.exe на локальный порт 8888 своего компьютера:

127.0.0.1:8888

Авторизуйтесь на удаленном компьютере и можете спокойно работать в RDP-сессии, при этом вы помните, что порт 3389 все еще закрыт в файерволе. С помощью TCPView вы можете убедиться, что RDP подключение установлено локально (RDP подключение инициировано запущенным локально SSH сервером).

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

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

mstsc.exe /v 10.10.1.220:8888

Переброс удаленного порта на локальную машину (Remote TCP forwarding)

Есть еще один вариант применения SSH туннеля – remote TCP forwarding. Через SSH туннель вы можете открыть доступ удаленному серверу к локальному порту на вашем компьютере или порту на другом компьютере в вашей локальной сети. Например, вы хотите, чтобы внешний сервер (192.168.1.90) получил доступ к вашему Интранет сайту (не опубликованному в Интернете). Для создания обратного туннеля, используйте такую команду:

ssh -R 8080:internalwebsever:80 [email protected]

Теперь, чтобы на удаленном SSH сервер получить доступ к веб серверу internalwebsever достаточно в браузере набрать адрес http://localhost:8080.

С помощью SSH туннелей вы можете строить целые цепочки для форвардинга портов. Включить или отключить SSH туннелирование можно в конфигурационном файле sshd_config директивами:

AllowStreamLocalForwarding yes

AllowTcpForwarding remote

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

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

Терминология

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

Клиент — компьютер-источник запросов. Например, браузер или ssh-клиент.
Сервер — компьютер-обработчик запросов. Например, десктоп в локальной сети.
Базовая схема — схема взаимодействия, в которой участвуют лишь Клиент и Сервер.
Расширенная схема — расширение базовой схемы, когда Клиент и Сервер опосредованы Прокси.
Прокси — компьютер-посредник между Клиентом и Сервером в расширенной схеме.
Прямой туннель — туннель, в котором направление инициирования SSH-сесии и запросов совпадают.
Обратный туннель — направление инициирования SSH-сессии и клиентских запросов противоположны.
Source port (исходный порт) — порт на одном из концов туннеля, куда приходит запрос от Клиента.
Может быть для PuTTY локальным «Local» (на том же конце туннеля, что и PuTTY) и удалённым «Remote» (на противоположном конце).
Destination (адрес назначения) — IP-адрес и порт компьютера, для которого предназначены пакеты, выходящие из туннеля. В расшриренной схеме это всегда сам Сервер.

Принцип работы SSH-туннеля

SSH-туннели создаются для решения 2-х независимых задач:

  1. Обеспечение конфиденциальности данных, передаваемых по защищённому каналу
  2. Создание связующего мостика (или нескольких мостиков) между Клиентом и Сервером через промежуточные компьютеры, так как Клиент может не иметь прямого доступа к Серверу. В этом случае конфиденциальность является второстепенной или вовсе не требуется.

SSH-туннели могут быть организованы как в режиме перенаправленя отдельных TCP-портов (Port forwarding), так и в режиме настоящих VPN-туннелей через виртуальные интерфейсы, когда передаваться может трафик любых протоколов и с любых портов. В данной статье мы рассмотрим первый режим.

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

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

Стрелкой указано направление инициирования SSH-сессии. В данном случае инициатором соединения выступает Клиент с установленным на нём PuTTY.

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

Для установления связи по SSH-протоколу необходима учётная запись на SSH-сервере, которая может быть любой, в том числе без каких бы то ни было прав и даже без шелла, если вы открываете на прослушивание непривелигированные порты от 1024 и выше. В противном случае необходим рутовый доступ и значение директивы PermitRootLogin равное yes или without-password.

Анализ связности и доступности участников взаимодействия

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

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

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

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

В частности, мы соединяем стрелкой Клиента с Прокси, если Прокси доступен с Клиента на 22-м порту. Перебрав попарно всех участников взаимодействия, получим схему связности. Например:

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

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

Схема доступности показывает, в каком направлении можно передать данные по незащищённому туннелем каналу.

Комбинация обеих схем помогает ответить на вопрос о том, имеется ли принципиальная возможность установления соединения Клиента с Сервером, а если её нет, то что надо добавить, чтобы её получить.

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

Приведённая выше схема очень распространена: Клиент и Сервер (чаще всего на базе Windows) находятся в разных локальных сетях за NAT, имеют выход в интернет и «видят» удалённый Прокси-сервер, тогда как с Прокси они недоступны ни по SSH ни по другим протоколам. На Прокси, как правило, установлена *nix-подобная операционная система, в которой SSH-сервер есть по умолчанию.

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

Далее в статье стрелка SSH-связности указываться не будет, так как совпадает с направлением инициирования туннеля.

Алгоритм построения канала связи с помощью SSH-туннелей

Разберём алгоритм построения канала связи с помощью SSH-туннеля на примере схемы, приведённой выше, где Клиент и Сервер находятся в разных локальных сетях за NAT-ами, и могут быть связаны только через Интернет с помощью некоторого Прокси-сервера.

1) Составление схемы SSH-связности

SSH-сервер у нас имеется только на Прокси, поэтому мы можем инициировать 2 туннеля: с Клиента и с Сервера:

Это схема с двумя односвязными звеньями.

2) Составление схемы доступности

Клиент и Сервер находятся за NAT, поэтому недоступны извне с Прокси, но Прокси пингуется как с Клиента, так и с Сервера

3) Выбор звена для создания туннеля

Для обеспечения связи между Клиентом и Сервером достаточно одного туннеля — либо Клиент-Прокси, либо Прокси-Клиент, так как на оставшемся участке пакеты можно передать по незащищённому каналу.

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

Пакеты, поступающие на вход туннеля на компьютере Клиента, передаются на Прокси и затем должны перенаправляться на адрес назначения (Destination), которым является Сервер. Однако согласно схеме доступности, Сервер недоступен с Прокси через интернет:

Поэтому для передачи пакетов не обойтись без создания второго туннеля между Прокси и Сервером:

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

Туннель Клиент-Прокси можно оставить лишь в том случае, если это важно с точки зрения конфиденциальности (по нему что-то передаётся открытым текстом и т.п.).

4) Выбор типа туннеля Прокси-Сервер: прямой или обратный

На самом деле тип туннеля уже предопределён. Запросы клиента поступают на порт источника (Source Port), который находится на Прокси, а туннель инициируется с Сервера. Это значит, что направление инициирования туннеля и запросов клиента будут противоположны. Следовательно туннель будет обратным (опция -R).

5) Прописывание параметров подключения и создания туннеля

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

  1. Составить схему SSH-связности, исходя из расположения SSH-серверов
  2. Составить схему доступности.
  3. Выбрать звено: Клиент-Прокси или Прокси-Сервер (для расширенной схемы)
  4. Выбрать направление инициирования туннеля, если звено полносвязное.
  5. Выбрать тип туннеля, отталкиваясь от направления запросов клиента: прямой или обратный
  6. Написать формулы проброса портов в PuTTY (Source port, Destination и дополнительные опции) для каждого туннеля

Понимая описанные выше принципы, легко выставить правильные настройки как на вкладке SSH-Tunnels в PuTTY, так и в командной строке OpenSSH-клиента. В частности, справедливы следующие аксиомы:

Source port — это порт туннеля, на который поступают запросы Клиента.
Если направление инициирования туннеля и запросов Клиента совпадают (прямой туннель), то порт находится на том же конце, что и PuTTY и является для PuTTY локальным (опция -L, Local).
В противном случае Source port находится на противоположной стороне обратного туннеля и для PuTTY является удалённым (опция -R, Remote)
В 99% случаев Source port открывается на прослушивание на петлевом интерфейсе той машины, на которую приходят запросы от Клиента, и поэтому обычно опускается. В PuTTY для IP-адреса источника запросов даже не предусмотрено отдельного места — только Source port.

Destination — это IP-адрес и порт компьютера, на который передаются данные на выходе из туннеля. Если PuTTY находится на Destination, то это, очевидно, будет localhost.
В отличие от петлевого IP-адреса на входе туннеля, данные на выходе из туннеля могут передаваться куда угодно, в том числе на хосты с другими IP-адресами.

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

Приведу, также, синтаксис командной строки OpenSSH клиента в терминах PuTTY, если вы захотите инициировать туннель с какой-нибудь *nix-системы по базовой схеме:

ssh [-g] [-p port] [Source port]:[Destination] user@Сервер

и по расширенной схеме:

ssh [-g] [-p port] [Source port]:[Destination] user@Прокси

Здесь под [Source port] понимается порт с ключами, например: -L 5000 (прямой туннель), -R 5000 (обратный туннель) или -D 5000 (динамический проброс порта; в этом случае [Destination] опускается)
[-p port] — соединиться с Сервером или Прокси на порт, отличный от 22.
[-g] — опция, разрешающая подключение к локальному (Local) или динамическому (Dynamic) порту не только с localhost, но и с внешних адресов.

Для разрешения аналогичной возможности подключения к удалённому (Remote) порту с внешних адресов необходимо прописать в конфигурационном файле SSH-сервера /etc/ssh/sshd_config опцию:

GatewayPorts clientspecified

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

GatewayPorts yes

когда эта опция включена всегда.

Базовая схема

В базовой схеме взаимодействия участвуют лишь 2 компьютера, соединённые туннелем.

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

Расширенная схема

Расширением базовой схемы является схема с промежуточным прокси-сервером, к которому либо подключается Клиент, либо с которого устанавливается соединение с Сервером. Здесь возможны 4 варианта.

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

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

Для полноты картины ниже рассмотрен и синтаксис OpenSSH клиента в терминах PuTTY, если вдруг вам понадобится инициировать туннель с помощью OpenSSH.

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

1. Прямой туннель по базовой схеме

Схема связности и доступности для системы с Клиентом за NAT:

Рассмотрим защиту открытого протокола от перехвата на примере POP3.

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

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

Эквивалентная команда для OpenSSH клиента:

Клиент# ssh -L 5000:Сервер:110 user@Сервер

2. Обратный туннель по базовой схеме

Схема связности и доступности для системы с Сервером за NAT:

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

Для поднятия обратного туннеля на Клиент необходимо установить SSH-сервер и указать, с какого удалённого порта (Remote Source port) на какой локальный для PuTTY будет выполняться проброс.

Эквивалентная команда для OpenSSH клиента:

Сервер# ssh -R 5000:localhost:3389 user@Клиент

3. Прямой туннель на SOCKS proxy

Схема связности и доступности для системы с Клиентом за NAT:

Такая схема позволяет безопасно подключаться к интернету через непроверенные источники, например Wi-Fi точки доступа в кафе и ресторанах. Весь трафик идёт через точку доступа в зашифрованном виде с удалённого Сервера.

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

Поскольку браузеры не умеют работать через SSH-туннели напрямую, в настройках подключения через прокси-сервер нужно выбрать подключение через SOCKS (v5) на адрес localhost:5000 и удалить localhost или 127.0.0.1 из поля «Не использовать прокси для:», если он там прописан автоматически.

Эквивалентная команда для OpenSSH клиента:

Клиент# ssh -D 5000 user@Сервер

Добавляя опцию -g, которая эквивалентна опции PuTTY «Local ports accept connections from other hosts», можно разрешить другим компьютерам подключаться к Клиенту на указанный порт и превратить его, таким образом, в точку доступа.

4. Обратный туннель на SOCKS Proxy

Схема аналогична предыдущей, только с обратной схемой связности (Клиенту запрещён выход в интернет).

Это значит, что инициировать туннель мы можем только с Сервера. Очевидно, что на Клиенте должен быть развёрнут SSH-сервер. Для Клиентов на базе Windows хорошим выбором будет Bitvise SSH-сервер на 443 порту. FreeSSHd сервер с обратными туннелями у меня не заработал.

Итак, чтобы схема работала, нужно сделать из Сервера Socks proxy на 5000-м порту, создав туннель с самим собой:

Сервер# ssh -D 5000 user@Сервер

А после этого установить обратный туннель с Клиентом, в котором запросы на порт XXXX перенаправляются на 5000 порт нашего Socks proxy:

Сервер# ssh -R XXXX:localhost:5000 user@Клиент

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

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

Прокси# ssh -D 5000 -R XXXX:localhost:5000 user@Сервер

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

Сервер# ssh -R YYYY:localhost:XXXX user@Компьютер

Однако в данном случае интернет-запрос на порт Сервера XXXX по обратному туннелю перенаправляется на компьютер, играющий роль Прокси-сервера, а затем возвращается на Cервер, чтобы быть обслуженным на нём же:

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

5. Прямой туннель на промежуточный SSH-сервер

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

Такая схема выручает тогда, когда с локального компьютера нет прямого доступа в интернет, но есть доступ к некоторому серверу внутри локальной сети, который подключен к интернет. Пример схемы связности и доступности для случая, когда Клиент и Прокси находятся за NAT, а Сервер доступен из Интернета:

В другом случае Сервер находится в удалённой локальной сети и недоступен из интернета напрямую, но к нему можно подключиться через промежуточный Прокси в той же локальной сети. Возможная схема связности и доступности для случая, когда Прокси является шлюзом, а Клиент разсположен за NAT в собственной LAN:

В обоих случаях Клиенту нужно подключиться на адрес localhost:5000.

Эквивалентная команда для OpenSSH клиента:

Клиент# ssh -L 5000:Сервер:3389 user@Прокси

6. Обратный туннель на промежуточный SSH-сервер

Эта схема уже подробно рассматривалась в самом начале:

В даном случае нам нужно зайти с домашнего компьютера на удалённый, к которому нет доступа из интернет, но есть промежуточный Прокси, доступный как для Клиента, так и для Сервера. Мы выяснили, что связь можно наладить только с помощью обратного туннеля Сервера с Прокси.

Для разрешения удалённого подключения Клиента необходимо также отметить опцию [Remote ports do the same]. Эта опция работает только в том случае, когда разрешение на подключение на удалённый порт по запросу клиента разрешено в файле конфигурации ssh-демона Прокси-сервера /etc/ssh/sshd_conf:

GatewayPorts clientspecified

После этого Сервер должен стать доступным с Клиента по RDP на адрес Прокси:5000

Эквивалентная команда для OpenSSH клиента:

Сервер# ssh -R 5000:localhost:3389 user@Прокси

SSH-туннель домой без необходимости оставлять включённым домашний ПК / Хабр

Disclaimer
Этот пост появился здесь по нескольким причинам:

1) Меня попросил сам Boomburum

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

Хабралюдям, познавшим Дао IOS, tun, VPN, *wrt, WOL… etc, предлагается на выбор:

А) Закрыть топик, заняться делом и не выводить себя из нирваны чтением этой любительской фигни.

Б) Потратить время на конструктивную критику и полезные дополнения в комментариях.

Специально для GrammarNazi:

Пишите пожалуйста об ошибках в личку — обещаю исправиться.

Бла-бла-бла, а топик-то о чём?
Итак, я обещал рассказать «как поднять ssh-туннель домой без необходимости оставлять включённым домашний ПК» и, как правильно догадался peter23 речь пойдёт про ssh-сервер на роутере.

Сначала о том, кому и зачем это может понадобиться и каковы начальные условия.
Предположим Вы находитесь в сети, которая подключена к интернет с ограничениями, доставляющими вам неудобства. Или напротив — Вы подключились к публичной точке доступа и у Вас обострение паранойи есть основания для беспокойства. В общем, Вы находитесь в ситуации, когда очень хотелось бы больше свободы/контроля в сети, но увы. И, кажется, можно было бы залогиниться на домашний компьютер через какой-нибудь сервис вроде logmein или teamviewer, но этот самый домашний компьютер представляет из себя ноутбук, забытый на диване без подзарядки, а личного сервера у вас нет.
Но зато у Вас дома всегда включён маршрутизатор и, пока вас нет, он просто тратит электроэнергию.

Есть несколько вариантов выхода из ситуации. Ниже описан лишь один из них.

1) Определяемся с роутером

Хорошо ли вы знаете свой маршрутизатор?

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

У вас «народный» D-Link DIR-xxx, ASUS WL-xxxGx/RT-Nxx, Netgear, TP-Link, TRENDnet, «гиковский» Linksys WRT-xxx, Ubiquiti или что-то вроде того? Вам повезло!

Идём в базу совместимых роутеров на официальном сайте прошивки и вводим название и модель своего маршрутизатора в строку поиска. Если всё хорошо, то на всякий случай обратимся ещё к коллективному разуму для уточнения подробностей о поддержке Вашей модели. Уразумев тонкости вопроса прошиваем роутер по инструкции на сайте. Не забудьте про 30/30/30.

Если всё прошло успешно, то настраиваем постоянное подключение к интернет и переходим к следующему пункту.

2) Путь домой

Следующим шагом необходимо понять как прийти из интернета домой.

По какому адресу обратиться к роутеру?

Необходимое условие — Ваш провайдер предоставляет Вам внешний IP адрес.

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

Это проще простого: регистрируетесь на сайте, в меню роутера Setup->DDNS выбираете в выпадающем списке этот сайт, вводите «логин-пароль-хост-остальное по вкусу», нажимаете кнопку «Apply Settings» и забываете об этом. Теперь Вам надо помнить только хост (кстати, даже если IP у вас статический, можете так сделать простой для запоминания адресок, а то вдруг провайдер поменяется или случится переезд).

В итоге мы имеем на руках «адрес своего дома» в интернет в виде IP или доменного имени. Ура!

3) Знакомимся с возможностями SSHd на роутере.
http://www.dd-wrt.com/wiki/index.php/SSH

Весьма гибкий инструмент, не правда ли?

Попробуем же с его помощью пустить весь Ваш трафик от браузера и других программ через домашний роутер. Т.е. поднять ssh-туннель от Вас до домашнего роутера, таким образом, чтобы вход в него на Вашей стороне выглядел как локальный SOCKS-прокси а на выходе роутер весь трафик разруливал в соответствии с назначением, давая нам возможность скрытно безнаказанно и безопасно выйти в свободный интернет (да-да, это очень «толстая» формулировка, несомненно) и заодно пользоваться домашними сетевыми ресурсами, если таковые имеют место быть. Короче — почувствовать себя как дома.

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

4) Ключи от квартиры, где деньги лежат.

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

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

Чтобы их получить запускаем puttygen, давим кнопку «Generate» и шевелим мышом пока не увидим примерно такую картину:


Сохраняем приватный ключ в файл с расширением .ppk, а публичный ключ достаточно просто скопировать из окошка puttygen вот сюда в настройках DD-WRT:

Хорошо бы не забыть, что удалённый SSH-доступ в DD-WRT необходимо включить в разделе Administration->Management.

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

Любителям прекрасного советую настроить Port-Knocking и запаролить приватный ключ, если не лень каждый раз стучать по портам и клаве.

5) Клиент всегда прав

Всё, роутер (читай «сервер с SSHd») настроили, возвращаемся к нашим баранам, т.е. виндам.

Берём программу SSH-клиент, например замечательный portable KiTYY (спасибо NZeraF за наводку). И настраиваем его на подключение к нашему роутеру примерно как на скриншотах ниже:

Будем ходить под рутом…


… поэтому осторожно.


Путь к приватному ключу можно указать относительно корня диска (удобно для portable-варианта).


Немножко магии port forwarding (порт можно задать от балды, например 5150).


Вспоминаем «путь домой», придумываем название подключения (aka сессии) и сохраняем.


Нужно, конечно, учитывать особенности доступа в интернет из сети, в которой Вы находитесь (прокси там всякие и прочее). В общем клиент настроен и туннель можно запускать и использовать.

Для удобства можно создать примерно такой батничек или ярлык для быстрого запуска:
kitty.exe -load "sessionname" -send-to-tray

6) И чё с этим делать?

Вариантов масса. Можно например использовать такой туннель как локальный прокси для браузера. Как-то так или этак:


Или для доступа по RDP или SSH на другие сервера, или просто IM клиент или Skype в интернет выпустить.

И даже если ваше приложение не понимает SOCKS-прокси, достаточно просто запустить
polipo socksParentProxy=localhost:5150

и будет Вам HTTP прокси на порту 8123. В общем, всё в Ваших руках.

UPD:

Мой ответ из личной переписки по следам топика для тех несчастных, у кого только 80 порт и никаких CONNECT.
daniel.haxx.se/docs/sshproxy.html
www.nocrew.org/software/httptunnel.html

Ну и сразу для новичков-пингвиноводов-убунтолюбов — corkscrew или proxytunnel

А для их более красноглазых друзей бонус от ValdikSS

Кстати, на хабре уже писали что, роутер Вам и торренты качать может и много чего ещё. Да и домашний комьютер можно включить удалённо так или иначе (или, пробросив порт, вот так).

PS: Один из источников вдохновения

PPS: Вопрос для знатоков (про браузеры и DNS).

Как настроить обратный туннель SSH в Linux

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

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

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

 $ ssh [ваш-аккаунт-логин] @ [server-ip]

Что такое обратный SSH?

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

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

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

Это описание параметра ssh -R на странице руководства:

-R [bind_address:] порт: хост: hostport

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

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

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

Как создать обратный туннель SSH?

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

 ssh -fN -R 7000: localhost: 22 имя пользователя @ yourMachine-ipaddress

Таким образом, этот запрос ssh-соединения, исходящий с удаленного сервера на ваш компьютер, будет гарантировать, что любой запрос ssh-соединения для порта 7000 на вашем компьютере будет перенаправлен на порт 22 удаленного сервера.

Теперь сделайте запрос на ssh-соединение с вашего компьютера на ваш собственный через порт 7000:

 имя пользователя ssh @ localhost -p 7000

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

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

Чтобы решить эту проблему, вы можете настроить машину, на которой отсутствует брандмауэр (как и ваша), так, чтобы она всегда была включена. Назовем эту машину machine_z.

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

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

Некоторые параметры, которые необходимо настроить на machine_z, включают:

  • Убедитесь, что для параметров TCPKeepAlive, ClientAliveInterval, ClientAliveCountMax и GatewayPorts установлены соответствующие значения. Эти параметры находятся в файле / etc / sshd_config или / etc / ssh / sshd_config

    • .

  • Если вы внесете некоторые изменения в вышеуказанные параметры, вам следует перезапустить демон sshd, чтобы отразить изменения.
  • Также убедитесь, что вы запускаете первую команду ssh (которая выполняется с удаленного сервера на machine_z) с помощью команды nohup, чтобы этот сеанс ssh стал невосприимчивым к зависаниям, которые могут произойти, когда пользователь выходит из системы.

Если вам понравилась эта статья, возможно, вам также понравится ..

.Аутентификация

— почему я не могу подключиться к обратному туннелю ssh?

Переполнение стека

  1. Около

  2. Продукты

  3. Для команд

  1. Переполнение стека
    Общественные вопросы и ответы

  2. Переполнение стека для команд
    Где разработчики и технологи делятся частными знаниями с коллегами

  3. Вакансии
    Программирование и связанные с ним технические возможности карьерного роста

  4. Талант
    Нанимайте технических специалистов и создавайте свой бренд работодателя

  5. Реклама
    Обратитесь к разработчикам и технологам со всего мира

  6. О компании

Загрузка…

.

No related posts.

Share :

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *