У нас возникла проблема с установлением SSH-подключений через удаленную переадресацию портов.
Сценарий представляет собой корпоративную сеть, где сервер во внутренней сети (назовем его «origin») должен войти через SSH на сервер в DMZ («target»). Поскольку целевой сервер в DMZ заблокирован для подключений из внутренней сети (и даже не виден из внутренней сети), у нас есть jump host в DMZ, через который мы проходим («jumphost»). Мы делаем это, настраивая удаленную переадресацию портов на jumphost.
Запускаем эту команду с исходного сервера во внутренней сети на jumphost:
origin> ssh -R *:1234:target:22 myusername@jumphost
Это делается для того, чтобы установить сеанс SSH на jumphost, заставить его начать прослушивание порта 1234 (просто пример произвольного номера порта) и перенаправить соединения с этого порта на порт 22 целевого сервера (SSH).
Затем мы устанавливаем второй сеанс SSH, по-прежнему от исходного сервера к хосту перехода, на порту 1234, который затем фактически подключается к целевому серверу на порту 22 — это наш «настоящий» сеанс SSH, в котором мы можем выполнять нашу работу на целевом сервере:
origin> ssh jumphost -P 1234
Конфигурация
Хост перехода настроен на разрешение удаленной переадресации портов со следующими настройками в sshd_config:
AllowTcpForwarding yes
GatewayPorts yes
Также, имеются брандмауэры между исходным сервером и хостом перехода для порта 22 (для начального SSH-подключения для настройки удаленного перенаправления портов) и порта 1234 (для последующего SSH-подключения на перенаправленном порту). Также имеется брандмауэр между хостом перехода и целью, который был открыт на порту 22.
Исход
Когда мы устанавливаем второе соединение (через перенаправленный порт), соединение немедленно закрывается («соединение закрыто удаленным хостом»).
Запуск tcpdump на целевом сервере не показывает никакой активности, т.е. похоже, что соединение блокируется.
Однако нам удается успешно установить обычную сессию SSH от jumphost к цели. Только при входе через перенаправленный порт соединение закрывается, хотя оба подключаются к цели на порту 22.
Более того, если мы настроим переадресацию портов на сервер во внутренней сети (т. е. соединение от источника во внутренней сети к хосту перехода в DMZ и обратно к третьему серверу во внутренней сети), то сеанс SSH будет успешно установлен.
Догадки и вопросы
Все это заставляет меня думать, что в игру вступают какие-то настройки сетевой безопасности, которые не позволяют подключаться через перенаправленный порт на сервере перехода к целевому серверу в DMZ. К сожалению, я недостаточно осведомлен, чтобы знать:
(1) Является ли SSH-подключение, идущее с исходного сервера через перенаправленный порт на сервере перехода, «отличным» с точки зрения политики безопасности сети, что его можно технически заблокировать, и если да, то как? И что нужно сделать, чтобы снять это ограничение?
(2) Есть ли другие причины, по которым это соединение не разрешено — настройки брандмауэра, настройки маршрутизатора, настройки SSH на исходном хосте или хосте jumphost, что-либо еще?
(3) Может ли это произойти из-за того, что исходный сервер не знает целевой сервер, и поэтому первая команда ssh не работает так, как задумано? Другими словами, интерпретируется ли имя хоста, указанное в первой команде ssh («target»), на клиенте (origin) или на сервере, к которому мы подключаемся для создания туннеля (jumphost)?
Больше всего меня озадачивает то, что обычный сеанс SSH может быть установлен от хоста-компьютера к цели. Я думал, что соединение SSH, входящее через перенаправленный порт, будет таким же, но почему-то это не так.
Любой вклад будет очень ценен.
решение1
Похоже, вам следует использовать локальную переадресацию портов вместо удаленной переадресации портов. Вы можете обратиться к следующему полезному посту в блоге Дирка Лосса:
Он включает в себя следующую иллюстративную диаграмму:
Чтобы прочитать схему, вам необходимо знать, что она описывает отношения между 4 различными ролями, участвующими в создании и использовании туннеля SSH:
- ssh-клиент (т.е.
sshклиент командной строки OpenSSH), используемый для установления туннеля; - ssh-сервер (т.е.
sshdдемон сервера OpenSSH), используемый для обслуживания другого конца туннеля; - сервер приложений (например, другой сервер ssh или сервер http);
- клиентское приложение (например, другой клиент SSH или веб-браузер), которому необходимо получить доступ к серверу приложений через туннель.
Также важно понимать, что два разных типа пересылки соответствуют двум разным вариантам использования:
Локальная переадресация: когда клиент приложения подключается через SSH-клиент
Удаленная переадресация: когда клиент приложения подключается через сервер SSH.
Удаленная пересылка так называется, потому что пересылка выполняется удаленно (на сервере ssh), а не локально (на клиенте ssh). Я также нахожу, что "удаленная пересылка = обратная пересылка" является полезной мнемоникой.
Итак, как вы видите, для того, чтобы инициировать соединение от sshклиента на originхосте через sshdсервер на прокси jumphostк третьему targetхосту, вам придется использовать локальную переадресацию портов. Удаленная переадресация портов предназначена для случая, когда вы хотите, чтобы точка входа в туннель находилась на хосте, на котором запущен сервер, sshdа не на хосте, на котором запущен sshклиент.
На странице руководства синтаксис локальной переадресации портов выглядит следующим образом:
ssh -L [bind_address:]port:host:hostport user@remote
Более наглядно это можно записать следующим образом:
ssh -L [local_bind_address:]local_port:remote_host:remote_host_port user@proxy_host
Или, используя ваши соглашения об именовании:
ssh -L [origin_bind_address:]origin_port:target_host:target_host_port user@jump_host
Если мы изменим вашу команду так, чтобы вместо этого использовать локальную переадресацию портов, то получим следующее:
user@origin:~$ ssh -L *:1234:target:22 myusername@jumphost