Putty не работает туннель

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Простой SSH туннель с помощью Putty

Безопасность на «минималках» 🙂

2 минуты чтения

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

Полный курс по Сетевым Технологиям

В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer

В статье мы расскажем о простом способе создания SSH – туннеля и использования его для HTTP/RDP доступа.

Шаг №1: Создание SSH — шлюза

Первое, что необходимо сделать, это создать SSH – шлюз. Для этого, откроем Putty и создадим подключение к шлюзу:

Сохраните сессию, чтобы потом оперативно загрузить ее с помощью кнопки Load.

Шаг №2: Делаем туннель

В левом меню навигации, переходим в раздел Connection → SSH → Tunnels. В данном меню настройки укажите параметр Source Port — это порт, к которому вы будете подключаться локально, чтобы отправить трафик через SSH – туннель. В поле Destination укажите адрес назначения, к которому вы будете подключаться:

Данная запись означает то, что при подключении к локальному порту 37662 (127.0.0.1:37662), вы будете перенаправлены через SSH туннель до SSH – шлюза, а затем уйдете на адрес назначения 11.12.13.14:3389 – то есть RDP.

Помимо этого, мы добавим подключение к WEB по 80 порту. Нажимаем Add:

Отлично. Теперь в Putty нажимаем Open — туннель готов к использованию.

Шаг №3: Проверяем

Вызываем утилиту подключения к удаленному рабочему столу командой mstsc и указываем требуемые для нас реквизиты подключения – локалхост и созданный ранее RDP порт:

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

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

Онлайн курс по Кибербезопасности

Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии

Источник

PuTTY SSH Tunneling не работает на Linux

Я использую сервер на Debian, на котором установлен Webmin, на котором не установлен порт по умолчанию.

Я недавно установил Linux Mint, заменив Windows.

Когда у меня была Windows, я использовал PuTTY для переноса своего порта Webmin, и все работало в Windows, используя localhost:port.

После перехода на Linux я установил PuTTY и снова настроил переадресацию портов в разделе SSH.

Я захожу на свой сервер и пытаюсь получить доступ к моему webmin через порт localhost: и он просто говорит, что в chrome отказано соединение?

Я не могу думать, что случилось, поскольку это работало назад на Windows.

У меня есть локальный сервер apache2, работающий на Linux Mint, я подумал, что это может помешать, но я остановил apache2 и все равно не повезло.

Буду признателен за любую оказанную помощь.

2 ответа 2

Я знаю, что это немного устарело, но у меня была такая же проблема при переносе сеансов putty из windows в Fedora linux. Ответ довольно прост. Я положил это здесь в пользу других с подобными проблемами.

В linux (по крайней мере, в Fedora) обычный пользователь не может перенаправить локальные порты менее 1024, если вы не используете пользователя root (или, наверное, sudo). Насколько я могу судить, Putty в Linux использует SSH, установленный в Linux. Замазка Windows сделала свое дело, я считаю, или, по крайней мере, установила версию Windows SSH, которая, казалось, не имела этого ограничения. Я думаю, что Linux-подход, вероятно, является наиболее безопасным, в то время как Windows-подход для удобства.

Поэтому вместо запуска putty под sudo я просто перенаправил локальные порты выше 1024 в удаленную сеть.

Таким образом, в OP вы можете перенаправить, скажем, 127.0.1.1:1080 -> debian_server:5436, например.

В моем случае (в Windows) я использовал перенаправление локально 127.0.1.1:80->192.168.1.1:80 (чтобы иметь возможность управлять веб-интерфейсом маршрутизатора в удаленной сети. Конфигурация сессии замазки (в реестре) под окнами была такой:

На Fedora запись в файле конфигурации сеанса стала такой:

Это также может быть использовано для https с использованием локального порта (скажем) 1443 для удаленного порта 443.

В Linux их можно настроить в файле conf или в открывающем графическом интерфейсе putty.

Источник

Создание 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

В настройках Connection → SSH → Tunnels, в поле Source port указать порт vnc 5900, в поле Destination указать локальный порт 127.0.0.1:5900, далее нажать кнопку Add.

Должно получится как на скриншоте:

Далее, в настройках Session указываем ip адрес сервера и жмем кнопку Open.

В открывшемся окне входим в систему с учетными данными из личного кабинета.

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

В результате, должно открыться окно входа на сервер:

Для Linux, вместо 1 и 2 пунктов, подключение:

$ ssh -L 5900:127.0.0.1:5900 root@X.X.X.X

где X.X.X.X — адрес сервера

Изменение разрешения vnc сессии

Открыть в текстовом редакторе файл: /lib/systemd/system/x11vnc.service

$ sudo nano /lib/systemd/system/x11vnc.service

В строку:
ExecStart=/usr/bin/x11vnc -auth /var/run/lightdm/root/:0 -forever -loop -noxdamage -repeat -display :0 -localhost
в самый конец добавить опцию: -geometry WxH (где WxH – жедаемое разрешение):

Источник

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

Источник