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-ами.Конечно же, это приводит к серьёзной бреши в корпоративной безопасности,
поэтому крайне не рекомендуется злоупотреблять этим советом.
URL: http://bappoy.pp.ru/2008/02/27/ssh-tunneling-tips.html http://bappoy.pp.ru/2008/06/09/socks-in-ssh.html
Обсуждается: http://www.opennet.ru/tips/info/1691.shtml
Угу , 2 firewall-a .
И открыты порты наружу .
И не забываем, что -R в ssh'е так будет работать _только_ в том случае, если не забыть в /etc/ssh/sshd_config поставить конфигурационный параметр "Gateway_ports" в "YES", чего по умолчанию, конечно же, нет.
м... "ssh -g" и далее решит вопросы
> И открыты порты наружу .Достаточно чтобы хоть какие-то данные качались, хоть HTTP.Далее в оные энкапсулируется что угодно, например и такая ssh сессия...
> это приводит к серьёзной бреши в корпоративной безопасностиНе более, чем предоставление внешним юзерам VPN-доступа с той же функциональностью. Просто пароли надо хранить!
Хотя мне не очень понятно, что будет, если кто-то выполнит http://домашняя_машина:8080 (где "домашняя_машина" - та, где я делаю http://localhost:8080). Будет ли ssh редиректить запросы от сторонних машин?
>> это приводит к серьёзной бреши в корпоративной безопасности
>
>Не более, чем предоставление внешним юзерам VPN-доступа с той же функциональностью. Просто
>пароли надо хранить!
>
>Хотя мне не очень понятно, что будет, если кто-то выполнит http://домашняя_машина:8080 (где
>"домашняя_машина" - та, где я делаю http://localhost:8080). Будет ли ssh редиректить
>запросы от сторонних машин?Без ключа -g не будет
>Конечно же, это приводит к серьёзной бреши в корпоративной безопасности,Угу, а если какойнить "пинч" пошлет спертые пароли банально засунув их в закодированном виде в HTTP GET запрос который к тому же сделает почти наверняка прописаный на фаерволе IE в невидимом окне - это не брешь в защите корпорации, да?Кому надо обойти фаервол его обойдет.Если хоть какой-то траффик можно прокинуть до хоть немного подконтрольного вам хоста - все, фаерволл оказывается в глубокой заднице.Если мыслить немного абстрактно, разрешенный метод коммуникации рассматривается в новой абстракции как транспортный уровень на который заново накладывается пачка протоколов.Далее фаерволл просто не способен анализировать что там шлется уровнями выше - а он то откуда знает что скажем HTTP в данном случае не передает смысловой нагрузки а всего лишь выступает как транспорт?
Извиняюсь, если ламерский вопрос, но как дать доступ юзеру только к туннелю ? То есть юзер коннектится на мой SSH-сервер, получает возможность туннеля и никакого доступа к шелу.
>Извиняюсь, если ламерский вопрос, но как дать доступ юзеру только к туннелю
>? То есть юзер коннектится на мой SSH-сервер, получает возможность туннеля
>и никакого доступа к шелу.В статье же написано:
-N - не запускать shell на удаленном хосте
вы можете мне помочь с решением данного вопроса?
я буду рада совету
cat >> /etc/passwd
user:x:1500:1500:user:/home/user:/bin/false
Ток подкорректировать запись надо
или man usermod почитать можно
ыыы
Самая лучшая статья по SSH-туннелингу, которую встречал!
Но и она неполная. Вот, например, описано применение весьма интересного ключика -f, переводящего ssh-сессию в фон:ssh -D 5555 user@remotehost -f -N
Ну хорошо, поработал всласть по образовавшемуся туннелю, выключил свой домашний комп.
И как теперь снова подключиться к этому же фоновому SSH-процессу?Пока запускаю снова эту же строку, но это же неграмотно, т.к. процессы плодятся, а это никому не нужно.
На Windows, я использую Proxyсap ( http:/www.proxycap.com/ ). Эта программа автоматически создает SSH туннель и перенаправляет программы через него.
На Windows, я использую Proxyсap ( http:/www.proxycap.com ). Эта программа автоматически создает SSH туннель и перенаправляет программы через него.
Глючит ваш форум.
Обновлю эту тему, и тому есть веская причина.
Несколько лет назад успешно пользовался SSH-туннелем в варианте п.1 данного хавту.
Проблем при этом никаких и никогда не возникало - туннель работал как часы.Пару дней назад снова вернулся к этому методу, но нет тут-то было - сколько ни бился, туннель не работает!
Долго консультировался на ЛОРе, но к определенным выводам, кроме как "анализируй лог", так и не пришли.На клиенте и на сервере использую обновленный CentOS 5.5.
Туннель создаю командой на клиенте:
ssh -D -N 5555 tun1@remote-ssh-server -p 54822По этой команде на клиентском экране выводится такой лог: http://pastebin.com/P1CN6XPj
Настроенный на SOCKS5 браузер выдает на «Соединение было сброшено» и сайты недоступны.
Что-то в этом мире SSH поменялось за это годы, но что именно - непонятно. Для выяснения причин нужна тяжелая артиллерия в вашем лице.
Не исключено, что по итогам понадобится корректировка данного хавту, так что выяснение неработоспособности туннеля будет полезно всем.
>[оверквотинг удален]
> На клиенте и на сервере использую обновленный CentOS 5.5.
> Туннель создаю командой на клиенте:
>ssh -D -N 5555 tun1@remote-ssh-server -p 54822
> По этой команде на клиентском экране выводится такой лог: http://pastebin.com/P1CN6XPj
> Настроенный на SOCKS5 браузер выдает на «Соединение было сброшено» и сайты недоступны.
> Что-то в этом мире SSH поменялось за это годы, но что именно
> - непонятно. Для выяснения причин нужна тяжелая артиллерия в вашем
> лице.
> Не исключено, что по итогам понадобится корректировка данного хавту, так что выяснение
> неработоспособности туннеля будет полезно всем.Точно такая же проблема на Kubuntu 14.10 b OpenSSH. Не знаю, что и делать.
> На клиенте и на сервере использую обновленный CentOS 5.5.Сорри, ошибся с цифрами версии - правильно 6.5.