Проброс портов используя SSH. Ssh проброс портов

Памятка пользователям ssh / Хабр

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

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

Оглавление:

управление ключами
копирование файлов через ssh
Проброс потоков ввода/вывода
Монтирование удалённой FS через ssh
Удалённое исполнение кода
Алиасы и опции для подключений в .ssh/config
Опции по-умолчанию
Проброс X-сервера
ssh в качестве socks-proxy
Проброс портов — прямой и обратный
Реверс-сокс-прокси

туннелирование L2/L3 трафика
Проброс агента авторизации
Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

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

Генерация ключа

Свой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо.

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

Сменить пароль на ключ можно с помощью команды ssh-keygen -p.

Структура ключа

(если на вопрос про расположение ответили по-умолчанию).~/.ssh/id_rsa.pub — открытый ключ. Его копируют на сервера, куда нужно получить доступ.~/.ssh/id_rsa — закрытый ключ. Его нельзя никому показывать. Если вы в письмо/чат скопипастите его вместо pub, то нужно генерировать новый ключ. (Я не шучу, примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa, причём из этих десяти процентов мужского пола 100%).

Копирование ключа на сервер

В каталоге пользователя, под которым вы хотите зайти, если создать файл ~/.ssh/authorized_keys и положить туда открытый ключ, то можно будет заходить без пароля. Обратите внимание, права на файл не должны давать возможность писать в этот файл посторонним пользователям, иначе ssh его не примет. В ключе последнее поле — user@machine. Оно не имеет никакого отношения к авторизации и служит только для удобства определения где чей ключ. Заметим, это поле может быть поменяно (или даже удалено) без нарушения структуры ключа.

Если вы знаете пароль пользователя, то процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ не редактируя файлы вручную.

Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.

Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id '-p 443 user@server' (внимание на кавычки).

Ключ сервера

Первый раз, когда вы заходите на сервер, ssh вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да — ключ сохраняется в файл ~/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).

Если ключ сервера поменялся (например, сервер переустановили), ssh вопит от подделке ключа. Обратите внимание, если сервер не трогали, а ssh вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся — это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль — то паранойю можно включать на 100% и пароль не вводить).

Удалить известный ключ сервера можно командой ssh-keygen -R server. При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1.

Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Их можно: а) скопировать со старого сервера на новый. б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.

Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать.

Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.

Передача файлов на сервер иногда может утомлять. Помимо возни с sftp и прочими странными вещами, ssh предоставляет нам команду scp, которая осуществляет копирование файла через ssh-сессию.

scp path/myfile [email protected]:/full/path/to/new/location/

Обратно тоже можно:scp [email protected]:/full/path/to/file /path/to/put/here

Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб — предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал ~5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).

Возможность копировать здорово. Но хочется так, чтобы «сохранить как» — и сразу на сервер. И чтобы в графическом режиме копировать не из специальной программы, а из любой, привычной.

Так тоже можно:

Теория: модуль fuse позволяет «экспортировать» запросы к файловой системе из ядра обратно в userspace к соответствующей программе. Это позволяет легко реализовывать «псевдофайловые системы». Например, мы можем предоставить доступ к удалённой файловой системе через ssh так, что все локальные приложения (за малым исключением) не будут ничего подозревать.

Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).

Использование: установить пакет sshfs (сам притащит за собой fuse).

Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере — с него в этой статье показываются картинки) на мой ноут:

#!/bin/bash sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o reconnect

Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:

Параметры sshfs, которые могут оказаться важными: -o reconnect (говорит пытаться пересоединиться вместо ошибок).

Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:

-o idmap=user. Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.

В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.

Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет — авторизация по паролю выбешивает на 2-3 подключение.

Отключить обратно можно командой fusermount -u /path, однако, если соединение залипло (например, нет сети), то можно/нужно делать это из-под рута: sudo umount -f /path.

ssh может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:

ssh user@server ls /etc/

Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.

Некоторые приложения хотят иметь управляющий терминал. Их следует запускать с опцией -t:ssh user@server -t remove_command

Кстати, мы можем сделать что-то такого вида:ssh user@server cat /some/file|awk '{print $2}' |local_app

Это нас приводит следующей фиче:

Проброс stdin/out

Допустим, мы хотим сделать запрос к программе удалённо, а потом её вывод поместить в локальный файл

ssh [email protected] command >my_file

Допустим, мы хотим локальный вывод положить удалённо

mycommand |scp — [email protected]:/path/remote_file

Усложним пример — мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:

mycommand | ssh [email protected] «scp — [email protected]:/path/to/file»

Есть и вот такой головоломный приём использования pipe'а (любезно подсказали в комментариях в жж):

tar -c * | ssh user@server "cd && tar -x"

Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar — читает и распаковывает. Так сказать, scp для бедных.

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

В более-менее крупной компании часто оказывается, что имена серверов выглядят так: spb-MX-i3.extrt.int.company.net. И пользователь там не равен локальному. То есть логиниться надо так: ssh [email protected]. Каждый раз печатать — туннельных синдромов не напасёшься. В малых компаниях проблема обратная — никто не думает о DNS, и обращение на сервер выглядит так: ssh [email protected]. Короче, но всё равно напрягает. Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам). Тогда всё выглядит так: ssh -1 -p 334 [email protected]. Удавиться. Про драму с scp даже рассказывать не хочется.

Можно прописать общесистемные alias'ы на IP (/etc/hosts), но это кривоватый выход (и пользователя и опции всё равно печатать). Есть путь короче.

Файл ~/.ssh/config позволяет задать параметры подключения, в том числе специальные для серверов, что самое важное, для каждого сервера своё. Вот пример конфига:

Host ric Hostname ооо-рога-и-копыта.рф User Администратор ForwardX11 yes Compression yes Host home Hostname myhome.dyndns.org User vasya PasswordAuthentication no

Все доступные для использования опции можно увидеть в man ssh_config (не путать с sshd_config).

По подсказке UUSER: вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например: Host * User root Compression yes

То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd_config), но это требует прав рута и распространяется на всех пользователей.

Собственно, немножко я проспойлерил эту часть в примере конфига выше. ForwardX11 — это как раз оно.

Теория: Графические приложения в юникс обычно используют X-сервер (wayland в пути, но всё ещё не готов). Это означает, что приложение запускается и подключается к X-серверу для рисования. Иными словами, если у вас есть голый сервер без гуя и есть локальный x-сервер (в котором вы работаете), то вы можете дать возможность приложениям с сервера рисовать у вас на рабочем столе. Обычно подключение к удалённом X-серверу — не самая безопасная и тривиальная вещь. SSH позволяет упростить этот процесс и сделать его совсем безопасным. А возможность жать трафик позволяет ещё и обойтись меньшим трафиком (т.е. уменьшить утилизацию канала, то есть уменьшить ping (точнее, latency), то есть уменьшить лаги).

Ключики: -X — проброс X-сервера. -Y проброс авторизации.

Достаточно просто запомнить комбинацию ssh -XYC user@SERVER. В примере выше (названия компании вымышленные) я подключаюсь к серверу ооо-рога-и-копыта.рф не просто так, а с целью получить доступ к windows-серверу. Безопасность microsoft при работе в сети мы все хорошо знаем, так что выставлять наружу голый RDP неуютно. Вместо этого мы подключаемся к серверу по ssh, а дальше запускаем там команду rdesktop:ssh ric rdesktop -k en-us 192.168.1.1 -g 1900x1200

и чудо, окошко логина в windows на нашем рабочем столе. Заметим, тщательно зашифрованное и неотличимое от обычного ssh-трафика.

Когда я оказываюсь в очередной гостинице (кафе, конференции), то местный wifi чаще всего оказывается ужасным — закрытые порты, неизвестно какой уровень безопасности. Да и доверия к чужим точкам доступа не особо много (это не паранойя, я вполне наблюдал как уводят пароли и куки с помощью банального ноутбука, раздающего 3G всем желающим с названием близлежащей кафешки (и пишущего интересное в процессе)).

Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.

Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает — его просто не пропускают. Экспериментально известно, что 443ий порт чаще всего оставляют, причём в режиме CONNECT, то есть пропускают «как есть» (обычный http могут ещё прозрачно на сквид завернуть).

Решением служит socks-proxy режим работы ssh. Его принцип: ssh-клиент подключается к серверу и слушает локально. Получив запрос, он отправляет его (через открытое соединение) на сервер, сервер устанавливает соединение согласно запросу и все данные передаёт обратно ssh-клиенту. А тот отвечает обратившемуся. Для работы нужно сказать приложениям «использовать socks-proxy». И указать IP-адрес прокси. В случае с ssh это чаще всего localhost (так вы не отдадите свой канал чужим людям).

Подключение в режиме sock-proxy выглядит так:

ssh -D 8080 user@server

В силу того, что чужие wifi чаще всего не только фиговые, но и лагливые, то бывает неплохо включить опцию -C (сжимать трафик). Получается почти что opera turbo (только картинки не жмёт). В реальном сёрфинге по http жмёт примерно в 2-3 раза (читай — если вам выпало несчастье в 64кбит, то вы будете мегабайтные страницы открывать не по две минуты, а секунд за 40. Фигово, но всё ж лучше). Но главное: никаких украденных кук и подслушанных сессий.

Я не зря сказал про закрытые порты. 22ой порт закрывают ровно так же, как «не нужный» порт джаббера. Решение — повесить сервер на 443-й порт. Снимать с 22 не стоит, иногда бывают системы с DPI (deep packet inspection), которые ваш «псевдо-ssl» не пустят.

Вот так выглядит мой конфиг:

/etc/ssh/sshd_config: (фрагмент) Port 22 Port 443

А вот кусок ~/.ssh/config с ноутбука, который описывает vpn

Host vpn Hostname desunote.ru User vasya Compression yes DynamicForward 127.1:8080 Port 443

(обратите внимание на «ленивую» форму записи localhost — 127.1, это вполне себе законный метод написать 127.0.0.1)

Мы переходим к крайне сложной для понимания части функционала SSH, позволяющей осуществлять головоломные операции по туннелированию TCP «из сервера» и «на сервер».

Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:

Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая — «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук — А, а «сервер» — Б.

Задача: у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.

Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).

Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.

ssh -R 127.1:80:8.8.8.8:8080 [email protected]

Опция -R позволяет перенаправлять с удалённого (Remote) сервера порт на свой (локальный). Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.Задача. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost'у.

Итоговая конфигурация: запросы на localhost:3333 на 'A' должны обслуживаться демоном на localhost:3128 'Б'.

ssh -L 127.1:3333:127.1:3128 [email protected]

Опция -L позволяет локальные обращения (Local) направлять на удалённый сервер.

Задача: На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.

Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.

ssh -L 192.168.0.2:8080:10.1.1.1:80 [email protected]

Вложенные туннели

Разумеется, туннели можно перенаправлять.

Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).

Решение сложно:ssh -L 192.168.0.2:8080:127.1:9999 [email protected] ssh -L 127.1:9999:127.1:80 [email protected]

Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.

Реверс-сокс-прокси

Если предыдущий пример вам показался простым и очевидным, то попробуйте догадаться, что сделает этот пример:ssh -D 8080 -R 127.1:8080:127.1:8080 [email protected] ssh -R 127.1:8080:127.1:8080 [email protected] Если вы офицер безопасности, задача которого запретить использование интернета на сервере 10.1.1.2, то можете начинать выдёргивать волосы на попе, ибо эта команда организует доступ в интернет для сервера 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.

Если к этому моменту попа отдела безопасности не сияет лысиной, а ssh всё ещё не внесён в список врагов безопасности номер один, вот вам окончательный убийца всего и вся: туннелирование IP или даже ethernet. В самых радикальных случаях это позволяет туннелировать dhcp, заниматься удалённым arp-спуфингом, делать wake up on lan и прочие безобразия второго уровня.

Подробнее описано тут: www.khanh.net/blog/archives/51-using-openSSH-as-a-layer-2-ethernet-bridge-VPN.html

(сам я увы, таким не пользовался).

Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели — либо ssh разрешён (читай — делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).

Если вы думаете, что на этом всё, то…… впрочем, в отличие от автора, у которого «снизу» ещё не написано, читатель заранее видит, что там снизу много букв и интриги не получается.

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

Для начала о простом пробросе авторизации.

Повторю картинку:

Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал [email protected] на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).

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

Вызов выглядит так:

ssh -A [email protected] ssh [email protected]

Удалённый ssh-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали ssh-клиенту доступ к своему агенту авторизации (но не ключу!).

В большинстве случаев это прокатывает.

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

Есть ещё более могучий метод — он превращает ssh в простой pipe (в смысле, «трубу») через которую насквозь мы осуществляем работу с удалённым сервером.

Главным достоинством этого метода является полная независимость от доверенности промежуточного сервера. Он может использовать поддельный ssh-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет — взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.

Эту клёвую настройку я не знал, и раскопал её redrampage.

Настройка завязана на две возможности ssh: опцию -W (превращающую ssh в «трубу») и опцию конфига ProxyCommand (опции командной строки, вроде бы нет), которая говорит «запустить программу и присосаться к её stdin/out». Опции эти появились недавно, так что пользователи centos в пролёте.

Выглядит это так (циферки для картинки выше):

.ssh/config:

Host raep HostName 10.1.1.2 User user2 ProxyCommand ssh -W %h:%p [email protected]

Ну а подключение тривиально: ssh raep.

Повторю важную мысль: сервер 8.8.8.8 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить — да, может. Но если разрешил — пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для [email protected], так и в [email protected]

Разумеется, подключение можно оснащать всеми прочими фенечками — прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.

Разумеется, в посте про туннели должен быть туннель, а в любой успешной статье — секретный ингредиент всеобщей популярности. Держите:

habr.com

Как создать туннелирование SSH или перенаправление портов в Linux — Information Security Squad

SSH-туннелирование (также называемое пересылкой портов SSH) — это просто маршрутизация трафика локальной сети через SSH на удаленные хосты.

Это означает, что все ваши соединения защищены с помощью шифрования.

Он предоставляет простой способ настройки базовой виртуальной частной сети (Virtual Private Network), полезной для подключения к частным сетям через незащищенные общедоступные сети, такие как Интернет.

Вы также можете использовать это решение, чтобы показывать локальные серверы за NAT и брандмауэрами в Интернет через защищенные туннели, как реализовано в ngrok.

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

В этой статье мы продемонстрируем, как быстро и легко настроить туннелирование SSH или различные типы переадресации портов в Linux.

Тестовая среда

Для задач этой статьи мы используем следующую настройку:

Локальный узел: 192.168.43.31
Удаленный хост: Linode CentOS 7 VPS с именем хоста server1.example.com.

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

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

Локальный переброс портов SSH

Этот тип переадресации портов позволяет подключаться с локального компьютера к удаленному серверу.

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

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

Флаг -L определяет порт, перенаправленный на удаленный хост и удаленный порт.

$ ssh [email protected] -L 8080: server1.example.com:3000

Добавление флага -N означает, что вы не выполняете удаленную команду, вы не получите оболочку в этом случае.

$ ssh -N [email protected] -L 8080: server1.example.com:3000

Параметр -f указывает ssh работать в фоновом режиме.

$ ssh -f -N [email protected] -L 8080: server1.example.com:3000

Теперь, на вашей локальной машине, откройте браузер, вместо того, чтобы обращаться к удаленному приложению, используя адрес server1.example.com:3000, вы можете просто использовать localhost: 8080 или 192.168.43.31:8080, как показано на скриншоте ниже.

Удаленное перенаправление портов SSH

Удаленная переадресация портов позволяет вам подключиться с удаленного компьютера к локальному компьютеру.

По умолчанию SSH не разрешает удаленное перенаправление портов.

Вы можете включить его с помощью директивы GatewayPorts в главном файле конфигурации SSHD /etc/ssh/sshd_config на удаленном хосте.

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

$ sudo vim /etc/ssh/sshd_config

Найдите требуемую директиву, раскомментируйте ее и установите ее значение «yes», как показано на скриншоте.

Сохраните изменения и выйдите. Затем вам необходимо перезапустить sshd, чтобы применить последнее изменение, которое вы сделали.

$ sudo systemctl restart sshd или $ sudo service sshd restart

Затем запустите следующую команду для перенаправления порта 5000 на удаленном компьютере на порт 3000 на локальном компьютере.

$ ssh -f -N [email protected] -R 5000:localhost:3000

Как только вы поймете этот метод туннелирования, вы можете легко и безопасно выявить локальный сервер разработки, особенно за NAT и брандмауэрами в Интернете по защищенным туннелям.

Аналогичным образом работают туннели, такие как Ngrok, pagekite, localtunnel и многие другие.

Динамическое перенаправление портов SSH

Это третий тип переадресации портов.

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

Динамическая переадресация портов настраивает ваш компьютер как прокси-сервер SOCKS, который по умолчанию прослушивает порт 1080.

Для начала SOCKS — это интернет-протокол, который определяет, как клиент может подключаться к серверу через прокси-сервер (SSH в этом случае).

Вы можете включить динамическую переадресацию портов с помощью опции -D.

$ ssh -f -N -D 1080 [email protected]

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

Обратите внимание, что прокси-сервер SOCKS перестанет работать после закрытия сеанса SSH.

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

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

itsecforu.ru

Туннели SSH | Проброс портов с помощью SSH | Проброс сервисов через файервол

http://www.linuxjournal.com/content/ssh-tunneling-poor-techies-vpn

Mar 28, 2012 By Jayson Broughtonin HOW-TOs SysAdmin

"Если вы видите свет в конце туннеля, то это свет приближающегося поезда", - Роберт Лоуэлл. Еще одна хорошая цитата. Эта статья посвящена построению туннелей с помощью SSH, или, как я называю эту тему, "VPN-туннелям для бедных". Несмотря на основные верования системных администраторов, туннели SSH на самом деле могут быть весьма полезной вещью как для технарей, так и для домашнего использования. Я сказал "несмотря на верования сисадминов" потому, что реверсивные туннели или завернутый в SSH веб-трафик могут продираться через межсетевые экраны и контентные фильтры. Статья, однако, не про то, как вам повергнуть корпоративную политику безопасности, а про то, как SSH-туннелирование может сделать нашу жизнь чуть-чуть менее сложной.

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

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

Итак, о системных требованиях. Я использую Дебиан в виртуальной среде, поэтому ваши результаты могут отличаться от моих. Поэтому привожу информацию о инструментах: эксплуатируется сервер OpenSSH_5.3p1 и различные по версиям клиенты OpenSSH 5.X. Перед тем, как погрузиться в глубины ssh-туннелирования должен сказать: перед тем, как проковырять дыру в безопасности компании с помощью реверсивного туннеля или заворачивания http-трафика убедитесь, что вы не нарушите какого либо стека внутренних регламентов типа Internet Acceptable Use Policy. Понятно, что в этом случае Системные Администраторы немедленно выследят и поджарят вас, особенно если вы используете туннель для попадания на сервер на работе из дома. В качестве Системного Администратора сам я получаю немалое удовольствие, обнаружив таких персонажей. Поверьте, при небольшой проверке выяснится, что системные администраторы вовсе не держиморды.

Ну вот, дисклаймер озвучен, можно приступать.

Построение SSH-туннелей довольно несложная вещь. Понимание того, что происходит и изучение подходов может оказаться несколько сложнее. Поэтому я дам несколько типичных случаев для настройки сознания перед тем, как мы перейдем к подробностям команд. До того, как у меня появились дети, я довольно много путешествовал. В своих путешествиях мне приходилось оказываться в весьма странных отелях, в комнатах которых были весьма странные Wi-Fi точки доступа. Вы действительно захотите коннектится к точке доступа отеля, у которой SSID набран непереводимой абракадаброй? Или в аэропорту, где несколько открытых сетей? Когда я где-то во внешнем мире, предпочитаю туннелировать веб-трафик на свой рутованный андроид через домашний сервер. Когда у меня в руках мой лэптоп, я открываю ssh-туннель и перенаправляю веб-трафик через socks5 так, чтобы весь входящий ко мне поток был шифрованным. Я доверяю открытым WAP лишь постольку, поскольку могу через них ходить. Что еще об открытом тексте? Я туннелирую SMTP трафик на своем компьютере через домашний сервер когда в некоторых местах вижу, что исходящий SMTP блокируется. Похожая ситуация с POP3. Другой пример: можно управлять X-приложениями через туннель. Можно заворачивать в туннель VNC-сессии. Одна из техник, которую я начал использовать раньше других - это реверсивные туннели. В этом случае вы создаете туннель от сервера, который находится за межсетевым экраном. Когда вы заходите на тот SSH-сервер, вы можете восстановить соединение.

Примеры

Перед тем, как глянуть со стороны клиента, нужно выполнить некоторые вещи на стороне сервера с помощью редактирования конфигурационного файла sshd.config, где я советую произвести указанные ниже изменения. Перед внесением изменений скопируйте оригинальный конфиг для сохранности, если что-то пойдет не так как задумано.

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

Собственно, конфигурация:

# Принудительно будем использовать версию протокола SSH 2Protocol 2

#Включим разделение прав для безопасностиUsePrivilegeSeparation yes

#Запретим логин под рутомPermitRootLogin no

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

#Разрешим форвардинг X-сессийX11Forwarding yesX11DisplayOffset 10

#Ненавижу Motd-дисплеиPrintMotd no

#Включим отслеживание TCP-сессийTCPKeepAlive yes

Если внесли изменения, должны перезапустить sshd-сервер для их применения.

Перейдем к ключам командной строки.

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

Где:

-Nзапрет на выполнение удаленных команд.

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

[email protected]это конструкция имя_пользователя@адрес_сервера(или доменное имя сервера).

-L 2110:localhost:110информация привязки. Структура: порт_клиента:имя_хоста:порт_сервера . В этом примере мы привязываем POP3 порт сервера на порт 2110 своего локального компьютера.

Несколько полезных примеров.

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

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

Вообще, все что пересылается в виде открытого текста, можно обезопасить путем заворачивания в туннель SSH. Установив туннель, вы должны на клиентской стороне выставить имя хоста как localhost и порты, какие вам нужны, будь то 2110,2020,5223 или любые другие.

Зашифруйте свой HTTP трафик

Еще одна тема для дисклаймера. Если вы работаете в компании, которая имеет политику безопасности для пользователей, проверьте документ, перед тем как делать это.

Я это проделываю, будучи где угодно за городом или в месте, где есть беспроводная точка доступа, которым я не доверяю. Если у меня с собой Андроид-планшет, я использую приложение SSHTunnel. На ноутбуке же ввожу команду как показано ниже:

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

Туннелирование Х протокола и сессий VNC

Помните птичку 'X11Forwarding yes' в конфигурационном файле? Это то место, где обеспечивается туннелирование протокола Х-сервера.

Как можно догадаться, опция -X обеспечивает туннелирование Х. Помните однако, что команда обеспечит туннелирование вашего приложения с вашей удаленной машины на вашу клиентскую машину с Линуксом. Если же вы в Виндоус, просто установите Cygwin/X (http://x.cygwin.com/) на вашу гостевую машину. Я сам этого не пробовал, но как понимаю это должно помочь запустить удаленное Х-приложение в Виндоус.

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

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

Реверсивные SSH туннели

Моя любимая фишка в SSH-туннелирвании. Действительно, доступ к сервисам через SSH, например, шифрование всего HTTP-потока, это прикольно. Но реальный сюрприз нас ждет в тот момент, когда мы понимаем, что можем обратить, реверсировать туннель. Как я уже говорил, если вы за межсетевым экраном, который не имеет SSH-сервера, но нуждаетесь в доступе и не желаете устанавливать VPN-соединение, что вам делать? Время от времени мне бывает нужно обеспечить такой сеанс своим родственникам или знакомым. В этом случае вы можете подсоединиться к вашему SSH-серверу, затем обратить туннель путем присоединения к этому открытому соединению. Для этого родственник может запустить сессию putty с сохраненными параметрами, присоединившись к SSH-серверу под определенным пользователем без прав. Когда туннель установлен, я могу с помощью VNC попасть на такую удаленную машину.

Шаги для установления реверсивного туннеля следующие.С клиентской машины:

ssh -R remoteport:localhost:22 username@servername

Для более ясного примера подставим в команду реальные параметры:

На стороне сервера для переустановления туннеля:

И вот вы его заимели, реверсивный туннель.

Для наглядности daddoo и nerdboy4200 из #linuxjournal объединили свои усилия и создали Mscgen, это программулина, которая парсит последовательность сообщений и строит наглядную диаграмму обмена сообщениями для разных протоколов. Она конечно, опенсорсная и довольно ужасна на вид ( http://www.mcternan.me.uk/mscgen/ ). Для случая реверсивного туннеля с помощью своего поделия они построили диаграмму (далее автор вставил в свой текст диаграмму, на которой ничего не видно - прим. перев.).

Заключение

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

______________________

www.jaysonbroughton.com

Назад в тематический каталогНазад на страницу переводов из Linux Journal

www.lexpr.ru

IT_blogs: SSH проброс портов

Мой замечательный провайдер выделил белый IP адрес в интернетеНе долго думая попросил пробросить мне портыПоскольку работаю Freelancer'ом ездить на работу мне удовольствия не доставляетVPN решил не использовать из-за избыточности.И мой сервер не приготовлен для VPN. Пришлось бы полностью перенастраивать.Да и клиентскую часть от OpenVpn таскать с собой...К счастью нашлось решение: SSh2)Для начала правим конфиг SSHnano /etc/ssh/sshd_configДобавляемAllowTcpForwarding yesПерезапускаем SSH/etc/rc.d/sshd restart (FreeBSD)/etc/init.d/sshd restart (Linux)2)Локальный пробросИз названия следует, что проброс будет действовать для локальной сетиДелаем:ssh -L9999:192.168.5.230:3128 192.168.1.1после авторизации на вашем локальном будет слушаться порт 9999. Т.е Мы пробросили 192.168.5.230:3128 на 192.168.1.1:9999

Проверить можно следующим образом:

netstat -lnp | grep 9999tcp 0 0 127.0.0.1:9999 0.0.0.0:* LISTEN 16384/sshТеперь немного подробнее о параметрах:-L - указывает что будем организовывать локальный проброс порта, то есть наш туннель будет открываться на локальной машине, то есть на локальной машине будет слушаться порт9999 - указывает какой именно порт мы будем открывать локально192.168.5.230:3128 - указывает на какой хост:порт мы будем пробрасывать туннель, хост который видно с сервера на который мы устанавливаем ssh соединени

В результате наших действий если поставить в браузере прокси сервер 127.0.0.1:9999 мы будем, к примеру, ходить в интернет через прокси-сервер который находится в другой подсети.3) Удалённый пробросДействует не только локально, но и удалённо.

ssh -R2222:localhost:22 234.12.34.34илиssh -R2222:192.168.1.234:22 234.12.34.34

Мы пробросили на 234.12.34.34:2222 адрес 192.168.1.234:22

Т.е сначала делаем туннель.

ssh 234.12.34.34 -p 2222 -v-v это для отладки, что-бы видеть что происходитЗатем не прекращая сессии подключаемся к 234.12.34.34 по порту 2222И получаем доступ к 192.168.1.234 по 22 порту

ОригиналО том как сделать постоянный проброс портов для нескольким приложений читать Здесь

itbg.davnozdu.ru

Проброс портов используя SSH | ProfHelp

Для того, чтоб получить удаленный доступ к компьютерам сети, располагающимся за NAT, не обязательно настраивать проброс портов в правилах фаервола на роутере. Если вы имеете SSH доступ к роутеру, то достаточно прописать проброс портов в настройках SSH клиента.

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

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

Итак, для настройки проброса портов средствами SSH имеется два пути:

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

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

-L [bind_address:]port:host:hostport

Данная команда сообщает, что указанный порт локального компьютера будет проброшен на host:hostport в удаленной сети за NAT сервером. Сокет будет слушать на интерфейсе указанном в bind_address, а если bind_address опустить, или вместо него поставить символ ‘*’, то подключения будут приниматься на всех интерфейсах. Для хоста, к которому мы подключаемся процесс подключения будет выглядеть так, как будто к нему подключается см NAT роутер.Для того, чтоб применить параметры командной строки на постоянной основе, следует прописать их в конфигурационном файле ~/.ssh/config, или /etc/ssh/ssh_config. Для этого предназначен параметр LocalForward и записывается он в следующей форме:

LocalForward [bind_address:]port host:hostport

Здесь, опять-же, по аналогии с командной строкой bind_address можно опустить, или вместо него поставить символ ‘*’.

Настройка проброса портов при помощи PuTTY

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

Для того, чтоб настроить проброс портов в программе PuTTY SSH Client, следует:

Открыть в категориях: Connection - SSH - Tunnels.
Указать локальный порт (Source port)
Указать целевой хост и порт (Destination)
Остальные параметры можно оставить по умолчанию и нажать кнопку Добавить (Add).

В данном примере при подключении к к локальному порту 5001 вы будете подключены к RDP порту удаленного сервера 10.10.1.2.

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

profhelp.com.ua

Перенаправление портов в SSH

Взято: http://www.opennet.ru/base/sec/ssh_tunnel.txt.html

Перевод: Сгибнев Михаил

Введение

Обычно SSH используется для регистрации на удаленном сервере с целью проведения технического обслуживания, чтения почты, управления сервисами и тому подобных задач администрирования. SSH также предоставляет некоторые другие сервисы, такие как копирование файлов (используя scp и sftp) и удаленное выполнение команд (используя ssh с указанием команды после имени хоста при выполнении из командной строки).

Всякий раз используя SSH для соединения одной машины с другой, мы создаем безопасный сеанс связи. Вы можете ознакомиться с другими статьями, связанными с настройкой и эксплуатированием SSH: SSH Host Key Protection, SSH User Identities и SSH and ssh-agent.

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

Пример локального перенаправления

Предположим, что на вашей машине имеется почтовый клиент и вы получаете письма с почтового сервера по протоколу POP (Post Office Protocol), порт 110. Вы хотите защитить ваше POP соединение с целью препятствовать перехвату пароля или почты (Некоторые POP серверы поддерживают дополнительные методы авторизации, типа S/Key или обмен запросами).

В обычном случае, клиент создает сессию с портом TCP за номером 110, вводится имя пользователя и пароль и скачиваются письма. Давайте просто попробуем использовать telnet или nc:

xahria@desktop$ nc mailserver 110 +OK SuperDuper POP3 mail server (mailserver.my_isp.net) ready. USER xahria +OK PASS twinnies +OK User successfully logged on. LIST +OK 48 1420253 1 1689 2 1359 3 59905 ... 47 3476 48 3925 . QUIT +OK SuperDuper POP3 mail server signing off. xahria@desktop$ Мы можем перенаправить эту TCP-сессию внутрь SSH-сессии используя перенаправление портов. Если мы имеем доступ по SSH к машине, на которой запущен требуемый нам сервис (в нашем случае POP, порт 110), то цель близка и приятна. Также, для наших целей мы можем использовать любой SSH-сервер в сети, из которой доступен целевой почтовый сервер.

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

# first, show that nothing's listening on our local machine on port 9999: xahria@desktop$ nc localhost 9999 Connection refused. xahria@desktop$ ssh -L 9999:mailserver:110 shellserver xahria@shellserver's password: ******** xahria@shellserver$ hostname shellserver С другого терминала вашей машины соединитесь с портом 9999 своей же машины(localhost). xahria@desktop$ nc localhost 9999 +OK SuperDuper POP3 mail server (mailserver.my_isp.net) ready. USER xahria +OK PASS twinnies ... Прежде чем мы соединились с shellserver по SSH ничто не слушало на порту 9999. Именно технологии туннелирования мы обязаны волшебному появлению на порту 9999 нашей локальной машины приглашения почтового сервера. Давайте подробно разберем предложенный пример:

Вы запустили клиент SSH /usr/bin/ssh из командной строки
Клиент регистрируется на удаленной машине используя один из методов авторизации (пароль или ключ)
SSH клиент занимает определенный вами локальный порт 9999 на кольцевом интерфейсе 127.0.0.1 (loopback)
Открытая же сессия с удаленной машиной вполне пригодна для использования, вы можете архивировать файлы или удалить /etc/shadow...
Когда же вы соединяетесь с локальной машиной 127.0.0.1 на порт 9999, то клиентская программа /usr/bin/ssh принимает соединение.
SSH клиент информирует сервер через шифрованный канал о необходимости создать соединение с mailserver, порт 110
Клиент принимает все данные, посылаемые на порт и посылает их серверу через шифрованный туннель, который расшифровывает их и передает их открытым текстом на mailserver, порт 110
При завершении сеанса любой из точек, туннель также прекращает существование.

Отладка перенаправления

Давайте рассмотрим этот механизм, используя опцию отладки: xahria@desktop$ ssh -v -L 9999:mailserver:110 shellserver debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: Connecting to shellserver [296.62.257.251] port 22. debug1: Connection established. debug1: identity file /home/bri/.ssh/identity type 0 debug1: identity file /home/bri/.ssh/id_rsa type 1 debug1: identity file /home/bri/.ssh/id_dsa type 2 ... debug1: Next authentication method: password xahria@shellserver's password: ******** debug1: Authentication succeeded (password). debug1: Connections to local port 9999 forwarded to remote address localhost:110 debug1: Local forwarding listening on 127.0.0.1 port 9999. debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: channel 0: request pty-req debug1: channel 0: request shell xahria@shellserver$ Как вы видите, порт 9999 резервируется для открытия туннеля. В настоящее время мы не соединяемя с этим портом, поэтому туннель не открыт. Вы можете использовать escape-последовательность ~# для просмотра соединений. Эта последовательность работает только после символа перевода каретки, поэтому вам придется сделать так: xahria@shellserver$ (enter) xahria@shellserver$ (enter) xahria@shellserver$ (enter) xahria@shellserver$ ~# The following connections are open: #1 client-session (t4 r0 i0/0 o0/0 fd 5/6) xahria@shellserver$ Видим, что в системе открыта только одна SSH-сессия, используя именно ее, мы вводим текущие команды unix.

Так, а теперь попробуем выполнить команду telnet localhost 9999 и просмотрим состояние соединений:

xahria@shellserver$ (enter) xahria@shellserver$ ~# The following connections are open: #1 client-session (t4 r0 i0/0 o0/0 fd 5/6) #2 direct-tcpip: listening port 9999 for mailserver port 110, connect from 127.0.0.1 port 42789 (t4 r1 i0/0 o0/0 fd 8/8) И что же мы видим? Таки туннель был создан! Мы можем воспользоваться утилитами netstat или lsof, чтобы увидеть соединение с 127.0.0.1, порт 42789 на 127.0.0.1, порт 9999.

Пример удаленного перенаправления

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

Приведем классический пример использования удаленного перенаправления.Вы весь в работе, а на выходные VPN доступ закрывается на техническое обслуживание. Однако, у вас действительно имеется очень важная работа, но вы предпочитаете делать ее дома, вместо того, что бы торчать в офисе в выходные. И по SSH к вашей рабочей машине никак не пробиться, ибо наличествует фаервол. Значит, перед уходом домой, сделаем пару движений. Ваш ~/.ssh/config должен содержать такие строки:

lainee@work$ tail ~/.ssh/config Host home-with-tunnel Hostname 204.225.288.29 RemoteForward 2222:localhost:22 User laineeboo lainee@work$ ssh home-with-tunnel [email protected]'s password: ******** laineeboo@home$ ping -i 5 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.2 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.2 ms ... Мы утановили в файле конфигурации SSH опцию RemoteForward, она то и позволяет осуществить туннелирование (в случае использования командной строки используйте опцию -R). Для того, чтобы удостовериться, что наше соединение не блокируется системой сетевой защиты, выполним команду ping: Вечером на домашней машине удостоверимся в удачном исходе дела: laineeboo@home$ last -1 laineeboo pts/18 firewall.my_work.com Tue Nov 23 22:28 still logged in laineeboo@home$ ps -t pts/18 PID TTY TIME CMD 3794 pts/18 00:00:00 ksh 4027 pts/18 00:00:00 ping -i 5 127.0.0.1 В результате, все соединения на порт 2222 вашей домашней машины будут туннелированы назад через корпоративный фаервол на порт 22 вашей машины на работе. Сделаем же сиё нехитрое действо: laineboo@home$ ssh -p 2222 lainee@localhost lainee@localhost's password: ******** lainee@work$ Какая радость и бурный восторг!

Port Forwarding Cheat Sheet

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

Локальное перенаправление

Опции командной строки	-L local_listen_port:destination_host:destination_port
Строки в файле конфигурации	LocalForwardlocal_listen_port:destination_host:destination_port
local_listen_port is on	SSH client loopback interface
destination_host is contacted from	SSH server host

Удаленное перенаправление

Опции командной строки	-R remote_listen_port:destination_host:destination_port
Строки в файле конфигурации	RemoteForwardremote_listen_port:destination_host:destination_port
remote_listen_port is on	SSH server loopback interface
destination_host is contacted from	SSH client host

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

Безопасность перенаправления портов

Перенаправление занимает порт на ssh клиенте(локальное перенаправление) или на ssh сервере (удаленное перенаправление). По умолчанию, этот порт будет доступен только на кольцевом интерфейсе 127.0.0.1, это означает, что туннель будет доступен только локальному пользователю.

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

	Command line option	Configuration file option
LocalForwards	-g	GatewayPorts yes(in ~/.ssh/config or /etc/ssh/ssh_config)
RemoteForwards	(none available)	GatewayPorts yes (in /etc/sshd_config)

Другая важная вещь, которую Вы должны помнить - то, что поток данных шифруется только на участке между ssh клиентом b ssh сервером. Если определенный вами destination_host - не localhost, то то часть трафика не будет зашифрована. Рассмотрим пример: desktop$ ssh -L 8080:www.example.com:80 somemachine Любое соединение с localhost:8080 будет зашифровано на участке от desktop до somemachine, но пойдет открытым текстом от somemachine до www.example.com. Если это соответствует вашей концепции безопасности, то проблемы нет.

To be cont...

www.mianet.ru

Памятка пользователям ssh

Спасибо автору!

Взято: http://habrahabr.ru/post/122445/

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

Оглавление:

управление ключами
копирование файлов через ssh
Проброс потоков ввода/вывода
Монтирование удалённой FS через ssh
Удалённое исполнение кода
Алиасы и опции для подключений в .ssh/config
Опции по-умолчанию
Проброс X-сервера
ssh в качестве socks-proxy
Проброс портов — прямой и обратный
Реверс-сокс-прокси
туннелирование L2/L3 трафика
Проброс агента авторизации
Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Генерация ключа

Сменить пароль на ключ можно с помощью команды ssh-keygen -p.

Структура ключа

Копирование ключа на сервер

Ключ сервера

Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Их можно:а) скопировать со старого сервера на новый.б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.

Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.

scp path/myfile [email protected]:/full/path/to/new/location/

Обратно тоже можно: scp [email protected]:/full/path/to/file /path/to/put/here

Так тоже можно:

Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).

Использование: установить пакет sshfs (сам притащит за собой fuse).

#!/bin/bash sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o reconnect

Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:

Параметры sshfs, которые могут оказаться важными: -o reconnect (говорит пытаться пересоединиться вместо ошибок).

Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:

В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.

ssh может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:

ssh user@server ls /etc/

Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.

Некоторые приложения хотят иметь управляющий терминал. Их следует запускать с опцией -t: ssh user@server -t remove_command

Кстати, мы можем сделать что-то такого вида: ssh user@server cat /some/file|awk '{print $2}' |local_app

Это нас приводит следующей фиче:

Проброс stdin/out

Допустим, мы хотим сделать запрос к программе удалённо, а потом её вывод поместить в локальный файл

ssh [email protected] command >my_file

Допустим, мы хотим локальный вывод положить удалённо

mycommand |scp — [email protected]:/path/remote_file

mycommand | ssh [email protected] «scp — [email protected]:/path/to/file»

Есть и вот такой головоломный приём использования pipe'а (любезно подсказали в комментариях в жж):

tar -c * | ssh user@server "cd && tar -x"

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

Host ric Hostname ооо-рога-и-копыта.рф User Администратор ForwardX11 yes Compression yes Host home Hostname myhome.dyndns.org User vasya PasswordAuthentication no

Все доступные для использования опции можно увидеть в man ssh_config (не путать с sshd_config).

По подсказке UUSER: вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например:

Host * User root Compression yes

Собственно, немножко я проспойлерил эту часть в примере конфига выше. ForwardX11 — это как раз оно.

Ключики: -X — проброс X-сервера. -Y проброс авторизации.

Достаточно просто запомнить комбинацию ssh -XYC user@SERVER.В примере выше (названия компании вымышленные) я подключаюсь к серверу ооо-рога-и-копыта.рф не просто так, а с целью получить доступ к windows-серверу. Безопасность microsoft при работе в сети мы все хорошо знаем, так что выставлять наружу голый RDP неуютно. Вместо этого мы подключаемся к серверу по ssh, а дальше запускаем там команду rdesktop: ssh ric rdesktop -k en-us 192.168.1.1 -g 1900x1200

Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.

Подключение в режиме sock-proxy выглядит так:

ssh -D 8080 user@server

Вот так выглядит мой конфиг:

/etc/ssh/sshd_config:(фрагмент)Port 22Port 443

А вот кусок ~/.ssh/config с ноутбука, который описывает vpn

Host vpn Hostname desunote.ru User vasya Compression yes DynamicForward 127.1:8080 Port 443

(обратите внимание на «ленивую» форму записи localhost — 127.1, это вполне себе законный метод написать 127.0.0.1)

Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:

Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.

ssh -R 127.1:80:8.8.8.8:8080 [email protected]

Опция -R позволяет перенаправлять с удалённого (Remote) сервера порт на свой (локальный).Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.Задача. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost'у.

Итоговая конфигурация: запросы на localhost:3333 на 'A' должны обслуживаться демоном на localhost:3128 'Б'.

ssh -L 127.1:333:127.1:3128 [email protected]

Опция -L позволяет локальные обращения (Local) направлять на удалённый сервер.

Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.

ssh -L 192.168.0.2:8080:10.1.1.1:80 [email protected]

Вложенные туннели

Разумеется, туннели можно перенаправлять.

Решение сложно: ssh -L 192.168.0.2:8080:127.1:9999 [email protected] ssh -L 127.1:9999:127.1:80 [email protected]

Реверс-сокс-прокси

Если предыдущий пример вам показался простым и очевидным, то попробуйте догадаться, что сделает этот пример: ssh -D 8080 -R 127.1:8080:127.1:8080 [email protected] ssh -R 127.1:8080:127.1:8080 [email protected] Если вы офицер безопасности, задача которого запретить использование интернета на сервере 10.1.1.2, то можете начинать выдёргивать волосы на попе, ибо эта команда организует доступ в интернет для сервера 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.

Подробнее описано тут: www.khanh.net/blog/archives/51-using-openSSH-as-a-layer-2-ethernet-bridge-VPN.html

(сам я увы, таким не пользовался).

Для начала о простом пробросе авторизации.

Повторю картинку:

Вызов выглядит так:

ssh -A [email protected] ssh [email protected]

В большинстве случаев это прокатывает.

Эту клёвую настройку я не знал, и раскопал её redrampage.

Выглядит это так (циферки для картинки выше):

.ssh/config:

Host raep HostName 10.1.1.2 User user2 ProxyCommand ssh -W %h:%p [email protected]

Ну а подключение тривиально: ssh raep.

Повторю важную мысль: сервер 10.1.1.2 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить — да, может. Но если разрешил — пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для [email protected], так и в [email protected]