- Создание SSH-туннелей с помощью PuTTY
- 1. Локальный проброс порта
- 2. Удалённый проброс порта
- 3. Socks–proxy
- Как настроить (создать) SSH-туннель с помощью PuTTY в Windows
- Создание (настройка) SSH-туннеля в PuTTY (Windows)
- Использование SSH-туннеля в качестве прокси в Google Chrome / Vivaldi / Яндекс.Браузере
- SSH Tunneling With PuTTY
- Troubleshooting
- Problem
- Resolving The Problem
- PuTTY: делаем Windows полезным
- 1. Локальный проброс порта
- 2. Удалённый проброс порта
- 3. Socks-proxy
- 55 Responses
Создание 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 можно увидеть следующее:
То есть 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 изменить следующим образом:
В результате после успешной авторизации со стороны клиента можно будет наблюдать следующее:
То есть 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… 🙂
Как настроить (создать) SSH-туннель с помощью PuTTY в Windows
/ author 0 Comments —>
Создание (настройка) SSH-туннеля в PuTTY (Windows)
- Арендуем дешёвый VPS/VDS у Inferno Solutions в Германии или Нидерландах за 5 USD/мес.
- Создаём сессию в PuTTY со следующими параметрами:
Host Name (or IP address) — IP адрес вашего VPS/VDS сервера;
Port — 22;
Saved Session — «ssh tunnel»;
После чего нажимаем «Save».
Переходим на вкладку Connection — SSH — Tunnels и вводим дополнительные параметры для туннеля:
Возвращаемся на вкладку Session и сохраняем настройки
Подключаемся к нашему серверу:
Использование SSH-туннеля в качестве прокси в Google Chrome / Vivaldi / Яндекс.Браузере
- Заходим в настройки Google Chrome и переходим в раздел «Система». В этом разделе нажимаем на «Настройки прокси-сервера»:
В открывшемся окне нажимаем на «Настройка сети»:
Ставим галочку «Использовать прокси-сервер для локальных подключений…» и нажимаем на «Дополнительно»:
В поле «4. Socks. Адрес прокси-сервера.» вводим «127.0.0.1». В поле «Порт» вводим «8085» и нажимаем «ОК»:
SSH Tunneling With PuTTY
Troubleshooting
Problem
This document provides information about how to configure a PuTTY session for tunneling Telnet traffic.
Resolving The Problem
To configure a PuTTY session for tunneling Telnet traffic, do the following:
Open PuTTY.EXE, configure your host name, and select SSH for port. | |
2 | Type the name you wish to use for the saved connection. In this example it is my.test.server. Do not save this yet; we have to configure the ports for tunneling. |
3 | Click on the path to reach Tunnels (Connection > SSH >Tunnels): |
4 | In the Port forwarding section, the Source Port is the source TCP/IP address you want assigned to your local host connection. The Destination is the connection on your remote SSH machine. localhost:23 will get you a Telnet connection. Select both Local ports accept connections from other hosts and Remote ports do the same. |
5 | Click the Add button to place your tunnel configuration in the Forwarded ports window. |
6 | In the left pane, click on Session to bring up the following window. Click on the Save button: |
7 | Now you can launch your session and sign in to the secure shell. After you are signed in, you must leave this window open to keep your tunnel active. |
8 | Open IBM Personal Communications. Configure a new connection and use the parameters below: |
9 | Click on Communications, and connect. You should get the remote sign on screen of the system you are tunneling to. |
You can tunnel multiple ports if you like; however, all require that the PuTTY secure shell connection stays active for data to pass over the tunnel to the remote server.
The steps above are represented as the following command on a UNIX system:
ssh -L50000:localhost:23 my.test.server.com
The steps above are represented as the following command on the QP2TERM/QP2SHELL/QSH command line:
PuTTY: делаем Windows полезным
В данной статье будет описано как строить 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 можно увидеть следующее:
То есть 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 изменить следующим образом: В результате после успешной авторизации со стороны клиента можно будет наблюдать следующее:
То есть 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. 🙂
P.P.S. Другой способ туннелирования трафика описан в заметке Разворачивание трафика на основе policy routing. Весьма рекомендую к прочтению.
55 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.
Добрый день.
Я убедительно прошу Вас ознакомиться с моей перепиской с техподдержкой онлайн-Flash-игры Танки Онлайн, из которой будет ясна моя проблема.
Мне кажется, что Вы сможете мне помочь советом, и я готов оплатить Ваши услуги или отблагодарить каким-нибудь способом.
С уважением,
Кирилл
Вот наша переписка:
Вопрос в поддержку:
Дррузья, пропадаю без Танков. Вы можете спасти мою страдающую душу и тело. ))
Сначала у нас в организации (оставим этичность игр на работе за скобками) перекрыли определенные порты (в нашем случае необходимые для Танков 5190, 5222 и 5223. Я расстроился, но потом установил на комп программу Tor, а на Firefox — плагин Torbutton. Причем версию Firefox пришлось ставить старую, ибо новые Torbutton не поддерживают. (( (примечание — если просто запускать Firefox при включенном Tor, то в браузере перестает работать Flash). Вот так заморочился, но все худо-бедно работало, пусть и медленнее из-за работы через Tor. Теперь еще одна напасть — сервер отказывает в соединении (см. приложенный скриншот). Это продолжается уже несколько дней, и я перепробовал уже кучу всего — очистку кэша браузера, очистку Flash-плеера, установку плагина Noscript, попытался запустить игру через Stadalone FlashPlayer, перегружал комп, пинговал соединение с сервером Танков (потери пакетов нет) и т.д. Короче — уже ничего не понимаю, и слезы горя катятся из моих глаз.
Помогите, братцы!
Вот ответ Вашего сотрудника, после которого модератор темы решил, что вопрос себя исчерпал:
Ответ сотрудника на форуме:
На скриншоте – именно признак недоступных игровых портов.
Лучшие выходы в вашей ситуации – альтернативный выход в интернет либо подход с ящиком пива к сисадмину (во втором случае возможны варианты, но принцип вы, надеюсь, поняли).
Вот мой ответ сотруднику:
По техническим причинам альтернативный выход в интернет мне не удастся организовать, то есть нужно попробовать использовать тот, что есть. )) И поход к админам с пивом тоже не сработает, так как все IT-политики у нас в конторе определяет центральный офис в Париже, через который и идет весь трафик. Они и зарубили нужные для игры порты.
Я попробовал даже соединиться с игрой через мой домашний компьютер с помощью программы Teamviewer, и зашел в игру легко, но задержки дикие, и играть невозможно. Соответсвенно кровь из носу нужно понять, на каком этапе происходит сбой.
Напомню, что я СОЕДИНЯЛСЯ с игровым сервером с браузером Firefox со встроенным Tor-клиентом. Только лишь неделю назад начались вот эта глюки.
Уж извиняюсь что влезаю раньше автора статьи. Сразу оговорюсь — вопрос решается если порт 22 НЕ закрыт админами. Если закрыт — увы и ах. Тут никак.
По мне так вопрос просто решается.
1. Арендуете сервер VPS. Из предустановленного ПО ничего не надо
2. Произвести оплату как хотите. Вам выдадут пароль root-а.
3. Создаете коннект в putty с именем root и логином который вам дали.
4. Порты перебрасываются как в пункте 3 по нужным вам портам. Но с указанием купленного сервера.
Да. Самое главное. Не забывайте оплачивать жалкие n Евро в месяц 🙂 Если так хочется играть — то почему бы и нет? Не великие деньги.
P.S. Для прикола счас подключился к локальной базе данных через сервер свой же. Все работает. Естественно с небольшими тормозами, но это и понятно. А так бесплатная схема типа TeamViewer-а получается. Сейчас буду по работе запускать на VNC аналог TeamViewer-а. И полноценная тех. поддержка будет и бесплатно!
Здравствуйте, подскажите как разрулить следующую ситуацию:
есть сервер (sshd с доступом только по ключу), есть клиент с доступом на этот сервер. Проблема в следующем: на клиенте есть приложение, которое работает через ссх, но не поддерживает ключи. Так вот, как с помощью путти расшарить сессию на локальный порт? Знаю что провернуть такое можно, т.к. когда-то (очень давно) уже делал подобное, но не через пути, а через что не помню и по-моему использовал для связки TAP интерфейс.
Если знаете более простой вариант, пожалуйста подскажите.
Приложение, которое работает через ссх, но не поддерживает ключи — это что-то очень странное. Как оно называется?
название ничего не даст, это программа для внутреннего пользования (типо биллингового интерфейса), писалась очень давно (когда фряха была где-то версии 4,5) и если уж добавлять поддержку ключей, то лучше сразу переписать весь код, кроме модулей, а это как минимум — лень, как максимум — некогда(
А рутовых прав у Вас на сервере случайно нет? Если вдруг есть (или можете попросить кого-то, у кого есть), то достаточно просто поменять значение параметра «PasswordAuthentication» в конфиг-файле SSH-сервера (обычно это /etc/ssh/sshd_config в случае OpenSSH). В противном случае используйте следующий подход.
1. Запустите на сервере ещё один SSH-сервер под своим пользователем на непривилегированном порту (выше 1024), например на порту 2222 (надо найти порт, не закрытый firewall-ом), не забыв разрешить в конфиге авторизацию по паролю.
2. Подключитесь с помощью putty к своему самосборному SSH-серверу на порт 2222, с такой конфигурацией в разделе tunnels: «L22 127.0.0.1:2222» (в первой части статьи вроде описано как «расшарить сессию на локальный порт», если я правильно понял что Вам требуется).
Тогда Вашему приложению нужно будет подключаться на 127.0.0.1 порт 22 и авторизоваться по паролю (авторизация будет идти с помощью Вашего самосборного SSH-сервера). Если приложение умеет подключаться на любой порт (а не только на стандартный 22), то пункт 2 можно пропустить и сразу заставить приложение подключаться к серверу на порт 2222.
К сожалению не совсем подходошло, по той причине что схх какие-то злые «пидарги» брутфорсят, поэтому оставлять «PasswordAuthentication» даже на нестандартном порту не безопасно. Тем не менее можно попробовать ограничить 2222 только для локального доступа. Спасибо за совет.
Нестандартные порты обычно не брутфорсят (разве что кто-то целенаправленно пытается расхачить именно Вашу систему). В моей практике перенос SSH на нестандартный порт минимум на 5-ти разных серверах полностью решил проблему подбора паролей. К тому же, если пароль достаточно сложный и представляет собой случайный набор символов, то даже на стандартном порту насчёт брутфорса можно не беспокоится.