Безопасность SSH-туннеля

Безопасность SSH-туннеля

У нас есть кластер (в настоящее время 10 машин) за NAT. Между частной сетью и обычной корпоративной сетью есть шлюз NAT/jump-host.

Пользователи могут sshперейти на хост-компьютер, а затем попасть на любую другую машину за NAT.

Я хотел бы предоставить простой скрипт, который поможет им туннелировать веб-интерфейсы за NAT к своим локальным машинам.

Поэтому моим первым предложением было: использовать SSH-прокси-сервер Socks и туннелировать интерфейсы на их локальный хост.

Итак, мой вопрос: если я создам эти два туннеля (один от локального компьютера моих коллег до jump-хоста, а другой от jump-хоста до соответствующей машины за NAT), насколько безопасен этот туннель?

Представьте, worker1что делает это:

ssh -t [email protected] -L 10001:localhost:33388 ssh -t hostxyz.behindnat.tld

На машине jump-host есть открытый порт 33388, который прослушивает интерфейс loopback. Если worker2просто войти в jump-host и использовать порт localhost 33388 для уже туннелированного соединения, он не должен проходить повторную аутентификацию в hostxyz.behindnat.tld, верно?

Мне кажется, что это огромная уязвимость в системе безопасности. Есть ли лучшее решение?

решение1

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

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

Настройте прокси-сервер Socks для worker1 следующим образом: ssh [email protected] -D 127.0.0.1:10001

Настройте браузер worker1 на использование socks localhost:10001для просмотра через jumphost.tld

Если вы хотите подключиться по ssh напрямую с worker1 на hostxyz, вы можете сделать что-то вроде следующего.

  ssh [email protected] -L localhost:10001:hostxyz:22
  ssh user@localhost:10001

Вот что я делаю. Я использую файл .ssh/config, чтобы все было организовано. Рекомендую прочитать следующее для информации о файле конфигурации и туннелировании.https://man.openbsd.org/ssh_configПосмотрите выступление Майкла В. Лукаса об openssh, чтобы получить еще одно хорошее введение.

Связанный контент