The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

Туннели с использованием SSH. Режим эмуляции Socks proxy в SSH
1. Режим эмуляции Socks proxy в SSH

Допустим, у нас есть рабочая станция в локальной сети за firewall'ом;
также имеется ssh-доступ на сервер в Интернете. Кроме ssh, никакой связи с
внешним миром не имеется,
а очень хочется, например, подключиться к какому-нибудь jabber-серверу.

На рабочей станции запускаем простую команду:

   ssh -D 5555 user@remotehost -f -N

, где -D 5555 - эмуляция SOCKS сервера через порт 5555 
-f  - работа в фоне, после аутентификации
-N - не запускать shell на удаленном хосте.

Теперь, указав в настройках XMPP-клиента (например, Pidgin'а) в качестве SOCKS5
прокси localhost:5555,
получим желаемый результат: Pidgin соединяется с сервером через внешний сервер.


2. Туннель ssh

Дано: сервер локальной сети ourproxy.provider.ru, доступный извне.

Требуется: получить из дома доступ к ресурсам внутри локальной сети, например,
к интранет-серверу 10.10.5.1:80

Решение: выполнить на домашней машине команду, пробрасывающую туннель к
искомому IP-адресу через ourproxy.provider.ru:

    ssh -f -N user@ourproxy.provider.ru -L 8080:10.10.5.1:80

Опция -f говорит ssh, что после соединения нужно уйти в background.
Опция -N указывает, что никаких команд выполнять не нужно
Ключ -L означает, что соединения к localhost на порт 8080 нужно перенаправлять
на 80 порт IP-адреса 10.10.5.1

Таким образом, набирая в браузере адрес http://localhost:8080, попадаем на нужный сервер.


3. Обратный туннель ssh


Дано: компьютер на работе, находящийся за firewall'ом и nat'ом; компьютер дома
с доступом в интернет;
сервер ourproxy.provider.ru с работающим sshd, доступный обоим компьютерам. 
Но в данном случае прямой доступ с ourproxy.provider.ru к рабочей машине отсутствует.

Требуется: получить из дома доступ к сервису sshd на рабочем компьютере.

Решение: на рабочей машине выполнить команду:

    ssh -f -N user@ourproxy.provider.ru -R 12345:localhost:22

Опции -f и -N описаны несколькими строчками выше.
Ключ -R означает, что подключения к порту 12345 на ourproxy.provider.ru будут
перенаправляться на 22 порт рабочего компьютера.

После выполнения этой команды с рабочей машины можно будет попасть на эту
машину с ourproxy.provider.ru,
выполнив команду:

    ssh -p 12345 user@locahost

По этому же принципу можно получить доступ к прочим ресурсам локальной сети. Вот еще один пример.

На рабочей машине:

    ssh -f -N user@ourproxy.provider.ru -R 8080:10.10.5.1:80

На домашней машине:

    ssh -f -N user@ourproxy.provider.ru -L localhost:8080:localhost:8080

Теперь, набрав в адресной строке браузера на домашнем компьютере http://localhost:8080, 
получаем доступ к интранет-серверу за семью замками двумя firewall-ами.

Конечно же, это приводит к серьёзной бреши в корпоративной безопасности, 
поэтому крайне не рекомендуется злоупотреблять этим советом.
 
10.06.2008 , Автор: Vladimir Brednikov , Источник: http://bappoy.pp.ru/2008/02/27/ssh-... (доп. ссылка 1)
Ключи: ssh, tunnel, socks / Лицензия: CC-BY
Раздел:    Корень / Безопасность / SSH

Обсуждение [ Линейный режим | Показать все | RSS ]
 
  • 1.1, rstone, 18:13, 10/06/2008 [ответить] [смотреть все]
  • +/
    Угу , 2 firewall-a .
    И открыты порты наружу .

     
  • 1.2, Andrew Kolchoogin, 12:33, 11/06/2008 [ответить] [смотреть все]
  • +/
    И не забываем, что -R в ssh'е так будет работать _только_ в том случае, если не забыть в /etc/ssh/sshd_config поставить конфигурационный параметр "Gateway_ports" в "YES", чего по умолчанию, конечно же, нет.
     
     
  • 2.3, Sadok, 12:53, 14/06/2008 [^] [ответить] [смотреть все]
  • +/
    м... "ssh -g" и далее решит вопросы
     
  • 1.4, i_am, 11:35, 17/06/2008 [ответить] [смотреть все]
  • +/
    > И открыты порты наружу .

    Достаточно чтобы хоть какие-то данные качались, хоть HTTP.Далее в оные энкапсулируется что угодно, например и такая ssh сессия...

     
  • 1.5, Дмитрий Ю. Карпов, 12:02, 18/06/2008 [ответить] [смотреть все]
  • +/
    > это приводит к серьёзной бреши в корпоративной безопасности

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

    Хотя мне не очень понятно, что будет, если кто-то выполнит http://домашняя_машина:8080 (где "домашняя_машина" - та, где я делаю http://localhost:8080). Будет ли ssh редиректить запросы от сторонних машин?

     
     
  • 2.7, Sadok, 13:17, 18/06/2008 [^] [ответить] [смотреть все]  
  • +/
    >> это приводит к серьёзной бреши в корпоративной безопасности
    >
    >Не более, чем предоставление внешним юзерам VPN-доступа с той же функциональностью. Просто
    >пароли надо хранить!
    >
    >Хотя мне не очень понятно, что будет, если кто-то выполнит http://домашняя_машина:8080 (где
    >"домашняя_машина" - та, где я делаю http://localhost:8080). Будет ли ssh редиректить
    >запросы от сторонних машин?

    Без ключа -g не будет

     
  • 1.6, User294, 12:20, 18/06/2008 [ответить] [смотреть все]  
  • +/
    >Конечно же, это приводит к серьёзной бреши в корпоративной безопасности,

    Угу, а если какойнить "пинч" пошлет спертые пароли банально засунув их в закодированном виде в HTTP GET запрос который к тому же сделает почти наверняка прописаный на фаерволе IE в невидимом окне - это не брешь в защите корпорации, да?Кому надо обойти фаервол его обойдет.Если хоть какой-то траффик можно прокинуть до хоть немного подконтрольного вам хоста - все, фаерволл оказывается в глубокой заднице.Если мыслить немного абстрактно, разрешенный метод коммуникации рассматривается в новой абстракции как транспортный уровень на который заново накладывается пачка протоколов.Далее фаерволл просто не способен анализировать что там шлется уровнями выше - а он то откуда знает что скажем HTTP в данном случае не передает смысловой нагрузки а всего лишь выступает как транспорт?

     
  • 1.8, ndruha, 15:55, 24/06/2008 [ответить] [смотреть все]  
  • +/
    Извиняюсь, если ламерский вопрос, но как дать доступ юзеру только к туннелю ? То есть юзер коннектится на мой SSH-сервер, получает возможность туннеля и никакого доступа к шелу.
     
     
  • 2.9, Sadok, 16:50, 24/06/2008 [^] [ответить] [смотреть все]  
  • +/
    >Извиняюсь, если ламерский вопрос, но как дать доступ юзеру только к туннелю
    >? То есть юзер коннектится на мой SSH-сервер, получает возможность туннеля
    >и никакого доступа к шелу.

    В статье же написано:

    -N - не запускать shell на удаленном хосте

     
     
  • 3.11, lena7, 20:34, 28/06/2008 [^] [ответить] [смотреть все]  
  • +/
    вы можете мне помочь с решением данного вопроса?
    я буду рада совету
     
  • 2.12, aes, 16:08, 14/07/2008 [^] [ответить] [смотреть все]  
  • +/
    cat >> /etc/passwd
    user:x:1500:1500:user:/home/user:/bin/false
    Ток подкорректировать запись надо
    или man usermod почитать можно
     
  • 1.13, rester, 17:08, 08/07/2010 [ответить] [смотреть все]  
  • +/
    ыыы
     
  • 1.14, Trofimov, 17:42, 04/12/2011 [ответить] [смотреть все]  
  • +/
    Самая лучшая статья по SSH-туннелингу, которую встречал!
    Но и она неполная. Вот, например, описано применение весьма интересного ключика -f, переводящего ssh-сессию в фон:

       ssh -D 5555 user@remotehost -f -N

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

    Пока запускаю снова эту же строку, но это же неграмотно, т.к. процессы плодятся, а это никому не нужно.

     
  • 1.15, Sergey, 04:58, 22/10/2013 [ответить] [смотреть все]  
  • +/
    На Windows, я использую Proxyсap ( http:/www.proxycap.com/ ). Эта программа автоматически создает SSH туннель и перенаправляет программы через него.
     
  • 1.16, Sergey, 05:02, 22/10/2013 [ответить] [смотреть все]  
  • +/
    На Windows, я использую Proxyсap ( http:/www.proxycap.com ). Эта программа автоматически создает SSH туннель и перенаправляет программы через него.
     
  • 1.17, Sergey78, 05:09, 22/10/2013 [ответить] [смотреть все]  
  • +/
    Глючит ваш форум.
     
  • 1.18, chuk, 14:47, 19/04/2014 [ответить] [смотреть все]  
  • +/
    Обновлю эту тему, и тому есть веская причина Несколько лет назад успешно пользо... весь текст скрыт [показать]
     
     
  • 2.20, Шмеле, 23:03, 24/12/2014 [^] [ответить] [смотреть все]  
  • +/
    >[оверквотинг удален]
    > На клиенте и на сервере использую обновленный CentOS 5.5.
    > Туннель создаю командой на клиенте:
    > [code]ssh -D -N 5555  tun1@remote-ssh-server -p 54822[/code]
    > По этой команде на клиентском экране выводится такой лог: http://pastebin.com/P1CN6XPj
    > Настроенный на SOCKS5 браузер выдает на «Соединение было сброшено» и сайты недоступны.
    > Что-то в этом мире SSH поменялось за это годы, но что именно
    > - непонятно.  Для выяснения причин нужна тяжелая артиллерия в вашем
    > лице.
    > Не исключено, что по итогам понадобится корректировка данного хавту, так что выяснение
    > неработоспособности туннеля будет полезно всем.

    Точно такая же проблема на Kubuntu 14.10 b OpenSSH. Не знаю, что и делать.

     
  • 1.19, chuk, 14:50, 19/04/2014 [ответить] [смотреть все]  
  • +/
    > На клиенте и на сервере использую обновленный CentOS 5.5.

    Сорри, ошибся с цифрами версии - правильно 6.5.

     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:



      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor