Можно ли реализовать следующие сценарии с помощью туннелей SSH?
Моя рабочая станция -> сервер перехода -> сервер приложений -> финал ресурс (порт 443)
Моя рабочая станция -> сервер приложений -> конечный ресурс (порт 443)
Серверы приложений могут обращаться к конечным ресурсам, но у меня нет доступа к ним. Я хотел бы провести небольшое тестирование на своей локальной рабочей станции. Я использую PuTTY для создания SSH-соединения.
Я прочитал несколько статей о туннелях SSH, но до сих пор не могу понять, как это работает и как я могу достичь чего-то подобного.
Прежде всего, помните, что порт пересылка работает только в том случае, если сервер разрешает это - поскольку это параметр, имеющий отношение к безопасности, его можно отключить по усмотрению администратора сервера.
Более того, вы можете найти подробную информацию об этих параметрах на страницах руководства OpenSSH:
Это подключается через сервер перехода к серверу приложений, использует ключи ssh-агента вашего исходного блока для входа на сервер приложений, и устанавливает туннель от 127.0.0.1:8443 до app-server: 443 (app-server в данном случае - localhost). Доступ к 127.0.0.1:8443 приведет к тому, что будет возвращено при доступе к серверу приложения: 443.
ssh -A -L 8443:localhost:443 -J user@jump-server user@app-server
Это делает то же самое, но не учитывает сервер перехода, что соответствует второму сценарию, который вы указали:
ssh -L 8443:localhost:443 user@app-server
Если это кажется немного неуклюже, нужно указать порты для пересылки явно, попробуйте следующее:
ssh -D 5050 -J user@jump-server,user@second-jump-server user@app-server
ssh -D 5050 -J user@jump-server user@app-server
ssh -D 5050 user@app-server
-D 5050
заставляет ssh
запускать прокси SOCKS5, который прослушивает localhost: 5050 и перенаправляет весь трафик на конечный целевой хост , app-server, в приведенных примерах. Трафик перенаправляется так, как если бы он был отправлен с сервера приложения,Также можно передавать запросы DNS. Чтобы это работало, вам необходимо настроить свой браузер на использование прокси-сервера SOCKS5.
Добавление -N
предотвратит создание ssh
оболочки после входа в систему и оставит открытым соединение (и блокирование) до тех пор, пока не будет нажата CTRL + C или соединение не будет разорвано иным образом.
Обновление : Предполагается, что все команды запускаются с вашей рабочей станции.
Если у вас нет доступа SSH к серверу приложений, попробуйте следующее:
(1) ssh -L 8443:app-server:443 user@jump-server
(2) ssh -D 5050 user@jump-server
с (1) вам необходимо получить доступ к https: // localhost: 8443 , с (2) и правильно настроенным браузером перейдите на https: // app-server / .
Попробуйте
ssh -A -t users@jump-server -A -t user@app-server
ОБНОВЛЕНИЕ: Извините за расплывчатость. Это сработает для вашего первого сценария.
-
пересылает соединение аутентификации агента, которое позволяет вам использовать ваш аутентифицированный сеанс для следующего перехода. Это особенно полезно, если вы подключаетесь к каждой системе с одним и тем же ключом, но предпочитаете не оставлять свой закрытый ключ на промежуточном хосте. Любое из указанных выше случаев можно отбросить, и вы по умолчанию будете аутентифицироваться от каждого перехода к следующему.
-t
вызывает эмуляцию псевдотерминала, которая позволяет тому, что происходит на дальнем конце, перемещаться вперед и назад через промежуточный сеанс.
Преимущество здесь в том, что вы получаете одну команду, которая помещает вас в сеанс на дальнем конце.
Что касается вашего второго сценария, решение, с которым связан Daywalker, предоставляет несколько отличных вариантов, используя -L
для сопоставления локального порта через посредник и удаленную систему или коммутатор -D
для создания туннеля с открытым концом, который просто вытекает из посредника.