возможно ли реализовать следующие сценарии с помощью туннелей SSH?
Моя рабочая станция -> сервер перехода -> сервер приложений -> конечный ресурс (порт 443)
Моя рабочая станция -> сервер приложений -> конечный ресурс (порт 443)
Серверы приложений могут достигать конечных ресурсов, но у меня нет к ним доступа. Я хотел бы провести небольшое тестирование на своей локальной рабочей станции. Я использую PuTTY для создания SSH-соединения.
Я прочитал несколько статей о туннелях SSH, но до сих пор не могу понять, как это работает и как я могу добиться чего-то подобного.
Прежде всего, имейте в виду, что переадресация портов работает только в том случае, если сервер разрешает это - поскольку это важная настройка безопасности, ее можно отключить по усмотрению администратора сервера.
Более того, вы можете найти подробную информацию об этих параметрах на страницах руководства OpenSSH:
Это подключается через сервер перехода к серверу приложений, использует ключи ssh-agent вашего источника для входа на сервер приложений и устанавливает туннель от 127.0.0.1:8443 к серверу приложений: 443 (в данном случае сервер приложений '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: // локальный: 8443, с (2) и правильно настроенным браузером перейдите к https: // app-server /.
Пытаться
ssh -A -t users@jump-server -A -t user@app-server
ОБНОВЛЕНИЕ: Извините за расплывчатость. Это сработает для вашего первого сценария.
-A пересылает соединение аутентификации агента, которое позволяет вам использовать аутентифицированный сеанс для следующего перехода. Это особенно полезно, если вы подключаетесь к каждой системе с одним и тем же ключом, но предпочитаете не оставлять свой закрытый ключ на промежуточном хосте. Любое приведенное выше вхождение можно отбросить, и вы будете аутентифицироваться по умолчанию от каждого перехода к следующему.
-t форсирует эмуляцию псевдотерминала, которая позволяет тому, что происходит на дальнем конце, перемещаться вперед и назад через промежуточный сеанс.
Преимущество здесь в том, что вы получаете одну команду, которая помещает вас в сеанс на дальнем конце.
Что касается вашего второго сценария, решение, с которым связан Daywalker, предоставляет несколько отличных вариантов, используя -L для сопоставления локального порта через посредника и удаленной системы или -D switch, чтобы создать открытый туннель, который просто вытекает из посредника.