ТОП-20 трюков и советов для работы с SSH-туннелями


Оглавление (нажмите, чтобы открыть):

OpenSource в заметках

При работе с удалёнными системами одной, пожалуй, из самых часто-используемых утилит системными администраторами и многими пользователями является ssh. Простая, надёжная, проверенная. Однако не каждый знает, что варианты использования secure shell более разнообразны, чем простое подключение к удалённой оболочке. Сегодня мы рассмотрим пять интересных трюков с ssh и с scp, которые многим могут пригодиться в работе и скрасить трудовые будни администраторов, разработчиков и простых пользователей.

X-сессия через SSH-туннель

Иногда бывает необходимо запустить X-приложение на удалённом хосте, при этом графический ввод-вывод перенаправить на локальный. Кроме традиционных вариантов с использованием XDMCP существует многим известный способ перенаправить ввод-вывод X-сессии в SSH-туннель.

Первым делом убедитесь, что в конфигурации вашего демона SSH включена опция X11Forwarding, разрешающая перенаправление X-сессии. В файле, расположенном обычно в /etc/ssh/sshd_config, раскомментируйте или добавьте строку:

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

После того, как будет изменено содержимое конфигурационного файла SSH-сервера, его необходимо перезапустить:

Теперь со стороны клиента можно инициировать SSH-подключение с перенаправлением X-сессии:

И после того, как авторизуетесь, можно запускать любые X-приложения, например:

Или, как вариант, можно запустить приложение в «фоновом режиме», т. е. не оставаясь подключённым к удалённой оболочке:

Поиск фалов на удалённом компьютере

Очень полезно бывает иногда найти файлы на удалённом компьютере, получив результаты поиска в локальном терминале. Сделать это очень просто. Например:

Само-собой, подобным образом вы можете выводить локально результаты работы любой удалённой команды.

Редактирование удалённых файлов в Vim

Вовсе необязательно подключаться к удалённой оболочке и редактировать файл непосредственно на сервере. Некоторым нравится делать это локально. Следующая команда запустить Vim, безопасно скопирует удалённый файл при помощи scp и после выхода из редактора обновит изменения на сервере, если таковые будут:

Кстати, помимо всего прочего, если соединение с сервером вдруг оборвётся, вас это не будет никоим образом волновать. Всё происходит локально, так что обрыв соединения с удалённым сервером не грозит вам потерять результаты работы.

Воспроизведение музыки с удалённого сервера

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

Воспроизведение видео с удалённого сервера

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

Пять трюков с SSH : 5 комментариев

По поводу проброса иксов через ssh я думаю стоит ещё рассказать о самом интересном применение технологии. На сервере вообще может не быть иксов, а с таким туннелем можно часть вещей настраивать в GUI. Самым простым примером может служить VirtualBox. Ставим его из репозитариев на сервер, пробрасываем иксы и настраиваем виртуалку в привычной среде. При этом и нам удобно и сервер не забит миллионом библиотек для отрисовки графики.

Важное замечание — на сервере должна стоять программа/пакет «xauth». Это принципиальный момент если вы пытаетесь подключиться к серверу на котором _нет_ x-сервера.

Мне кажется автор слабо представляет то, о чем пишет:

«Далее, на сервере необходимо указать IP-адрес клиента, которому разрешено инициировать X-сессию. Делается это при помощи команды xhost:

Теперь со стороны клиента с IP-адресом 1.2.3.4 можно инициировать SSH-подключение с перенаправлением X-сессии:

При использовании ssh -X НЕ ТРЕБУЕТСЯ ни каких xhost! Финт с xhost нужен, если вы хотите на машине, где запускаете приложение указать DISPLAY=1.2.3.4:0 и запустив приложение увидеть его окно на машине 1.2.3.4! При использовании ssh -X или -Y используется тунелирование и авторизация X-приложений через xauth. Так что пожалуйста не вводите людей в заблуждение: почитайте документацию и исправьте статью.

OllyCat, спасибо огромное за замечание. Это меня всё XDMCP не отпускает и поэтому бездумно слизал в оригинала статьи.

Да, я так и понял. 🙂 Но если бы вы прочли комментарии к ней, то увидели бы, что там на это ему тоже указали. 😉

Создание туннеля внутрь сети поверх SSH-сессии

Не знаю, как вам, а мне лично данная фича SSH оказалась очень полезна, хотя я только недавно взял её на вооружение. Если кто-то ещё не знал, что так можно – прошу читать и просвещаться. Надеюсь, кому-то тоже пригодится.

Суть туннелирования

Суть в том, что мы можем создать разновидность туннеля внутри созданной SSH-сессии и трафик будет передаваться в шифрованном виде как будто в трубе. Принцип возможно понятен будет из картинки (честно стыреной с Интернета):

Удалённый клиент устанавливает соединение с SSH-сервером на границе корпоративной сети. Затем он, по установленному соединению, может обращаться к внутренним узлам сети так, как если бы он был этим самым SSH-сервером. Здесь можно увидеть параллели VPN и NAT-технологий. Давайте подумаем над сценариями использования:

Сценарий 1. Устранение неполадок внутри сети удалённо

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

  1. Скорее бежать на работу. Было чрезвычайно ранее время и я очень не хотел этого делать.
  2. Подключиться удалённо к шлюзу, совмещающему функции межсетевого экрана, добавить правило форвардинга в файрволл, пробросить себя дальше вглубь сети. Но это создаст некую “дверь” в защите, которую потом желательно бы не забыть убрать.
  3. Подключиться удалённо к шлюзу и внутри этой сессии прыгнуть со шлюза дальше, прописав правило туннелирования. Делается это так:
    В конфигурации PuTTY в разделе “Connection -> SSH -> Tunnels” добавим незанятый порт источник и адрес гипервизора:порт назначения, тип выберем “Local” и нажмём кнопку “Add”.
    PuTTY начнёт прослушивать этот локальный порт, в этом нетрудно убедиться выполнив команду netstat -abn с правами Администратора:
    Теперь откроем в браузере адрес 127.0.0.1:12345 и …. попадём на страничку гипервизора:
    Когда решим все проблемы – просто разрываем SSH-сессию и всё, никаких изменений в межсетевом экране подправлять не придётся. При желании можно прокинуть не один порт, а несколько. И не на один сервис, а на разные, хоть на RDP, хоть на веб, хоть на SSH до внутреннего оборудования.

Сценарий 2. Защита административных интерфейсов.

Чтобы не городить с множеством файрволлов, можно сделать вот какую тему:

  1. Поднять один SSH-сервер в сети, защитить его как следует – файрволл, PortKnocking, авторизация по ключам – не важно, главное, чтобы он был один. Один сервер защитить всегда проще;
  2. Для всего остального “админского” царства задать доступ только с этого адреса. Не нужно прописывать все айпишники админов, если их несколько. Только один адрес для управления. Можно даже экзотический порт, чтоб наверняка;
  3. С целью администрирования подключаться по SSH на этот сервер, затем через туннель нырять дальше, куда хочешь. Хочешь – на циску, хочешь – на гипервизор, хочешь – на другой сервер по RDP.

Главное, что этот стартовый сервер может быть нормально защищён (SSH), а также будет вести логи – кто откуда к нему цеплялся и куда прыгал.

Эти сценарии не единственно возможные, можно придумывать различные комбинации и вариации! Но без сомнения, данный инструмент в копилке админа будет наверняка нужным!

Подробное описание SSH и примеры использования туннелей

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

Друзья попросили написать об этом статью. Но поскольку подобные описания уже существуют, то не было смысла переписывать это ещё раз. Была найдена вот эта отличная статья иженера компании «Белтел» — Сергея Герасимова. При перепечатке она подверглась незначительной редактуре для удобства восприятия, и дополнена моими комментариями.

Эта статья, практически рассказывает об SSH на пальцах.

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

SSH — это магия, друзья!

Зачем нужен SSH?

Каждый системный администратор или сетевой инженер хоть раз в своей практике сталкивался с ситуацией, когда нужно получить доступ из публичной сети Интернет к ресурсам своей рабочей сети, скрытой за NAT и защищённой фаерволом.
Конечно, для решения этой задачи можно настроить шифрованный site-to-site туннель или PPTP.

Или же воспользоваться сторонним приложением для организации удалённого доступа, например TeamViewer. Однако есть более простое решение, на реализацию которого уйдет буквально одна минута. К тому же, это решение не требует никакого стороннего программного обеспечения, кроме включённого по умолчанию в 90% Linux/Unix дистрибутивов пакета OpenSSH.

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

Как работает SSH-туннелирование

SSH туннель или SSH Port Forwarding, как его называет man(1) ssh – это опциональный функционал протокола, который работает поверх всем знакомой обычной SSH сессии. SSH туннель позволяет послать TCP пакет с одной стороны SSH соединения на другую его сторону и произвести трансляцию IP заголовка по заранее определенному правилу в процессе передачи.
Понять, как работает SSH туннель очень просто: если представить его в виде point-to-point соединения. Так же как и в PPP, любой пакет, попавший в один конец соединения,
будет передан и получен на другом конце туннеля. Дальше, в зависимости от адреса получателя заданного в IP заголовке, пакет будет либо обработан принимающей стороной туннеля (если пакет предназначается непосредственно ей), либо смаршрутизирован дальше в сеть (если адресатом является другой узел сети).

Основное отличие SSH туннеля от PPP соединения в том, что в SSH туннель можно завернуть только TCP трафик. (Примечание: есть несколько хаков, как можно передать UDP через TCP-сокет внутри SSH туннеля, но это решение выходит за рамки данной статьи).
Второе отличие состоит в том, что в point-to-point
соединении входящий трафик может быть инициирован с любой стороны, тогда как для SSH туннеля необходимо явно задать «точку входа» для трафика. «Точка входа» – это параметр вида : ,

указывающий какой сокет открыть для входа в туннель (с локальной или удалённой стороны SSH сессии).
Кроме точки входа дополнительно нужно указать правило вида
: , по которому должен
быть переписан заголовок (точнее, адрес и порт назначения) TCP пакета в процессе передачи. Точка входа может задаваться с любого конца туннеля. За этот параметр отвечают ключи –L (local) и –R (remote). Под local
и remote подразумеваются стороны туннеля с точки зрения стороны-оригинатора, то есть того хоста, который устанавливает SSH сессию.

Пока выглядит немного запутанно, поэтому давайте разберём на конкретном примере.

Прямой туннель SSH — обеспечиваем доступ к серверу за NAT

Алекс работает системным администратором в маленькой
компании Qwerty Cakes, занимающейся производством яблочных пирогов. Вся сеть компании находится в
одном броадкаст домене 192.168.0.0/24. Для доступа в интернет используется программный маршрутизатор на базе Linux, адрес которого 192.168.0.1 со стороны сети компании и
1.1.1.1 со стороны сети Интернет. На маршрутизаторе поднят и работает демон OpenSSD, который доступен по сокету
1.1.1.1:22. Внутри сети на сервере с адресом 192.168.0.2 установлен внутренний корпоративный портал, на котором до завтрашнего утра Алексу нужно сделать изменения через Web интерфейс. Однако Алекс не хочет задерживаться на работе допоздна, он хочет получить доступ к порталу из дома со своего домашнего компьютера с адресом
2.2.2.2.

Алекс приходит домой и после ужина устанавливает следующее соединение с маршрутизатором компании:

Что произошло? Алекс установил SSH сессию между адресами 2.2.2.2 и 1.1.1.1, при этом открыв локальную «точку входа» в туннель 127.0.0.1:8080
на своем домашнем компьютере:

$ sudo lsof -nPi | grep 8080

ssh 3153 alex 4u IPv4 9862 0t0 TCP 27.0.0.1:8080 (LISTEN)

Любой TCP пакет, который попадёт в сокет 127.0.0.1:8080 со стороны компьютера Алекса, будет отправлен по point-to-point соединению внутри сессии SSH, при этом адрес
назначения в TCP заголовке будет перезаписан с 127.0.0.1 на 192.168.0.2, а порт с 8080 на 80.

Теперь Алексу, чтобы попасть на портал своей компании, нужно всего лишь набрать в браузере:

Как проходят сетевые пакеты внутри SSH-туннеля

Давайте детально разберём, что произошло с TCP пакетом в процессе его прохождения по SSH туннелю:

1. TCP пакет с адресом источника 127.0.0.1 и адресом и портом назначения 127.0.0.1:8080 попал в сокет 127.0.0.1:8080, открытый процессом ssh;
2. Процесс ssh получил пакет, в соответствии с правилом трансляции переписал адрес и порт назначения на 192.168.0.2:80 и отправил его внутри SSH сессии удалённой
стороне 1.1.1.1;

3. Процесс sshd на маршрутизаторе 1.1.1.1 получил пакет и, просмотрев адрес назначения, отправил его хосту 192.168.0.2, переписав при этом адрес источника с 127.0.0.1
на адрес собственного интерфейса 192.168.0.1, для того чтобы получатель, который ничего не знает про существование SSH туннеля, вернул пакет роутеру, а не отправил в свой же localhost 127.0.0.1.

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

Если сервис доступен по адресу localhost (например, локальный SQL сервер), то и к нему
можно получить доступ:

$ ssh -L
127.0.0.1:13306:127.0.0.1:3306 alex@1.1.1.1

Конструкции вида -L 127.0.0.1:80:127.0.0.1:80 могут выглядеть, на первый взгляд, довольно странными. Но в них нет ничего сложного, если помнить, что решение о
маршрутизации пакета принимается на удалённой стороне туннеля. Нужно помнить основное правило: вторая пара
: обрабатывается удалённой стороной туннеля
.
Поэтому пакет с адресом назначения 127.0.0.1 в правиле трансляции будет обработан второй стороной SSH сессии, и никак иначе.

Как вы уже, наверное, догадались, точку входа в туннель можно создавать не только на loopback интерфейсе. Если туннель нужно сделать доступным не только для локального хоста, но и для других участников сети, то в качестве адреса сокета можно указать реальный адрес интерфейса.

$ ssh -L
10.0.0.5:8080:192.0.0.2:80 alex@1.1.1.1

Компьютер Алекса Alex-PC имеет два сетевых интерфейса с адресами 2.2.2.2 и 10.0.0.5. В процессе установления сессии ssh откроет сокет 10.0.0.5:8080 на компьютере Alex-PC. Теперь Алекс может получить доступ к порталу 192.168.0.2:80 со своего ноутбука с адресом 10.0.0.4 и со всей
своей домашней сети 10.0.0.0/24.

Обратный SSH-туннель — выставить свои ресурсы в интернет

Как я уже говорил, точку входа в туннель можно открывать не только со стороны оригинатора ssh сессии, но и с удалённой стороны, то есть с той, к которой мы устанавливаем ssh сессию. Для этого вместо параметра -L используется параметр -R. Для чего это нужно?
Например, для того, чтобы можно было опубликовать локальный сервис для удалённого доступа.

На ноутбуке Алекса запущен Web сервер apache доступный
по адресу 127.0.0.1 с тестовой копией портала компании. Алексу нужно дать доступ к Web серверу своим
коллегам для проведения тестирования интерфейса. Вообще, для подобных целей Алексу неплохо было бы реализовать более надёжную тестовую песочницу. Но так как наш Алекс не более чем виртуальный персонаж этой статьи, он для
демонстрации работы SSH туннеля устанавливает
сессию между своим ноутбуком и маршрутизатором Linux. А с помощью параметра -R открывает порт 8080 на
внутреннем интерфейсе маршрутизатора с адресом 192.168.0.1, который ссылается на сокет 127.0.0.1:80 его тестового Web сервера.

Как видите, на маршрутизаторе процесс sshd открыл локальный сокет 8080

$
sudo lsof -nPi | grep 8080

sshd
17233 alex 9u IPv4
95930 0t0 TCP 192.168.0.1:8080 (LISTEN)

Давайте посмотрим, что произойдёт с TCP пакетом, отправленным с компьютера 192.168.0.200 в сторону тестового портала, опубликованного на 192.168.0.1:8080:
1. TCP пакет с адресом источника 192.168.0.200 и адресом и портом назначения 192.168.0.1:8080 попадёт в сокет 192.168.0.1:8080, открытый процессом sshd;

2. Процесс sshd, получив пакет, в соответствии с правилом трансляции перепишет адрес и порт назначения с 192.168.0.1:8080 на 127.0.0.1:80 и отправит его внутри SSH сессии стороне-оригинатору 2.2.2.2;

3. Процесс ssh на ноутбуке Алекса, получив пакет и просмотрев адрес его назначения, перепишет адрес отправителя с 192.168.0.200 на адрес своего loopback, и отправит его в локальный сокет 127.0.0.1:80, открытый процессом apache.


Как видите, правила трансляции очень простые. Хост, который открывает сокет для туннеля, занимается трансляцией адреса и порта назначения согласно правилу трансляции. Хост с противоположной стороны туннеля производит подмену адреса и порта источника согласно своей таблице маршрутизации. Таблица маршрутизации необходима, во-первых, для того чтобы отправить пакет в нужную сторону, а, во вторых, для того чтобы произвести
подмену адреса источника на адрес интерфейса, с которого будет отправлен пакет.
Одно важное замечание, которое я оставил на конец статьи.
Если при открытии точки входа в туннель используется localhost вместо адреса реального интерфейса, то его можно опустить, сократив, таким образом, команду с

$ ssh -L 127.0.0.1:8080:192.0.0.1:80 alex@1.1.1.1

ssh -L
8080:192.0.0.1:80 alex@1.1.1.1

Эта важная особенность синтаксиса пригодится нам в следующем примере.

Двойное туннелирование

Давайте посмотрим на чуть более сложный пример. Пользователю SQL-Tester, находящемуся за NAT, нужно получить доступ к базе данных на SQL сервере, который тоже находится за NAT. SQL-Tester не может установить
соединение напрямую к серверу, так как в NAT серверной сети нет соответствующих трансляций. Однако от обоих хостов можно установить SSH сессию с промежуточным
сервером 3.3.3.3.

С SQL сервера устанавливаем SSH соединение с сервером 3.3.3.3 и открываем на loopback интерфейсе сервера
3.3.3.3 порт 13306, ссылающийся на локальный сервис SQL, запущенный на локальном сокете 127.0.0.1:3306 SQL сервера:

$ ssh -R 13306:127.0.0.1:3306
user1@3.3.3.3

Теперь с клиентского хоста SQL-Tester устанавливаем соединение с 3.3.3.3 и открываем порт 3306 на loopback интерфейсе клиента, который, в свою очередь, ссылается на 127.0.0.1:13306 на сервере
3.3.3.3, который… ссылается на 127.0.0.1:3306 на SQL сервере. Всё просто J

$ ssh -L
3306:127.0.0.1:13306 user2@3.3.3.3

Динамический туннель — SSH как Socks-прокси

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

Создаём сокет динамического туннеля 127.0.0.1:5555 на хосте client внутри сессии SSH к серверу 2.2.2.2

$ ssh -D 5555 user@2.2.2.2

Проверяем, что порт открыт

$ sudo lsof -nPi | grep 5555

ssh
7284 user 7u
IPv4 0x74fcb9e03a5ef5b1 0t0 TCP 127.0.0.1:5555 (LISTEN)

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

Теперь весь трафик браузера будет идти через SOCKS прокси внутри шифрованного соединения SSH
между хостами 1.1.1.1 и 2.2.2.2.

Как использовать SSH в Microsoft Windows?

Прочитав статью, вы возможно, решите, что все преимущества SSH туннелей доступны только
пользователям Unix-like систем. Однако это не так. Практически все терминальные клиенты для Windows работающие по протоколу SSH имеют поддержку туннелирования.

С некоторых пор, имеется возможность использовать Windows не только в качестве клиента SSH. Есть возможность установить SSH-сервер на Windows.

В каких случаях использовать SSH-туннели?

Конечно же, для создания постоянных туннелей на боевых серверах нужно использовать специальное программное обеспечение. Но для быстрого решения задачи по пробросу портов, траблшутинга, получения быстрого удалённого доступа да и вообще решения конкретной задачи “здесь и сейчас” зачастую хорошим подспорьем будет использование SSH туннелей.

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

Admin

IT-cпециалист с высшим техническим образованием и 8-летним опытом системного администрирования. Подробней об авторе и контакты. Даю бесплатные консультации по информационным технологиям, работе компьютеров и других устройств, программ, сервисов и сайтов в интернете. Если вы не нашли нужную информацию, то задайте свой вопрос!

Практические советы, примеры и туннели SSH

Практические примеры SSH , которые выведут на новый уровень ваши навыки удалённого системного администратора. Команды и советы помогут не только использовать

, но и более грамотно перемещаться по сети.

Знание нескольких трюков

полезно любому системному администратору, сетевому инженеру или специалисту по безопасности.

Практические примеры SSH

Сначала основы

Разбор командной строки SSH

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

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

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

. Порт прослушивания указывается в файле

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

: строка перед символом @ обозначает имя пользователя для аутентификации на удалённом сервере. Если не указать его, то по умолчанию будет использоваться имя пользователя учётной записи, в которую вы вошли в данный момент (

$ whoami). Пользователя также можно указать параметром

: имя хоста, к которому подключается

, это может быть полное доменное имя, IP-адрес или любой хост в локальном файле hosts. Для подключения к хосту, который поддерживает и IPv4, и IPv6, можно добавить в командную строку параметр

для правильного резолвинга.

Все вышеперечисленные параметры являются необязательными, кроме

Использование файла конфигурации

Хотя многие знакомы с файлом

, есть ещё файл конфигурации клиента для команды

. Значение по умолчанию

, но его можно определить как параметр для опции

В приведённом выше примерном файле конфигурации ssh две записи хоста. Первая обозначает все хосты, для всех применяется параметр конфигурации Port 2222. Вторая говорит, что для хоста remoteserver следует использовать другое имя пользователя, порт, FQDN и IdentityFile.

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

Копирование файлов по SSH с помощью SCP

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

В этом примере файл mypic.png скопирован на remoteserver в папку /media/data и переименован в mypic_2.png.

Не забывайте о разнице в параметре порта. На этом попадаются многие, кто запускает

из командной строки. Здесь параметр порта

, как в ssh-клиенте! Вы забудете, но не волнуйтесь, все забывают.

Для тех, кто знаком с консольным

, многие из команд похожи в

. Вы можете сделать push, put и ls, как сердце пожелает.

Практические примеры

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

1. SSH socks-прокси

Функция SSH Proxy под номером 1 по уважительной причине. Она более мощная, чем многие предполагают, и даёт вам доступ к любой системе, к которой имеет доступ удалённый сервер, используя практически любое приложение. Клиент ssh может туннелировать трафик через прокси-сервер SOCKS одной простой командой. Важно понимать, что трафик к удалённым системам будет исходить от удалённого сервера, так будет указано в логах веб-сервера.

Здесь мы запускаем socks-прокси на TCP-порту 8888, вторая команда проверяет, что порт активен в режиме прослушивания. 127.0.0.1 указывает, что служба работает только на localhost. Мы можем применить немного другую команду для прослушивания всех интерфейсов, включая ethernet или wifi, это позволит другим приложениям (браузерам и т д.) в нашей сети подключаться к прокси-сервису через ssh socks-прокси.

Теперь можем настроить браузер для подключения к socks-прокси. В Firefox выберите Настройки | Основные | Параметры сети. Укажите IP-адрес и порт для подключения.

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

Активация socks-прокси в Chrome

Запуск Chrome с определёнными параметрами командной строки активирует socks-прокси, а также туннелирование DNS-запросов из браузера. Доверяй, но проверяй. Используйте tcpdump для проверки, что DNS-запросы больше не видны.

Использование других приложений с прокси

Имейте в виду, что многие другие приложения тоже могут использовать socks-прокси. Веб-браузер просто самое популярное из них. У некоторых приложений есть параметры конфигурации для активации прокси-сервера. Другим нужно немного помочь вспомогательной программой. Например, proxychains позволяет запустить через socks-прокси Microsoft RDP и др.

Параметры конфигурации socks-прокси задаются в файле конфигурации proxychains.

Подсказка: если используете удалённый рабочий стол из Linux на Windows? Попробуйте клиент FreeRDP . Это более современная реализация, чем

, с гораздо более плавным взаимодействием.

Вариант использования SSH через socks-прокси

Вы сидите в кафе или гостинице — и вынуждены использовать довольно ненадёжный WiFi. С ноутбука локально запускаем ssh-прокси и устанавливаем ssh-туннель в домашнюю сеть на локальный Rasberry Pi. Используя браузер или другие приложения, настроенные для socks-прокси, мы можем получить доступ к любым сетевым службам в нашей домашней сети или выйти в интернет через домашнее подключение. Всё между вашим ноутбуком и домашним сервером (через Wi-Fi и интернет до дома) зашифровано в туннеле SSH.

2. Туннель SSH (переадресация портов)

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

. Его можно представить как локальную сторону прослушивания. Таким образом, в примере выше порт 9999 прослушивается на стороне localhost и переадресуется через порт 80 на remoteserver. Обратите внимание, что 127.0.0.1 относится к localhost на удалённом сервере!

Поднимемся на ступеньку. В следующем примере порты прослушивания связываются с другими узлами локальной сети.

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

3. SSH-туннель на сторонний хост


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

В данном примере мы перенаправляем туннель от remoteserver к веб-серверу, работающему на 10.10.10.10. Трафик с remoteserver к 10.10.10.10 уже не в SSH-туннеле. Веб-сервер на 10.10.10.10 будет считать remoteserver источником веб-запросов.

4. Обратный SSH-туннель

Здесь настроим прослушивающий порт на удалённом сервере, который будет подключаться обратно к локальному порту на нашем localhost (или другой системе).

В этой SSH-сессии устанавливается соединение с порта 1999 на remoteserver к порту 902 на нашем локальном клиенте.

5. Обратный прокси SSH

В этом случае мы устанавливаем socks-прокси на нашем ssh-соединении, однако прокси слушает на удалённом конце сервера. Подключения к этому удалённому прокси теперь появляются из туннеля как трафик с нашего localhost.

Устранение проблем с удалёнными SSH-туннелями

Если у вас возникли проблемы с работой удалённых опций SSH, проверьте с помощью

, к каким ещё интерфейсам подключён порт прослушивания. Хотя мы в примерах указали 0.0.0.0, но если значение GatewayPorts в sshd_config установлено в значение no, то листенер будет привязан только к localhost (127.0.0.1).

Предупреждение безопасности

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

6. Установка VPN по SSH

Общий термин среди спецов по методам атаки (пентестеры и проч.) — это «точка опоры в сети». После установления соединения в одной системе эта система становится шлюзом для дальнейшего доступа к сети. Точка опоры, которая позволяет двигаться вширь.

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

Используя этот более продвинутый вариант VPN, подключение снижается до уровня 3. Затем мы можем просто направить трафик через туннель, используя стандартную сетевую маршрутизацию.

viking_k

Записная книжка IT-шника

идеи / интересы / шлак

Оригинал: SSH Tunneling — Poor Techie’s VPN

«Если мы видим свет в конце туннеля, то это свет приближающегося поезда» (Роберт Лоуэлл)

Ну да, еще одна неплохая цитата. Эта статья посвящена туннелям через SSH или, как мне больше нравится называть их, «VPN для бедных». Вопреки распространенному среди сисадминов мнению, эти туннели могут быть весьма полезны как для технических специалистов, так и для обычных пользователей. Я говорю «вопреки распространенному мнению», поскольку обратные туннели и туннели с HTTP-трафиком внутри могут обходить файерволы и фильтры содержимого. Но эта статья не о том, как нарушать корпоративную политику пользования Интернетом, она о том, как с помощью SSH-туннелей сделать свою жизнь чуть легче.

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

Я дам здесь лишь самые основы: расскажу, как создавать туннели, объясню синтаксис команд, приведу примеры обратных туннелей и причины для использования каждого из них. Кратко коснусь файла ssh_config; более подробно он будет рассмотрен в будущем.

Итак, с чем мы будем работать? Я использую Debian в виртуальном окружении, поэтому ваши реалии могут отличаться от моих. В данном случае я использовал OpenSSH_5.3p1 в качестве сервера и различные OpenSSH-клиенты 5 версии. Перед тем, как углубиться в туннели, хочу сказать следующее: если вам хочется использовать SSH-туннели для шифрования HTTP или обратные SSH-туннели для обхода корпоративного файервола, удостоверьтесь, что вы не нарушаете никаких правил вашей компании. Нечего и говорить о том, что ваши системные администраторы начнут на вас охотиться, как только обнаружат такие проделки; сам будучи системным администратором, я получаю невыразимое удовольствие, отлавливая подобных индивидуумов. По крайней мере, предупредите их, чтобы они не были застигнуты врасплох. LinuxJournal.com и я не несут никакой ответственности за ваши нарушения вашей же корпоративной политики 🙂 Ну, а теперь перейдем к делу.

Создать SSH-туннель довольно просто. А вот решить, что с ним делать, может оказаться немного труднее. Поэтому я приведу несколько примеров, прежде чем мы вдадимся в детали. Я в свое время немного попутешествовал — это было на прежнем месте работы и до того, как у меня родились дети. В поездках мне доводилось останавливаться в самых странных гостиницах (думаю, вы с такими знакомы), оснащенных еще более странными беспроводными точками доступа. Захотите ли вы в гостинице подключиться к точке доступа, у которой SSID написан с орфографическими ошибками? Или в аэропорту, где вы обнаруживаете сразу несколько открытых точек? Если я нахожусь не дома, я пущу HTTP-трафик через туннель между своим устройством на Android (с root-доступом) и домашним сервером. Если же я работаю на ноутбуке, то открою SSH-туннель и пущу HTTP-трафик через Socks5 с тем, чтобы он весь был зашифрован средствами SSH. Я не доверяю открытым точкам доступа настолько, насколько могу. Что еще добавить? Мне приходилось «заворачивать» в туннели SMTP-трафик, когда я попадал в такие места, где блокировались исходящие SMTP-пакеты. То же самое мне приходилось делать и с POP3, с которого я недавно перешел на IMAPS. Другие примеры SSH-туннелей включают в себя проброс приложений X11 и сеансов VNC. Ранее я также упоминал обратные туннели. Они представляют собой. ну, вы сами понимаете — туннели, направленные в обратную сторону. В этом случае вы подключаетесь откуда-либо, где нет сервера SSH, к внешнему SSH-серверу. Потом, зарегистрировавшись на этом сервере, в том числе и локально, вы можете восстановить это подключение. Какая в этом польза, говорите? Ну, например, VPN-сервер вашей компании «упал» или работает только с VPN-клиентами под Windows, но вам совершенно не хочется тащиться с ноутбуком домой, чтобы проверить, работает ли тот или иной процесс. Придя домой, вы можете установить обратный туннель. В этом случае вам следует подключиться с сервера «Икс» к вашей домашней машине. Прибыв домой, вы восстанавливаете подключение к серверу «Икс», таким образом обходя файервол или VPN, и проверяете работу процесса без необходимости подключения по VPN. Я поступаю так очень редко, так как, на мой взгляд, подключение к серверу минуя файервол или VPN — это «плохое кунг-фу» и может использоваться лишь в самом крайнем случае.

Итак, вы получили несколько примеров SSH-туннелей, а теперь посмотрим, как это все делается.

Перед тем, как мы углубимся в работу на клиенте, немного отредактируем файл sshd_config на сервере. В /etc/ssh/sshd_config я обычно вношу некоторые изменения. Но не забудьте перед началом редактирования сделать его резервную копию на случай, если что-то пойдет наперекосяк.

Не забудьте, что если вы внесли какие-либо изменения в sshd_config, то вам нужно будет перезапустить сервис sshd для того, чтобы эти изменения вступили в силу.

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

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

Здесь ключи означают следующее:

-N — не выполнять команд на удаленной машине
-p 22 — подключаться на внешний порт 22. Я обычно использую другой внешний порт, чтобы избавиться от атак «кулхацкеров» на мой SSH-сервер
bob@mylinuxserver.xxx — имя_пользователя@имя_сервера (или IP-адрес)
-L 2110:localhost:110 — информация о привязке портов. Означает следующее: порт_клиента:имя_сервера:порт_сервера. В данном примере мы перенаправляем 110 порт сервера на 2110 порт вашей машины

Хотите еще немного примеров?

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

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

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

Шифрование HTTP-трафика

Еще одна вещь, понятная без лишних слов. Но если в вашей компании действует какая-либо политика относительно ИТ, проверьте, не нарушаете ли вы ее. Я пускаю HTTP-трафик через SSH в тех случаях, когда не доверяю точке доступа. Под Android я использую приложение SSHTunnel, а на ноутбуке — такую команду:

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

Перенаправление сеансов X и VNC

Припоминаете, что вы добавили » X11Forwarding yes» в sshd_config? Это-то и позволяет пробрасывать сеансы X.

Вы угадали, -X пробрасывает X. Но учтите, что это работает только на клиентских машинах с Linux. Если вы вдруг оказались вынуждены работать в Microsoft Windows, а вам нужен SSH-туннель, просто установите пакет Cygwin/X ( https://x.cygwin.com/ ). Я лично не пробовал с ним работать, но, насколько я понимаю, он предоставляет возможность запускать удаленные X-приложения, находясь в Windows.

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

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

Обратные SSH-туннели

Ну, вот и настало время для моей любимой разновидности SSH-туннелей. Разумеется, получать доступ к какому-либо сервису через SSH — это здорово, «гонять» веб-трафик по зашифрованным SSH-туннелям — тоже, но самое приятное удивление можно испытать от обратных туннелей. Как я уже говорил ранее, ими приходится пользоваться в ситуации, когда имеется машина без SSH-сервера, а вы испытываете необходимость получить к ней доступ в дальнейшем (через несколько минут, часов или дней), но при этом не хотите или не можете воспользоваться VPN. Вам следует соединиться с SSH-сервером с этой машины, а затем установить обратный SSH-туннель, подключившись к этому соединению. Для чего я это применяю? Время от времени — для того, чтобы поработать с удаленным сервером или просто для того, чтобы помочь друзьям и родственникам по VNC через SSH. В последнем случае они запускают Putty с сохраненными настройками сеанса и подключаются к моему SSH-серверу от имени пользователя, не имеющего никаких прав. После создания туннеля я могу зайти по VNC на их машины. И все, им не нужно настраивать файервол или разбираться с LogMeIn или другими подобными сайтами.

Итак, для создания обратного SSH-туннеля необходимо выполнить следущие действия:

Как пользоваться SSH? А также установка и настройка (Linux, Windows, macOS, Android, iOS)

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

Эта статья — своего рода сборник быстрых рецептов, который ты можешь заучить или использовать как шпаргалку. Команды приведены для Linux, но большинство из них будут работать и в любой другой ОС, для которой есть сборка OpenSSH. Удаленный юзер и хост в тексте всегда обозначаются как [email protected], а по отдельности как и . Приятного чтения.

6. Работай с удаленными файлами с помощью локального файлового менеджера

Не всегда удобно работать с большим количеством файлов с помощью консольных команд или mc, запущенного на удаленной машине. Но всегда можно подключить любой каталог удаленной машины как сетевой диск. Для этого достаточно установить sshfs:

Создать каталог для подключения «сетевого диска»:

И подключить его:

Теперь все файлы удаленного каталога /home/user будут видны в каталоге

/remote_files/ и с ними можно работать, как с обычными.

7. Используй tmux

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

Утилита tmux — еще одно детище команды OpenBSD. Она позволяет запустить внутри одной SSH-сессии неограниченное количество консолей, с которыми можно работать одновременно, в том числе сразу с несколькими на одном экране. Но самое главное — tmux поддерживает функцию detach/attach, позволяющую отключиться от текущей сессии tmux, закрыть SSH-соединение, подключиться к машине уже с другого компа и возобновить сессию tmux со всеми открытыми консолями и их содержимым.

Tmux в режиме разделения экрана

Tmux доступна в репозиториях почти всех популярных дистрибутивов. Устанавливать и запускать ее следует на удаленной машине, но перед тем как начать использовать, придется прочитать документацию (или шпаргалку).

Установка SSH в ОС Linux

В 99,99% случаях в Linux уже установлен ssh клиент, с помощью которого можно подключиться к удаленной машине. Но если вы хотите чтобы подключились к компьютеру за которым вы сейчас находитесь или на любой другой, необходимо «скачать ssh сервер».

Сделать это очень просто, все необходимое уже есть в репозиториях (а-ля магазин программ), откройте терминал и введите команду:

То есть, необходима серверная часть, которая делает компьютер доступным в сети по протоколу ssh. Есть клиентская часть, которая уже установлена на ваш компьютер, и с помощью ее, вы подключаетесь к удаленному компьютеру.

Подключение по SSH (с паролем)

Откройте терминал и введите команду для подключения к удаленной машине:

Вначале пишем ssh , потом имя пользователя который есть на удаленной машине, далее знак @ (собачка) и IP адрес . Вот например:

Как правило, ssh подключение происходит к порту 22, если вы его принудительно изменили, то нужно его указать. Для этого в конце пишем -p номер. Вот пример:

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

Далее необходимо написать пароль пользователя. Его необходимо будет указывать каждый раз!

Как создать ключ SSH?

На компьютере за которым вы сейчас находитесь создаем ключ, а после, его необходимо будет скопировать на наш сервер!

Создаем ключ за текущим компьютером:

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

Далее вам предложат создать кодовое слово, также жмем Enter, чтобы пропустить!

Ключ создан, теперь его необходимо добавить на удаленную машину или сервер.

Как добавить SSH-ключ на сервер?

Для этого вводим команду:

Пишем команду ssh-copy-id , далее имя пользователя, который существует на удаленной машине, символ @ (собачка) и IP адрес . Вот например:

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

Теперь у вас есть возможность подключаться к серверу или другой машине без использования ключа, просто введя имя пользователя и пароль!

Перенос ключа

  1. Сохраняем наш Linux сервер в сессиях следующим образом:
    • Указываем ИмяПользователя@IPадрес
    • чуть ниже название подключения


  2. Подключаемся к серверу
  3. Переходим в директорию ./ssh:
  4. Далее с помощью редактора nano откройте документ authorized_keys для редактирования

и добавьте ранее сгенерированный ключ в данный файл и сохраните данные

  • Закройте Putty SSH
  • Откройте Putty, нажмите кнопку «Load»
  • Далее в настройках SSH -> Auth укажите путь до файла ключа.ppk
  • Нажмите Open, после чего запустится сеанс на сервере без использования ключа!

    Локальное перенаправление портов (port forwarding): получаем доступ к удалённым ресурсам на локальной системе

    « Локальное перенаправление портов » позволяет осуществлять доступ к ресурсам, находящимся внутри локальной сети. Предположим, что нужно попасть на офисный сервер БД, сидя дома. В целях безопасности этот сервер настроен так, чтобы принимать подключения только с ПК, находящихся в локальной сети офиса. Но если у вас есть доступ к SSH-серверу , находящемуся в офисе, и этот SSH-сервер разрешает подключения из-за пределов офисной сети, то к нему можно подключиться из дома. Затем осуществить доступ к БД. Проще защитить от атак один SSH-сервер , чем защищать каждый ресурс локальной сети по отдельности.

    Чтобы сделать это, вы устанавливаете SSH-соединение с SSH-сервером и говорите клиенту передать трафик с указанного порта на локальном ПК. Например, с порта 1234 на адрес сервера базы данных и его порт внутри офисной сети. Когда вы пытаетесь получить доступ к БД через порт 1234 на вашем ПК (« localhost ») трафик автоматически « туннелируется » по SSH-соединению и отправляется на сервер БД.

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

    Чтобы использовать локальное перенаправление, подключитесь к SSH-серверу с использованием вспомогательного аргумента -L . Синтаксис для туннелирования трафика будет следующим:

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

    Запустив эту команду, вы попадете на офисный сервер баз данных через порт 8888 на localhost . Если у СУБД есть веб-интерфейс, можно вписать в адресную строку браузера https://localhost:8888 . Если у вас инструмент командной строки, которому необходим сетевой адрес базы данных, то направьте его на localhost:8888 . Весь трафик, отправленный на порт 8888 на ПК, будет перенаправлен на 192.168.1.111:1234 внутри офисной сети:

    При попытке подключиться к БД через 8888 порт на вашем ПК, трафик будет передаваться с помощью SSH-подключения . Когда он достигнет системы, в которой работает SSH , SSH-сервер отправит его на порт 1234 на « localhost », принадлежащий тому же ПК, на котором запущен SSH-сервер . То есть, « localhost » в приведённой выше команде означает « localhost » с перспективы удалённого сервера:

    Например, если нужно настроить SSH-тоннель , как это сделано выше, то введите 8888 в качестве порта-источника и localhost:1234 в качестве целевого адреса. После этого нажмите « Add » и затем « Open », чтобы открыть SSH-подключение . До подключения SSH туннелирования нужно ввести адрес и порт самого SSH-сервера в разделе « Session »:

    Дистанционное перенаправление портов: открываем доступ к локальным ресурсам на удалённой системе

    « Дистанционное перенаправление портов » — ситуация, противоположная локальному перенаправлению, и используется не так часто. Она позволяет открывать доступ к ресурсам на локальном ПК через SSH-сервер . Предположим, что на локальном ПК настроен веб-сервер. Но ваш ПК защищён сетевым экраном, который не пропускает входящий трафик на сервер.

    Если есть доступ к удалённому SSH-серверу , можно подключиться к этому SSH-серверу и использовать дистанционное перенаправление портов. Ваш SSH-клиент укажет серверу перенаправлять трафик с определённого порта – скажем, 1234 – на SSH-сервере на указанный адрес и порт на вашем ПК или внутри локальной сети. Когда кто-то подключается к порту 1234 на SSH-сервере , этот трафик автоматически « туннелируется » по SSH-соединению . Любой, кто подключается к SSH-серверу , сможет получить доступ к серверу, запущенному на вашем ПК. Это достаточно эффективный способ обхода фаерволов.

    Чтобы воспользоваться дистанционным туннелированием IP , используйте ssh-команду с аргументом — R . Синтаксис здесь будет практически таким же, как и в случае с локальным перенаправлением:

    Предположим, что нужно создать серверное приложение, прослушивающее порт 1234 на вашем ПК. Оно доступно через порт 8888 на удалённом SSH-сервере . Адрес SSH-сервера ssh.youroffice.com , а ваше имя пользователя на SSH-сервере bob . Значит, команда будет следующей:

    Затем кто-то может подключиться к SSH-серверу через порт 8888 , и это подключение будет туннелировано на серверное приложение, запущенное на порте 1234 ПК , с которого вы подключались:

    Например, если нужно настроить SSH-тоннель , как это сделано выше, то укажите 8888 в качестве порта-источника и localhost:1234 в качестве целевого адреса. После этого нажмите « Add » и затем « Open », чтобы открыть SSH-подключение . До подключения нужно будет ввести адрес и порт самого SSH-сервера в разделе « Session ».

    После этого пользователи смогут подключаться к порту 8888 на SSH-сервере и их трафик будет передаваться на порт 1234 на вашей локальной системе:

    Нужно включить опцию « GatewayPorts » в sshd_config на удалённом SSH-сервере , если хотите изменить эти настройки.

    Динамическое перенаправление портов: используем SSH-сервер в качестве прокси

    Также существует « динамическое перенаправление портов », которое работает по тому же принципу что прокси или VPN-сервер . SSH-клиент создаёт SOCKS-прокси , который можно настраивать под собственные приложения. Весь трафик, отправляемый через прокси, будет отправляться через SSH-сервер . Принцип здесь схож с локальным перенаправлением – берётся локальный трафик, отправленный на определённый порт на вашем ПК, и перенаправляется через SSH-соединение на удалённый адрес.

    Предположим, что вы используете общедоступную Wi-Fi сеть. Но хочется делать это безопасно. Если у вас есть доступ к SSH-серверу из дома, то можно подключиться к нему и использовать динамическое перенаправление. SSH-клиент создаст SOCKS-прокси на вашем ПК. Весь трафик, отправленный на этот прокси, будет отправляться через подключение к SSH-серверу . Никто из тех, кто использует общедоступную Wi-Fi сеть, не сможет отслеживать ваши перемещения в сети или закрывать доступ к сайтам. С перспективы сайтов, которые посещаете, будет казаться, что вы заходите на них с домашнего ПК.

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

    Например, если медиа-сервер находится по адресу 192.168.1.123 в вашей домашней сети, то можно добавить адрес 192.168.1.123 в любое приложение при помощи SOCKS-прокси и получить доступ к медиа-серверу, как будто вы находитесь внутри домашней сети.

    Чтобы воспользоваться динамическим перенаправлением, запустите ssh-команду с аргументом — D :

    Предположим, что у вас есть доступ к SSH-серверу по адресу ssh.yourhome.com , а ваш логин на SSH-сервере – bob . Нужно использовать динамическое перенаправление для того, чтобы открыть SOCKS-прокси по порту 8888 на текущем ПК. Тогда команда для SSH туннелирования будет выглядеть следующим образом:

    После этого можно настроить браузер или другое приложение на использование локального IP-адреса (127.0.0.1) и порта 8888 . Весь трафик этого приложения будет перенаправляться через туннель:

    Например, если вам нужно настроить SOCKS-прокси на порт 8888 , то введите 8888 в качестве порта-источника. После этого нажмите « Add » и затем « Open », чтобы открыть SSH-подключение .

    После этого можно настроить приложение на подключение через SOCKS-прокси на вашем локальном ПК ( то есть, по IP-адресу 127.0.0.1 , который ведёт на ваш локальный ПК ) и указать корректный порт для работы:

    Туннель будет оставаться активным и открытым до тех пор, пока открыта сессия SSH-соединения . Когда вы завершите SSH-сессию и отключаетесь от сервера, туннель тоже закроется. Чтобы снова открыть туннель, переподключитесь при помощи соответствующей команды или нужной функции в PuTTY .

    Данная публикация представляет собой перевод статьи « How to Use SSH Tunneling to Access Restricted Servers and Browse Securely » , подготовленной дружной командой проекта Интернет-технологии.ру

    Что такое SSH? Краткое описание

    Протокол Secure Shell (SSH) был разработан для максимальной защиты сетевых взаимодействий с удаленными узлами сети. Этот протокол шифрует сетевой трафик при помощи улучшенных возможностей аутентификации, а также функций, направленной на защиту других незащищенных протоколов – таких как защищенное копирование (Secure Copy, SCP), защищенный протокол передачи файлов (Secure File Transfer Protocol, SFTP), перенаправление X-сеансов и перенаправление портов. Поддерживается несколько типов шифрования (начиная от 512-битного и заканчивая 32768-битным) с использованием различных криптографических алгоритмов – Blowfish, Triple DES, CAST-128, Advanced Encryption Scheme (AES) и ARCFOUR. Чем выше разрядность шифрования, тем больший объем трафика генерируется в сети. Из рисунка 1 видно, как любой пользователь сети может с легкостью просмотреть трафик telnet-подключения с помощью анализатора сетевых пакетов (например, Wireshark).

    Часто используемые сокращения
    • API: Application programming interface – интерфейс прикладного программирования
    • FTP: File Transfer Protocol – протокол передачи файлов
    • IETF: Internet Engineering Task Force – инженерная группа по развитию Интернета
    • POSIX: Portable Operating System Interface for UNIX – интерфейс переносимой операционной системы для UNIX
    • RFC: Request for Comments – документ RFC , запрос на комментарий
    • VPN: Virtual private network – виртуальная частная сеть

    Если вы используете незащищенный «открытый» протокол (например, telnet), то любой пользователь сети может подсмотреть ваши пароли и другую секретную информацию. На рисунке 1 изображена схема подключения пользователя fsmythe к удаленному узлу с использованием telnet. Пользователь вводит свое имя fsmythe и пароль [email protected]$20!0, которые может видеть любой пользователь, находящийся в той же сети, что и наш ничего не подозревающий пользователь telnet.

    Рисунок 2. Подключения с использованием протокола SSH зашифрованы

    На рисунке 2 изображена типовая схема SSH-подключения, и мы видим, что никакой пользователь сети не может просматривать зашифрованный трафик. Пакеты SSH (как правило, это Open Source-пакет OpenSSH) по умолчанию установлены во всех распространенных дистрибутивах Linux® и UNIX®, поэтому вам вряд ли придется загружать и компилировать их из исходного кода. Если вы не работаете в Linux или UNIX, то существует множество поддерживаемых бесплатных SSH-инструментов, например, WinSCP, Putty, FileZilla, TTSSH и Cygwin (программное обеспечение POSIX, устанавливаемое в операционной системе Windows®). Эти инструменты работают под управлением операционной системы Windows и имеют интерфейс командной оболочки UNIX или Linux.

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

    Архитектура SSH

    В документах IETF RFC 4251-4256 дается следующее определение SSH: «Протокол SSH используется для организации безопасного входа в удаленную систему и организации иных безопасных служб через сети, не обеспечивающие безопасности». Протокол включает три основных компонента (рисунок 3):

    • Протокол транспортного уровня: обеспечивает аутентификацию серверов, конфиденциальность и целостность. Этот протокол может также обеспечивать сжатие информации и работает в основном с использованием соединений TCP/IP, но может быть реализован и на базе иных потоков данных с гарантированной доставкой.
    • Протокол аутентификации пользователей: используется на серверах для проверки подлинности клиентов и работает на основе протокола транспортного уровня.
    • Протокол соединений: обеспечивает мультиплексирование шифрованного туннеля в несколько логических каналов и работает поверх протокола аутентификации пользователей.
    Рисунок 3. Логические уровни протокола SSH

    Транспортный уровень отвечает за обмен ключами и аутентификацию серверов. На этом уровне обеспечивается поддержка шифрования, проверки целостности и сжатия данных (при необходимости), после чего на верхний уровень передается API-интерфейс для отправки и получения нешифрованных текстовых пакетов. Уровень аутентификации пользователей обеспечивает проверку подлинности клиентов при помощи различных методов. Наиболее распространенные методы аутентификации включают в себя использование паролей и открытых ключей, ввод данных с клавиатуры, интерфейс GSSAPI, технологию SecureID, а также различные подключаемые модули аутентификации (PAM).

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

    Эта открытая архитектура обладает большой гибкостью. Транспортный уровень совместим с протоколом Transport Layer Security (TLS), и вы можете реализовывать собственные методы проверки подлинности, расширяя уровень аутентификации пользователей. Уровень соединений позволяет объединять в одном SSH-подключении несколько сеансов (рисунок 4).

    Примеры типового использования SSH в операционных системах UNIX и Linux

    Как правило, SSH используется для того, чтобы пользователи могли подключаться к удаленным компьютерам и выполнять на них различные команды. Однако SSH также поддерживает туннелирование и X11-соединения и даже позволяет передавать файлы с помощью SFTP и SCP. SSH можно использовать во множестве приложений для различных платформ, включая Linux, UNIX, Windows и Apple® OS X (для запуска некоторых приложений могут потребоваться дополнительные возможности, доступные либо совместимые только с определенными SSH-клиентами или SSH-серверами).

    Рассмотрим несколько общих примеров синтаксиса SSH:

    • Доступ к командной оболочке удаленного компьютера (вместо использования незащищенных протоколов telnet и rlogin):
    • Выполнение отдельной команды на удаленном компьютере (вместо использования rsh)
    • Копирование файлов с локального сервера на удаленный компьютер посредством команды SCP :
    • Защищенная передача файлов посредством SFTP (вместо использования FTP):
    • Эффективные и безопасные процедуры резервного копирования, синхронизации и зеркалирования файлов на локальный или удаленный компьютер при помощи rsync:
    • Перенаправление или туннелирование порта (не путайте с VPN):
    • Перенаправление X-сеансов с удаленного компьютера (может осуществляться через несколько промежуточных узлов):
    • Конфигурация с перенаправлением X11, используемая совместно с клиентом X Windows, в котором настроено SSH-туннелирование X11. Это позволяет использовать графическую подсистему UNIX или Linux через защищенное SSH-соединение на локальном компьютере с Windows, подключенном через SSH к удаленному узлу Linux или UNIX:
    • Безопасное монтирование директории удаленного сервера в качестве файловой системы локального компьютера с помощью sshfs :
    • Автоматизированное наблюдение и управление удаленными серверами при помощи различных средств:

    Полезные советы по настройке и использованию SSH

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

    • Запретите удаленные подключения пользователям с привилегиями root:
    • Создавайте пары ключей (открытый/закрытый) с использованием стойких идентификационных фраз и защищайте закрытый ключ паролем (никогда не генерируйте пары ключей или идентификационные фразы без использования паролей):
    • Настраивайте обработчики TCP (TCP wrappers) таким образом, чтобы разрешать подключаться только определенным удаленным компьютерам, а всем остальным – запрещать:
    • Отключайте функциональность SSH-сервера на рабочих станциях и ноутбуках – для этого отключите службу SSH, а затем удалите пакет SSH-сервера:
    • Управляйте разрешениями на SSH-подключение с помощью учетных записей:
    • Используйте только протокол SSH версии 2:
    • Закрывайте неактивные подключения, указав время простоя:
    • Запрещайте аутентификацию на основе хоста:
    • Отключайте пользовательские файлы .rhosts:
    • Настраивайте брандмауэр таким образом, чтобы разрешать входящие SSH-подключения только из доверенных сетей:
    • Явно указывайте сетевые интерфейсы, которые должны принимать входящие SSH-подключения:
    • Настраивайте политики пользователей на использование стойких паролей, обеспечивающих защиту от атак с помощью полного перебора, социальной инженерии и подбора по словарям:
    • Ограничивайте доступ SFTP-пользователей их домашними директориями с помощью параметра Chroot SSHD :
    • Запрещайте использование пустых паролей:
    • Ограничивайте количество входящих соединений на порт 2022 в определенный интервал времени:
    • Настраивайте iptables таким образом, чтобы в течение 30 секунд разрешать не более трех попыток подключения к порту 2022:
    • Используйте анализатор log-файлов (например, logcheck , loggrep , splunk или logwatch ) для более тщательного анализа и создания отчетов. Настройте также само SSH-приложение на более подробное журналирование событий:
    • Устанавливайте наиболее подробный уровень журналирования SSH:
    • Всегда обновляйте пакеты SSH и необходимые библиотеки до последних версий:
    • Скрывайте версию OpenSSH в исходном коде, после чего компилируйте приложение заново. После этого вносите следующие изменения:
    • Удаляйте исполняемые файлы rlogin и rsh из системы и замещайте их symlink -ссылками на SSH:

    SSH поддерживает множество разнообразных методов и способов аутентификации, которые можно включать и отключать. Этим можно управлять в конфигурационном файле /etc/ssh/sshd_config, указывая ключевое слово, относящееся к тому или иному методу аутентификации, с последующим указанием параметра yes или no . В следующем примере показаны наиболее распространенные параметры:

    Ключевые слова AllowedAuthentications и RequiredAuthentications в файле sshd_config определяют, какие конфигурации и методы аутентификации используются только с протоколом SSH версии 2. Синтаксис, разрешающий аутентификацию с помощью паролей и открытых ключей, выглядит следующим образом:

    Открытые и закрытые ключи SSH

    Вспомогательными инструментами проверки подлинности SSH являются средства управления ключами и связанные с ними агенты. Если настроена аутентификация с использованием открытого ключа, то ваш ключ подтверждает вашу подлинность удаленному узлу SSH. Подлинность на основе SSH определяется на основе двух компонентов: открытого и закрытого ключей. Закрытый ключ SSH подтверждает подлинность пользователя при исходящем SSH-подключении и должен храниться в секрете. Когда пользователь инициирует SSH- или SCP-подключение к удаленному компьютеру или серверу, он является SSH-клиентом. При помощи математических алгоритмов ваш закрытый ключ становится вашей персональной электронной картой доступа, а открытый ключ – замком, к которому подходит ваша электронная карта. Ваш закрытый ключ говорит: «Это действительно я, Фред Смит», открытый ключ отвечает: «Да, вы действительно Фред Смит, ваша личность установлена, пожалуйста, входите».

    Открытый ключ определяет, кому разрешено открывать замок и получать право на вход. Открытые ключи не нужно держать в секрете, поскольку их невозможно использовать для компрометации системы или для несанкционированного доступа. В операционных системах Linux и UNIX открытые и закрытые ключи хранятся в виде текстовых ASCII-файлов, в системах под управлением Windows пары ключей могут храниться как в текстовых файлах, так и в реестре Windows.

    Протокол SSH версии 2 позволяет выполнять множественную идентификацию с использованием нескольких закрытых ключей. Давайте посмотрим, как создать и настроить пару из открытого и закрытого SSH-ключей на обычных компьютерах с Linux (рисунок 5).

    Листинг 2. Копирование открытого ключа с компьютера-источника в файл authorized_keys на целевом компьютере

    В листинге 3 выполняется первое удаленное SSH-обращение (запуск команды ls -d /tmp ) к серверу, вследствие чего ключ кэшируется на сервере в файле .ssh/known_hosts. Пользователь вводит парольную фразу, заданную на этапе генерации SSH-ключей, а вывод команды, запущенной на удаленном сервере, передается на экран локального компьютера.

    Листинг 3. Проверка SSH-доступа посредством запуска команды на удаленном компьютере

    Примечание. Во всех вышеприведенных примерах не требовалось вводить пароль пользователя fsmythe. Вместо этого требовалось вводить парольную фразу, заданную на шаге 1. Если вы не хотите вводить парольную фразу при подключении к удаленному компьютеру, то создайте пустую фразу, нажав клавишу enter в момент появления соответствующего запроса. После этого при подключении к удаленному компьютеру thor01.com от имени пользователя fsmythe вам не придется ничего вводить.

    Конфигурирование и использование утилиты ssh-agent

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

    Далее с помощью ssh-agent сгенерируйте на устройство stdout команды интерпретатора bash:

    На третьем шаге задайте значения вышеупомянутых переменных среды для текущего сеанса командной оболочки:


    Убедитесь, что утилита ssh-agent запущена:

    Получите список текущих элементов, загруженных внутри ssh-agent :

    На следующем шаге добавьте требуемые SSH-элементы (выполнив их предварительную аутентификацию с использованием парольной фразы SSH-ключей):

    Убедитесь, что указанные элементы были загружены в запущенную оболочку ssh-agent :

    Наконец, можно проверить работу ssh-agent с использованием синтаксиса SSH. Обратите внимание на отсутствие запроса на ввод парольной фразы:

    Когда вы вводите парольную фразу с помощью команды ssh-add , вы в действительности вы дешифруете закрытый ключ и помещаете его через агента в память, после чего он может использоваться в последующих SSH-подключениях, использующих данную парольную фразу. Обратите внимание на то, что при помощи ssh-add можно выполнять предварительную аутентификацию нескольких закрытых ключей.

    Другой инструмент, SSH-утилита ssh-keyscan из листинга 4, позволяет собирать открытые SSH-ключи хостов с удаленных компьютеров. Эта чрезвычайно быстрая и эффективная утилита полезна при наполнении файлов /etc/ssh_known_hosts. В первую очередь она предназначена для использования в командных сценариях, помогающих автоматизировать процессы.

    Использование SSH в приложениях и сценариях UNIX

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

    не могут обрабатывать вводимые пользователями парольные фразы SSH и прекращают работу, если заранее не была настроена беспарольная конфигурация SSH-ключей, конфигурация с использованием ssh-agent или механизм доверенной сети – т. е. один из методов, не требующий ввода SSH-паролей. Это происходит потому, что SSH ожидает ввода парольной фразы с терминала, связанного с текущим сеансом командной оболочки. Эту проблему можно обойти, используя сценарии, написанных при помощи expect, либо при помощи Perl-сценариев (рассмотрите возможности CPAN-модуля Net::SSH::Perl ), к ним можно также обращаться из вашего собственного сценария:

    Некоторые системные администраторы считают предоставление обычным пользователям беспарольного SSH-доступа к удаленным хостам достаточной причиной для линчевания. Однако существуют альтернативные меры безопасности, оправдывающие беспарольные механизмы SSH-доступа к удаленным хостам, например, когда пользователь использует на удаленном компьютере ограниченную командную оболочку korn (rksh – restricted korn shell) или shell (rssh – restricted shell) вместо полнофункциональной Bash. Также с помощью авторизованных ключей можно ограничить список команд, которые разрешено запускать пользователям на удаленном компьютере, в результате чего пользователи не смогут случайно запустить команду, способную нанести вред системе. Пример такого ограничения представлен в листинге 5.

    Создание среды доверенных узлов с помощью SSH

    Наконец, следует упомянуть о среде доверенных узлов, являющейся заменой использованию открытых и закрытых ключей SSH. В средах с использованием командных сценариев (или если стоит задача автоматизировать определенные процедуры), в которых необходимо использовать эти типы обращений, среда доверенных узлов имеет определенные преимущества по сравнению с использованием SSH-ключей (хотя при этом остаются риски, связанные с нарушением безопасности). Среда доверенных узлов (или аутентификация на основе доверенных узлов) по большей части реализуется с помощью заранее сконфигурированных файлов, содержащих списки пользователей и хостов, которым разрешен доступ. Существует два типа аутентификации на основе доверенных узлов. В первом, более старом и менее защищенном методе (например, OpenSSH и SSH1) используются команды открытого протокола ( rsh , rcp и rlogin ), проверяется два файла и устанавливается одно ключевое слово в файле sshd_config:

    Протокол SSH версии 2 не поддерживает этот метод. Вместо этого для лучшей защиты сети измените файл /etc/ssh/sshd_config (можно указывать как имена хостов, так и IP-адреса), а также сконфигурируйте файлы shosts.equiv и/или .shosts следующим образом:

    Чтобы разрешить использование среды доверенных узлов, задайте в файле the /etc/ssh/sshd_config следующие параметры для протокола SSH версии 2:

    Например, если файл /etc/shosts.equiv настроен на сервере example.com следующим образом:

    то пользователю fsmythe разрешено выполнять аутентификацию на основе доверенных узлов, если он работает за удаленными компьютерами remoteclient.com, 192.168.100.12 и secureserver.net, пользователю sallyh разрешен доступ с компьютера secureserver.net, а пользователю james запрещен доступ с удаленного компьютера hackers.org.

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

    Таблица 1. Сравнение возможностей аутентификации на основе SSH-ключей и на основе доверенных узлов
    Возможности SSH Доверенные узлы Публичный и открытый ключи
    Аутентификация по IP-адресу Да Да
    Аутентификация по имени хоста Да Да
    Использование других возможностей открытого ключа Нет Да
    Аутентификация по имени удаленного пользователя Да Нет
    Использование групповых символов в именах хостов и IP-адресах Нет Да
    Необходимость использования парольной фразы для получения доступа Нет Нет
    Сбои в случае изменения IP-адреса или имени хоста В некоторых случаях Да
    Необходимость выполнения настроек как на сервере, так и на клиенте Нет Да
    Возможность использования для автоматизации задач, а также в командных сценариях Да Да

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

    • При изменении имени или IP-адреса хоста пара SSH-ключей перестанет работать, поскольку информация об известных хостах находится в кэше. В этом случае необходимо удалить из файла .ssh/known_hosts старую запись о хосте и заново поместить обновленную информацию в кэш. При возникновении такой ситуации все сценарии, использующие SSH-ключи, перестанут работать.
    • Аутентификация с использованием SSH-ключей требует настройки как на стороне клиента, так и на стороне сервера. Каждый раз при изменении открытого ключа или генерации новой пары ключей необходимо передавать новый открытый ключ на все удаленные компьютеры и обновлять файл authorized_keys.
    • При изменении прав доступа к папке .ssh/ (а также к файлам открытого или закрытого ключа) беспарольный SSH-доступ может перестать работать. Для отключения строгой проверки прав доступа к файлам и директориям отредактируйте файл /etc/ssh/sshd_config, задав для параметра StrictModes значение no .
    • Не существует централизованного способа отозвать ключ после того, как пара ключей была сгенерирована, также невозможно точно узнать, кому был передан ключ.

    Заключение

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

    ТОП-20 трюков и советов для работы с SSH-туннелями

    Вас приветствует сервис 24/7 по работе с туннелями — ssh4work.ru !

    Пожалуй, стоит начать с вводной части, что предлагает наш сервис 24/7:

    1. Для чего нужен SSH-туннель?
    SSH скрывает ваш IP и шифрует ваш трафик.

    2. Преимущества SSH перед socks5!
    — Высокая скорость работы!
    — Долгое время жизни(от недели до года и более!), если вам нужен постоянный сокс для серфинга, рассылки, работы с зарубежными сервисами и т.д., то SSH — идеальный вариант.
    — Шифрование.

    Только у нас самые надежные и скоростные туннели!

    Мы работаем под заказ!
    Список стран постоянно пополняется, изучается спрос на экзотические страны.
    В планах заниматься туннелями в каждой стране, кроме России.

    Ищем партнеров и оптовиков, для которых уже готовы скидки.
    Опт от 10 шт.
    Мы всегда открыты к вашим предложениям!

    Наши контактные данные:
    ICQ: 76510000
    E-Mail: mail@ssh4work.ru

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

    Прогон по твиттеру, постинг в 1500 аккунтов
    Постинг в твиттер аккаунты, для ускорения индексации ваших сайтов, сателлитов, дорвеев.

    [Перевод] Практические советы, примеры и туннели SSH 09.01.2020 17:17

    Практические примеры SSH, которые выведут на новый уровень ваши навыки удалённого системного администратора. Команды и советы помогут не только использовать SSH , но и более грамотно перемещаться по сети.

    Знание нескольких трюков ssh полезно любому системному администратору, сетевому инженеру или специалисту по безопасности.

    Практические примеры SSH

    1. SSH socks-прокси
    2. Туннель SSH (переадресация портов)
    3. SSH-туннель на третий хост
    4. Обратный SSH-туннель
    5. Обратный прокси SSH
    6. Установка VPN по SSH
    7. Копирование ключа SSH (ssh-copy-id)
    8. Удалённое выполнение команд (неинтерактивно)
    9. Удалённый перехват пакетов и просмотр в Wireshark
    10. Копирование локальной папки на удалённый сервер по SSH
    11. Удалённые приложения GUI с переадресацией SSH X11
    12. Удалённое копирование файлов с помощью rsync и SSH
    13. SSH через сеть Tor
    14. SSH к инстансу EC2
    15. Редактирование текстовых файлов с помощью VIM через ssh/scp
    16. Монтирование удалённого SSH как локальной папки с SSHFS
    17. Мультиплексирование SSH с помощью ControlPath
    18. Потоковое видео по SSH с помощью VLC и SFTP
    19. Двухфакторная аутентификация
    20. Прыжки по хостам с SSH и -J
    21. Блокировка попыток брутфорса SSH с помощью iptables
    22. SSH Escape для изменения переадресации портов

    Разбор командной строки SSH

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

    • -v : вывод отладочной информации особенно полезен при анализе проблем аутентификации. Можно использовать несколько раз для вывода дополнительной информации.
    • — p 22 : порт для подключения к удалённому серверу SSH. 22 не обязательно указывать, потому что это значение по умолчанию, но если протокол на каком-то другом порту, то указываем его с помощью параметра -p . Порт прослушивания указывается в файле sshd_config в формате Port 2222 .
    • -C : сжатие для соединения. Если у вас медленный канал или вы просматриваете много текста, это может ускорить связь.
    • neo@ : строка перед символом @ обозначает имя пользователя для аутентификации на удалённом сервере. Если не указать его, то по умолчанию будет использоваться имя пользователя учётной записи, в которую вы вошли в данный момент (

    $ whoami). Пользователя также можно указать параметром -l .

  • remoteserver : имя хоста, к которому подключается ssh , это может быть полное доменное имя, IP-адрес или любой хост в локальном файле hosts. Для подключения к хосту, который поддерживает и IPv4, и IPv6, можно добавить в командную строку параметр -4 или -6 для правильного резолвинга.
  • Все вышеперечисленные параметры являются необязательными, кроме remoteserver .

    Использование файла конфигурации

    Хотя многие знакомы с файлом sshd_config , есть ещё файл конфигурации клиента для команды ssh . Значение по умолчанию

    /.ssh/config , но его можно определить как параметр для опции -F .

    В приведённом выше примерном файле конфигурации ssh две записи хоста. Первая обозначает все хосты, для всех применяется параметр конфигурации Port 2222. Вторая говорит, что для хоста remoteserver следует использовать другое имя пользователя, порт, FQDN и IdentityFile.

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

    Копирование файлов по SSH с помощью SCP

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

    В этом примере файл mypic.png скопирован на remoteserver в папку /media/data и переименован в mypic_2.png.

    Не забывайте о разнице в параметре порта. На этом попадаются многие, кто запускает scp из командной строки. Здесь параметр порта -P , а не -p , как в ssh-клиенте! Вы забудете, но не волнуйтесь, все забывают.

    Для тех, кто знаком с консольным ftp , многие из команд похожи в sftp . Вы можете сделать push, put и ls, как сердце пожелает.

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

    1. SSH socks-прокси

    Функция SSH Proxy под номером 1 по уважительной причине. Она более мощная, чем многие предполагают, и даёт вам доступ к любой системе, к которой имеет доступ удалённый сервер, используя практически любое приложение. Клиент ssh может туннелировать трафик через прокси-сервер SOCKS одной простой командой. Важно понимать, что трафик к удалённым системам будет исходить от удалённого сервера, так будет указано в логах веб-сервера.

    Здесь мы запускаем socks-прокси на TCP-порту 8888, вторая команда проверяет, что порт активен в режиме прослушивания. 127.0.0.1 указывает, что служба работает только на localhost. Мы можем применить немного другую команду для прослушивания всех интерфейсов, включая ethernet или wifi, это позволит другим приложениям (браузерам и т д.) в нашей сети подключаться к прокси-сервису через ssh socks-прокси.

    Теперь можем настроить браузер для подключения к socks-прокси. В Firefox выберите Настройки | Основные | Параметры сети. Укажите IP-адрес и порт для подключения.

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

    Активация socks-прокси в Chrome

    Запуск Chrome с определёнными параметрами командной строки активирует socks-прокси, а также туннелирование DNS-запросов из браузера. Доверяй, но проверяй. Используйте tcpdump для проверки, что DNS-запросы больше не видны.

    Использование других приложений с прокси

    Имейте в виду, что многие другие приложения тоже могут использовать socks-прокси. Веб-браузер просто самое популярное из них. У некоторых приложений есть параметры конфигурации для активации прокси-сервера. Другим нужно немного помочь вспомогательной программой. Например, proxychains позволяет запустить через socks-прокси Microsoft RDP и др.

    Параметры конфигурации socks-прокси задаются в файле конфигурации proxychains.

    Подсказка: если используете удалённый рабочий стол из Linux на Windows? Попробуйте клиент FreeRDP. Это более современная реализация, чем rdesktop , с гораздо более плавным взаимодействием.

    Вариант использования SSH через socks-прокси

    Вы сидите в кафе или гостинице — и вынуждены использовать довольно ненадёжный WiFi. С ноутбука локально запускаем ssh-прокси и устанавливаем ssh-туннель в домашнюю сеть на локальный Rasberry Pi. Используя браузер или другие приложения, настроенные для socks-прокси, мы можем получить доступ к любым сетевым службам в нашей домашней сети или выйти в интернет через домашнее подключение. Всё между вашим ноутбуком и домашним сервером (через Wi-Fi и интернет до дома) зашифровано в туннеле SSH.

    2. Туннель SSH (переадресация портов)

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

    Разберём параметр -L . Его можно представить как локальную сторону прослушивания. Таким образом, в примере выше порт 9999 прослушивается на стороне localhost и переадресуется через порт 80 на remoteserver. Обратите внимание, что 127.0.0.1 относится к localhost на удалённом сервере!

    Поднимемся на ступеньку. В следующем примере порты прослушивания связываются с другими узлами локальной сети.

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

    3. SSH-туннель на сторонний хост

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

    В данном примере мы перенаправляем туннель от remoteserver к веб-серверу, работающему на 10.10.10.10 . Трафик с remoteserver к 10.10.10.10 уже не в SSH-туннеле. Веб-сервер на 10.10.10.10 будет считать remoteserver источником веб-запросов.

    4. Обратный SSH-туннель

    Здесь настроим прослушивающий порт на удалённом сервере, который будет подключаться обратно к локальному порту на нашем localhost (или другой системе).

    В этой SSH-сессии устанавливается соединение с порта 1999 на remoteserver к порту 902 на нашем локальном клиенте.


    5. Обратный прокси SSH

    В этом случае мы устанавливаем socks-прокси на нашем ssh-соединении, однако прокси слушает на удалённом конце сервера. Подключения к этому удалённому прокси теперь появляются из туннеля как трафик с нашего localhost.

    Устранение проблем с удалёнными SSH-туннелями

    Если у вас возникли проблемы с работой удалённых опций SSH, проверьте с помощью netstat , к каким ещё интерфейсам подключён порт прослушивания. Хотя мы в примерах указали 0.0.0.0, но если значение GatewayPorts в sshd_config установлено в значение no, то листенер будет привязан только к localhost ( 127.0.0.1 ).

    Предупреждение безопасности

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

    6. Установка VPN по SSH

    Общий термин среди спецов по методам атаки (пентестеры и проч.) — это «точка опоры в сети». После установления соединения в одной системе эта система становится шлюзом для дальнейшего доступа к сети. Точка опоры, которая позволяет двигаться вширь.

    Для такой точки опоры мы можем использовать SSH-прокси и proxychains, однако есть некоторые ограничения. Например, не получится работать напрямую с сокетами, поэтому мы не сможем сканировать порты внутри сети через Nmap SYN .

    Используя этот более продвинутый вариант VPN, подключение снижается до уровня 3. Затем мы можем просто направить трафик через туннель, используя стандартную сетевую маршрутизацию.

    Метод использует ssh , iptables , tun interfaces и маршрутизацию.

    Сначала нужно задать эти параметры в sshd_config . Поскольку мы вносим изменения в интерфейсы и удалённой, и клиентской системы, нам нужны права root с обеих сторон.

    Затем установим ssh-соединение, используя параметр, который запрашивает инициализацию tun-устройств.

    Теперь у нас должно быть устройство tun при показе интерфейсов ( # ip a ). Следующий шаг добавит IP-адреса к туннельным интерфейсам.

    Сторона клиента SSH:

    Сторона сервера SSH:

    Теперь у нас прямой маршрут к другому хосту ( route -n и ping 10.10.10.10 ).

    Можно маршрутизировать любую подсеть через хост на другой стороне.

    На удалённой стороне необходимо включить ip_forward и iptables .

    Бум! VPN через туннель SSH на сетевом уровне 3. Вот это уже победа.

    Если возникают какие-то проблемы, используйте tcpdump и ping , чтобы установить причину. Поскольку мы играем на уровне 3, то наши пакеты icmp пойдут через этот туннель.

    7. Копирование ключа SSH (ssh-copy-id)

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

    /.ssh/id_rsa.pub (или ключ по умолчанию) с вашей системы в

    /.ssh/authorized_keys на удалённом сервере.

    8. Удалённое выполнение команд (неинтерактивно)

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

    В данном примере grep выполняется на локальной системе после того, как лог скачался по ssh-каналу. Если файл большой, удобнее запустить grep на удалённой стороне, просто заключив обе команды в двойные кавычки.

    Другой пример выполняет ту же самую функцию, что и ssh-copy-id из примера 7.

    9. Удалённый перехват пакетов и просмотр в Wireshark

    Я взял один из наших примеров по tcpdump. Используйте его для удалённого перехвата пакетов с выдачей результата непосредственно в GUI локального Wireshark.

    10. Копирование локальной папки на удалённый сервер по SSH

    Красивый трюк, который сжимает папку с помощью bzip2 (это параметр -j в команде tar ), а затем извлекает поток bzip2 на другой стороне, создавая на удалённом сервере дубликат папки.

    11. Удалённые приложения GUI с переадресацией SSH X11

    Если на клиенте и удалённом сервере установлены «иксы», то можно удалённо выполнить команду GUI, с окном на вашем локальном рабочем столе. Эта функция существует давным давно, но по-прежнему очень полезна. Запустите удалённый веб-браузер или даже консоль VMWawre Workstation, как я делаю в этом примере.

    Требуется строка X11Forwarding yes в файле sshd_config .

    12. Удалённое копирование файлов с помощью rsync и SSH

    rsync во многом удобнее scp , если требуется периодическое резервное копирование каталога, большого количества файлов или очень больших файлов. Здесь есть функция восстановления после сбоя передачи и копирования только изменённых файлов, что сохраняет трафик и время.

    В этом примере используется сжатие gzip (-z) и режим архивирования (-a), который включает рекурсивное копирование.

    13. SSH через сеть Tor

    Анонимная сеть Tor может туннелировать SSH-трафик с помощью команды torsocks . Следующая команда прокинет ssh-прокси через Tor.

    Torsocks будет использовать для прокси порт 9050 на localhost. Как всегда при использовании Tor необходимо серьёзно проверять, какой трафик туннелируется и другие проблемы операционной безопасности (opsec). Куда идут ваши DNS-запросы?

    14. SSH к инстансу EC2

    Для подключения к инстансу EC2 необходим закрытый ключ. Скачайте его (расширение .pem) из панели управления Amazon EC2 и измените разрешения ( chmod 400 my-ec2-ssh-key.pem ). Храните ключ в надёжном месте или поместите его в свою папку

    Параметр -i просто указывает ssh-клиенту использовать этот ключ. Файл

    /.ssh/config идеально подходит для автоматической настройки использования ключа при подключении к хосту ec2.

    15. Редактирование текстовых файлов с помощью VIM через ssh/scp

    Для всех любителей vim этот совет сэкономит немного времени. С помощью vim файлы редактируются по scp одной командой. Этот метод просто создаёт файл локально в /tmp , а затем копирует его обратно, как только мы его сохранили из vim .

    Примечание: формат немного отличается от обычного scp . После хоста у нас двойной // . Это ссылка на абсолютный путь. Один слэш будет означать путь относительно домашней папки users .

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

    16. Монтирование удалённого SSH как локальной папки с SSHFS

    При помощи sshfs — клиента файловой системы ssh — мы можем подключить локальный каталог к удалённому местоположению со всеми взаимодействиями файлов в зашифрованном сеансе ssh .

    На Ubuntu и Debian установим пакет sshfs , а затем просто приимонтируем удалённое расположение к нашей системе.

    17. Мультиплексирование SSH с помощью ControlPath

    По умолчанию при наличии существующего подключения к удалённому серверу с помощью ssh второе подключение с помощью ssh или scp устанавливает новый сеанс с дополнительной аутентификацией. Опция ControlPath позволяет использовать существующий сеанс для всех последующих соединений. Это значительно ускорит процесс: эффект заметен даже в локальной сети, а тем более при подключении к удалённым ресурсам.

    ControlPath указывает сокет для проверки новыми соединениями на предмет наличия активной сессии ssh . Последняя опция означает, что даже после выхода из консоли существующий сеанс останется открытым 10 минут, так что в течение этого времени вы сможете повторно подключиться по существующему сокету. Для дополнительной информации смотрите справку ssh_config man .

    18. Потоковое видео по SSH с помощью VLC и SFTP

    Даже давние пользователи ssh и vlc (Video Lan Client) не всегда знают об этой удобной опции, когда очень нужно посмотреть видео по сети. В настройках File | Open Network Stream программы vlc можно ввести местоположение как sftp:// . Если требуется пароль, появится запрос.

    19. Двухфакторная аутентификация

    Такая же двухфакторная аутентификация, как у вашего банковского счёта или учётной записи Google, применима к сервису SSH.

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

    См. наше 8-минутное руководство по использованию Google Authenticator и SSH.

    20. Прыжки по хостам с ssh и -J

    Если из-за сегментации сети приходится переходить через несколько хостов ssh, чтобы добраться до конечной сети назначения, вам сэкономит время ярлык -J.

    Здесь главное понимать, что это не аналогично команде ssh host1 , затем user@host1:

    $ ssh host2 и т. д. Параметр -J хитро использует переадресацию, чтобы localhost устанавливал сеанс со следующим хостом в цепочке. Таким образом, в приведённом выше примере наш localhost аутентифицируется на host4. То есть используются наши ключи localhost, а сеанс от localhost до host4 полностью зашифрован.

    Для такой возможности в ssh_config укажите опцию конфигурации ProxyJump. Если регулярно приходится переходить через несколько хостов, то автоматизация через конфиг сэкономит массу времени.

    21. Блокировка попыток брутфорса SSH с помощью iptables

    Любой, кто управлял сервисом SSH и просматривал логи, знает о количестве попыток брутфорса, которые происходят каждый час каждый день. Быстрый способ уменьшить шум в логах — перенести SSH на нестандартный порт. Внесите изменения в файл sshd_config с помощью параметра конфигурации Port##.

    С помощью iptables тоже можно легко блокировать попытки подключения к порту по достижении определённого порога. Простой способ сделать это — использовать OSSEC, поскольку он не только блокирует SSH, но выполняет кучу других мер по обнаружению вторжений на базе имени хоста (HIDS).

    22. SSH Escape для изменения переадресации портов

    И наш последний пример ssh предназначен для изменения переадресации портов на лету в рамках существующего сеанса ssh . Представьте такой сценарий. Вы глубоко в сети; возможно, прыгнули через полдюжины хостов и вам нужен локальный порт на рабочей станции, который перенаправлен на Microsoft SMB старой системы Windows 2003 (кто-нибудь помнит ms08–67?).

    Нажав enter , попробуйте ввести в консоли

    C . Это управляющая последовательность в сессии, позволяющая вносить изменения в существующее соединение.

    Здесь вы можете увидеть, что мы переадресовали наш локальный порт 1445 на хост Windows 2003, который нашли во внутренней сети. Теперь просто запустите msfconsole , и можно идти дальше (предполагая, что вы планируете использовать этот хост).
    Эти примеры, советы и команды ssh должны дать отправную точку; дополнительная информация о каждой из команд и возможностей доступна на справочных страницах ( man ssh , man ssh_config , man sshd_config ).

    Меня всегда очаровывала возможность обращаться к системам и выполнять команды в любой точке мира. Развивая свои навыки по работе с инструментами вроде ssh вы станете более эффективным в любой игре, в какую играете.

    Парсер Хабра

    Вас тоже достает, когда автор переносит топик в черновик?

    среда, 9 января 2020 г.

    [Перевод] Практические советы, примеры и туннели SSH

    Знание нескольких трюков ssh полезно любому системному администратору, сетевому инженеру или специалисту по безопасности.

    Практические примеры SSH

    Разбор командной строки SSH

    $ whoami). Пользователя также можно указать параметром -l .

  • remoteserver : имя хоста, к которому подключается ssh , это может быть полное доменное имя, IP-адрес или любой хост в локальном файле hosts. Для подключения к хосту, который поддерживает и IPv4, и IPv6, можно добавить в командную строку параметр -4 или -6 для правильного резолвинга.


  • Все вышеперечисленные параметры являются необязательными, кроме remoteserver .

    Использование файла конфигурации

    /.ssh/config , но его можно определить как параметр для опции -F .
    В приведённом выше примерном файле конфигурации ssh две записи хоста. Первая обозначает все хосты, для всех применяется параметр конфигурации Port 2222. Вторая говорит, что для хоста remoteserver следует использовать другое имя пользователя, порт, FQDN и IdentityFile.

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

    Копирование файлов по SSH с помощью SCP

    Не забывайте о разнице в параметре порта. На этом попадаются многие, кто запускает scp из командной строки. Здесь параметр порта -P , а не -p , как в ssh-клиенте! Вы забудете, но не волнуйтесь, все забывают.

    Для тех, кто знаком с консольным ftp , многие из команд похожи в sftp . Вы можете сделать push, put и ls, как сердце пожелает.

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

    1. SSH socks-прокси

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

    Активация socks-прокси в Chrome

    Использование других приложений с прокси

    Подсказка: если используете удалённый рабочий стол из Linux на Windows? Попробуйте клиент FreeRDP. Это более современная реализация, чем rdesktop , с гораздо более плавным взаимодействием.

    Вариант использования SSH через socks-прокси

    2. Туннель SSH (переадресация портов)

    Поднимемся на ступеньку. В следующем примере порты прослушивания связываются с другими узлами локальной сети.

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

    3. SSH-туннель на сторонний хост

    4. Обратный SSH-туннель

    5. Обратный прокси SSH

    Устранение проблем с удалёнными SSH-туннелями

    Предупреждение безопасности

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

    6. Установка VPN по SSH

    Для такой точки опоры мы можем использовать SSH-прокси и proxychains, однако есть некоторые ограничения. Например, не получится работать напрямую с сокетами, поэтому мы не сможем сканировать порты внутри сети через Nmap SYN .

    Используя этот более продвинутый вариант VPN, подключение снижается до уровня 3. Затем мы можем просто направить трафик через туннель, используя стандартную сетевую маршрутизацию.

    Метод использует ssh , iptables , tun interfaces и маршрутизацию.

    Сначала нужно задать эти параметры в sshd_config . Поскольку мы вносим изменения в интерфейсы и удалённой, и клиентской системы, нам нужны права root с обеих сторон.

    Затем установим ssh-соединение, используя параметр, который запрашивает инициализацию tun-устройств.
    Теперь у нас должно быть устройство tun при показе интерфейсов ( # ip a ). Следующий шаг добавит IP-адреса к туннельным интерфейсам.

    Сторона клиента SSH:

    Сторона сервера SSH:
    Теперь у нас прямой маршрут к другому хосту ( route -n и ping 10.10.10.10 ).

    Можно маршрутизировать любую подсеть через хост на другой стороне.

    На удалённой стороне необходимо включить ip_forward и iptables .
    Бум! VPN через туннель SSH на сетевом уровне 3. Вот это уже победа.

    Если возникают какие-то проблемы, используйте tcpdump и ping , чтобы установить причину. Поскольку мы играем на уровне 3, то наши пакеты icmp пойдут через этот туннель.

    7. Копирование ключа SSH (ssh-copy-id)

    /.ssh/id_rsa.pub (или ключ по умолчанию) с вашей системы в

    /.ssh/authorized_keys на удалённом сервере.

    8. Удалённое выполнение команд (неинтерактивно)

    Другой пример выполняет ту же самую функцию, что и ssh-copy-id из примера 7.

    9. Удалённый перехват пакетов и просмотр в Wireshark

    10. Копирование локальной папки на удалённый сервер по SSH

    11. Удалённые приложения GUI с переадресацией SSH X11

    12. Удалённое копирование файлов с помощью rsync и SSH

    В этом примере используется сжатие gzip (-z) и режим архивирования (-a), который включает рекурсивное копирование.

    13. SSH через сеть Tor

    14. SSH к инстансу EC2

    /.ssh/ .
    Параметр -i просто указывает ssh-клиенту использовать этот ключ. Файл

    /.ssh/config идеально подходит для автоматической настройки использования ключа при подключении к хосту ec2.

    15. Редактирование текстовых файлов с помощью VIM через ssh/scp

    16. Монтирование удалённого SSH как локальной папки с SSHFS

    17. Мультиплексирование SSH с помощью ControlPath

    18. Потоковое видео по SSH с помощью VLC и SFTP

    19. Двухфакторная аутентификация

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

    20. Прыжки по хостам с ssh и -J

    $ ssh host2 и т. д. Параметр -J хитро использует переадресацию, чтобы localhost устанавливал сеанс со следующим хостом в цепочке. Таким образом, в приведённом выше примере наш localhost аутентифицируется на host4. То есть используются наши ключи localhost, а сеанс от localhost до host4 полностью зашифрован.

    Для такой возможности в ssh_config укажите опцию конфигурации ProxyJump. Если регулярно приходится переходить через несколько хостов, то автоматизация через конфиг сэкономит массу времени.

    21. Блокировка попыток брутфорса SSH с помощью iptables

    С помощью iptables тоже можно легко блокировать попытки подключения к порту по достижении определённого порога. Простой способ сделать это — использовать OSSEC, поскольку он не только блокирует SSH, но выполняет кучу других мер по обнаружению вторжений на базе имени хоста (HIDS).

    22. SSH Escape для изменения переадресации портов

    Нажав enter , попробуйте ввести в консоли

    C . Это управляющая последовательность в сессии, позволяющая вносить изменения в существующее соединение.

    Здесь вы можете увидеть, что мы переадресовали наш локальный порт 1445 на хост Windows 2003, который нашли во внутренней сети. Теперь просто запустите msfconsole , и можно идти дальше (предполагая, что вы планируете использовать этот хост).
    Эти примеры, советы и команды ssh должны дать отправную точку; дополнительная информация о каждой из команд и возможностей доступна на справочных страницах ( man ssh , man ssh_config , man sshd_config ).

    Меня всегда очаровывала возможность обращаться к системам и выполнять команды в любой точке мира. Развивая свои навыки по работе с инструментами вроде ssh вы станете более эффективным в любой игре, в какую играете.

    Практические советы, примеры и туннели SSH

    Практические примеры SSH, которые выведут на новый уровень ваши навыки удалённого системного администратора. Команды и советы помогут не только использовать SSH , но и более грамотно перемещаться по сети.

    Знание нескольких трюков ssh полезно любому системному администратору, сетевому инженеру или специалисту по безопасности.

    Практические примеры SSH

    Разбор командной строки SSH

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

    • -v : вывод отладочной информации особенно полезен при анализе проблем аутентификации. Можно использовать несколько раз для вывода дополнительной информации.
    • — p 22 : порт для подключения к удалённому серверу SSH. 22 не обязательно указывать, потому что это значение по умолчанию, но если протокол на каком-то другом порту, то указываем его с помощью параметра -p . Порт прослушивания указывается в файле sshd_config в формате Port 2222 .
    • -C : сжатие для соединения. Если у вас медленный канал или вы просматриваете много текста, это может ускорить связь.
    • neo@ : строка перед символом @ обозначает имя пользователя для аутентификации на удалённом сервере. Если не указать его, то по умолчанию будет использоваться имя пользователя учётной записи, в которую вы вошли в данный момент (

    $ whoami). Пользователя также можно указать параметром -l .

  • remoteserver : имя хоста, к которому подключается ssh , это может быть полное доменное имя, IP-адрес или любой хост в локальном файле hosts. Для подключения к хосту, который поддерживает и IPv4, и IPv6, можно добавить в командную строку параметр -4 или -6 для правильного резолвинга.
  • Все вышеперечисленные параметры являются необязательными, кроме remoteserver .

    Использование файла конфигурации

    /.ssh/config , но его можно определить как параметр для опции -F .

    В приведённом выше примерном файле конфигурации ssh две записи хоста. Первая обозначает все хосты, для всех применяется параметр конфигурации Port 2222. Вторая говорит, что для хоста remoteserver следует использовать другое имя пользователя, порт, FQDN и IdentityFile.

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

    Копирование файлов по SSH с помощью SCP

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

    В этом примере файл mypic.png скопирован на remoteserver в папку /media/data и переименован в mypic_2.png.

    Не забывайте о разнице в параметре порта. На этом попадаются многие, кто запускает scp из командной строки. Здесь параметр порта -P , а не -p , как в ssh-клиенте! Вы забудете, но не волнуйтесь, все забывают.

    Для тех, кто знаком с консольным ftp , многие из команд похожи в sftp . Вы можете сделать push, put и ls, как сердце пожелает.

    Практические примеры

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


    1. SSH socks-прокси

    Функция SSH Proxy под номером 1 по уважительной причине. Она более мощная, чем многие предполагают, и даёт вам доступ к любой системе, к которой имеет доступ удалённый сервер, используя практически любое приложение. Клиент ssh может туннелировать трафик через прокси-сервер SOCKS одной простой командой. Важно понимать, что трафик к удалённым системам будет исходить от удалённого сервера, так будет указано в логах веб-сервера.

    Здесь мы запускаем socks-прокси на TCP-порту 8888, вторая команда проверяет, что порт активен в режиме прослушивания. 127.0.0.1 указывает, что служба работает только на localhost. Мы можем применить немного другую команду для прослушивания всех интерфейсов, включая ethernet или wifi, это позволит другим приложениям (браузерам и т д.) в нашей сети подключаться к прокси-сервису через ssh socks-прокси.

    Теперь можем настроить браузер для подключения к socks-прокси. В Firefox выберите Настройки | Основные | Параметры сети. Укажите IP-адрес и порт для подключения.

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

    Активация socks-прокси в Chrome

    Запуск Chrome с определёнными параметрами командной строки активирует socks-прокси, а также туннелирование DNS-запросов из браузера. Доверяй, но проверяй. Используйте tcpdump для проверки, что DNS-запросы больше не видны.

    Использование других приложений с прокси

    Имейте в виду, что многие другие приложения тоже могут использовать socks-прокси. Веб-браузер просто самое популярное из них. У некоторых приложений есть параметры конфигурации для активации прокси-сервера. Другим нужно немного помочь вспомогательной программой. Например, proxychains позволяет запустить через socks-прокси Microsoft RDP и др.

    Параметры конфигурации socks-прокси задаются в файле конфигурации proxychains.

    Подсказка: если используете удалённый рабочий стол из Linux на Windows? Попробуйте клиент FreeRDP. Это более современная реализация, чем rdesktop , с гораздо более плавным взаимодействием.

    Вариант использования SSH через socks-прокси

    Вы сидите в кафе или гостинице — и вынуждены использовать довольно ненадёжный WiFi. С ноутбука локально запускаем ssh-прокси и устанавливаем ssh-туннель в домашнюю сеть на локальный Rasberry Pi. Используя браузер или другие приложения, настроенные для socks-прокси, мы можем получить доступ к любым сетевым службам в нашей домашней сети или выйти в интернет через домашнее подключение. Всё между вашим ноутбуком и домашним сервером (через Wi-Fi и интернет до дома) зашифровано в туннеле SSH.

    2. Туннель SSH (переадресация портов)

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

    Разберём параметр -L . Его можно представить как локальную сторону прослушивания. Таким образом, в примере выше порт 9999 прослушивается на стороне localhost и переадресуется через порт 80 на remoteserver. Обратите внимание, что 127.0.0.1 относится к localhost на удалённом сервере!

    Поднимемся на ступеньку. В следующем примере порты прослушивания связываются с другими узлами локальной сети.

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

    3. SSH-туннель на сторонний хост

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

    В данном примере мы перенаправляем туннель от remoteserver к веб-серверу, работающему на 10.10.10.10. Трафик с remoteserver к 10.10.10.10 уже не в SSH-туннеле. Веб-сервер на 10.10.10.10 будет считать remoteserver источником веб-запросов.

    4. Обратный SSH-туннель

    Здесь настроим прослушивающий порт на удалённом сервере, который будет подключаться обратно к локальному порту на нашем localhost (или другой системе).

    В этой SSH-сессии устанавливается соединение с порта 1999 на remoteserver к порту 902 на нашем локальном клиенте.

    5. Обратный прокси SSH

    В этом случае мы устанавливаем socks-прокси на нашем ssh-соединении, однако прокси слушает на удалённом конце сервера. Подключения к этому удалённому прокси теперь появляются из туннеля как трафик с нашего localhost.

    Устранение проблем с удалёнными SSH-туннелями

    Если у вас возникли проблемы с работой удалённых опций SSH, проверьте с помощью netstat , к каким ещё интерфейсам подключён порт прослушивания. Хотя мы в примерах указали 0.0.0.0, но если значение GatewayPorts в sshd_config установлено в значение no, то листенер будет привязан только к localhost (127.0.0.1).

    Предупреждение безопасности

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

    6. Установка VPN по SSH

    Общий термин среди спецов по методам атаки (пентестеры и проч.) — это «точка опоры в сети». После установления соединения в одной системе эта система становится шлюзом для дальнейшего доступа к сети. Точка опоры, которая позволяет двигаться вширь.

    Для такой точки опоры мы можем использовать SSH-прокси и proxychains, однако есть некоторые ограничения. Например, не получится работать напрямую с сокетами, поэтому мы не сможем сканировать порты внутри сети через Nmap SYN .

    Используя этот более продвинутый вариант VPN, подключение снижается до уровня 3. Затем мы можем просто направить трафик через туннель, используя стандартную сетевую маршрутизацию.

    Метод использует ssh , iptables , tun interfaces и маршрутизацию.

    Сначала нужно задать эти параметры в sshd_config . Поскольку мы вносим изменения в интерфейсы и удалённой, и клиентской системы, нам нужны права root с обеих сторон.

    Затем установим ssh-соединение, используя параметр, который запрашивает инициализацию tun-устройств.

    Теперь у нас должно быть устройство tun при показе интерфейсов ( # ip a ). Следующий шаг добавит IP-адреса к туннельным интерфейсам.

    Сторона клиента SSH:

    Сторона сервера SSH:

    Теперь у нас прямой маршрут к другому хосту ( route -n и ping 10.10.10.10 ).

    Можно маршрутизировать любую подсеть через хост на другой стороне.

    На удалённой стороне необходимо включить ip_forward и iptables .

    Бум! VPN через туннель SSH на сетевом уровне 3. Вот это уже победа.

    Если возникают какие-то проблемы, используйте tcpdump и ping , чтобы установить причину. Поскольку мы играем на уровне 3, то наши пакеты icmp пойдут через этот туннель.

    7. Копирование ключа SSH (ssh-copy-id)

    /.ssh/id_rsa.pub (или ключ по умолчанию) с вашей системы в

    /.ssh/authorized_keys на удалённом сервере.

    8. Удалённое выполнение команд (неинтерактивно)

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

    В данном примере grep выполняется на локальной системе после того, как лог скачался по ssh-каналу. Если файл большой, удобнее запустить grep на удалённой стороне, просто заключив обе команды в двойные кавычки.

    Другой пример выполняет ту же самую функцию, что и ssh-copy-id из примера 7.

    9. Удалённый перехват пакетов и просмотр в Wireshark

    Я взял один из наших примеров по tcpdump. Используйте его для удалённого перехвата пакетов с выдачей результата непосредственно в GUI локального Wireshark.

    10. Копирование локальной папки на удалённый сервер по SSH

    Красивый трюк, который сжимает папку с помощью bzip2 (это параметр -j в команде tar ), а затем извлекает поток bzip2 на другой стороне, создавая на удалённом сервере дубликат папки.

    11. Удалённые приложения GUI с переадресацией SSH X11

    Если на клиенте и удалённом сервере установлены «иксы», то можно удалённо выполнить команду GUI, с окном на вашем локальном рабочем столе. Эта функция существует давным давно, но по-прежнему очень полезна. Запустите удалённый веб-браузер или даже консоль VMWawre Workstation, как я делаю в этом примере.

    Требуется строка X11Forwarding yes в файле sshd_config .

    12. Удалённое копирование файлов с помощью rsync и SSH

    rsync во многом удобнее scp , если требуется периодическое резервное копирование каталога, большого количества файлов или очень больших файлов. Здесь есть функция восстановления после сбоя передачи и копирования только изменённых файлов, что сохраняет трафик и время.

    В этом примере используется сжатие gzip (-z) и режим архивирования (-a), который включает рекурсивное копирование.

    13. SSH через сеть Tor

    Анонимная сеть Tor может туннелировать SSH-трафик с помощью команды torsocks . Следующая команда прокинет ssh-прокси через Tor.

    Torsocks будет использовать для прокси порт 9050 на localhost. Как всегда при использовании Tor необходимо серьёзно проверять, какой трафик туннелируется и другие проблемы операционной безопасности (opsec). Куда идут ваши DNS-запросы?

    14. SSH к инстансу EC2

    Параметр -i просто указывает ssh-клиенту использовать этот ключ. Файл

    /.ssh/config идеально подходит для автоматической настройки использования ключа при подключении к хосту ec2.

    15. Редактирование текстовых файлов с помощью VIM через ssh/scp

    Для всех любителей vim этот совет сэкономит немного времени. С помощью vim файлы редактируются по scp одной командой. Этот метод просто создаёт файл локально в /tmp , а затем копирует его обратно, как только мы его сохранили из vim .

    Примечание: формат немного отличается от обычного scp . После хоста у нас двойной // . Это ссылка на абсолютный путь. Один слэш будет означать путь относительно домашней папки users .

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

    16. Монтирование удалённого SSH как локальной папки с SSHFS

    При помощи sshfs — клиента файловой системы ssh — мы можем подключить локальный каталог к удалённому местоположению со всеми взаимодействиями файлов в зашифрованном сеансе ssh .

    На Ubuntu и Debian установим пакет sshfs , а затем просто приимонтируем удалённое расположение к нашей системе.

    17. Мультиплексирование SSH с помощью ControlPath

    По умолчанию при наличии существующего подключения к удалённому серверу с помощью ssh второе подключение с помощью ssh или scp устанавливает новый сеанс с дополнительной аутентификацией. Опция ControlPath позволяет использовать существующий сеанс для всех последующих соединений. Это значительно ускорит процесс: эффект заметен даже в локальной сети, а тем более при подключении к удалённым ресурсам.

    ControlPath указывает сокет для проверки новыми соединениями на предмет наличия активной сессии ssh . Последняя опция означает, что даже после выхода из консоли существующий сеанс останется открытым 10 минут, так что в течение этого времени вы сможете повторно подключиться по существующему сокету. Для дополнительной информации смотрите справку ssh_config man .

    18. Потоковое видео по SSH с помощью VLC и SFTP

    Даже давние пользователи ssh и vlc (Video Lan Client) не всегда знают об этой удобной опции, когда очень нужно посмотреть видео по сети. В настройках File | Open Network Stream программы vlc можно ввести местоположение как sftp:// . Если требуется пароль, появится запрос.

    19. Двухфакторная аутентификация

    Такая же двухфакторная аутентификация, как у вашего банковского счёта или учётной записи Google , применима к сервису SSH.

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

    20. Прыжки по хостам с ssh и -J

    Если из-за сегментации сети приходится переходить через несколько хостов ssh, чтобы добраться до конечной сети назначения, вам сэкономит время ярлык -J.

    Здесь главное понимать, что это не аналогично команде ssh host1 , затем user@host1:

    $ ssh host2 и т. д. Параметр -J хитро использует переадресацию, чтобы localhost устанавливал сеанс со следующим хостом в цепочке. Таким образом, в приведённом выше примере наш localhost аутентифицируется на host4. То есть используются наши ключи localhost, а сеанс от localhost до host4 полностью зашифрован.

    Для такой возможности в ssh_config укажите опцию конфигурации ProxyJump. Если регулярно приходится переходить через несколько хостов, то автоматизация через конфиг сэкономит массу времени.

    21. Блокировка попыток брутфорса SSH с помощью iptables

    Любой, кто управлял сервисом SSH и просматривал логи, знает о количестве попыток брутфорса, которые происходят каждый час каждый день. Быстрый способ уменьшить шум в логах — перенести SSH на нестандартный порт. Внесите изменения в файл sshd_config с помощью параметра конфигурации Port##.

    С помощью iptables тоже можно легко блокировать попытки подключения к порту по достижении определённого порога. Простой способ сделать это — использовать OSSEC, поскольку он не только блокирует SSH, но выполняет кучу других мер по обнаружению вторжений на базе имени хоста (HIDS).

    22. SSH Escape для изменения переадресации портов

    И наш последний пример ssh предназначен для изменения переадресации портов на лету в рамках существующего сеанса ssh . Представьте такой сценарий. Вы глубоко в сети; возможно, прыгнули через полдюжины хостов и вам нужен локальный порт на рабочей станции, который перенаправлен на Microsoft SMB старой системы Windows 2003 (кто-нибудь помнит ms08-67?).

    Нажав enter , попробуйте ввести в консоли

    C . Это управляющая последовательность в сессии, позволяющая вносить изменения в существующее соединение.

    Здесь вы можете увидеть, что мы переадресовали наш локальный порт 1445 на хост Windows 2003, который нашли во внутренней сети. Теперь просто запустите msfconsole , и можно идти дальше (предполагая, что вы планируете использовать этот хост).

    Завершение

    Эти примеры, советы и команды ssh должны дать отправную точку; дополнительная информация о каждой из команд и возможностей доступна на справочных страницах ( man ssh , man ssh_config , man sshd_config ).

    Меня всегда очаровывала возможность обращаться к системам и выполнять команды в любой точке мира. Развивая свои навыки по работе с инструментами вроде ssh вы станете более эффективным в любой игре, в какую играете.

    Мастер Йода рекомендует:  Что такое пинг и как его проверить
    Добавить комментарий