Приносим извинения, если об этом спрашивали раньше, но в настоящее время я пытаюсь найти решение, которое позволит нам устанавливать SSH-соединения аналогично тому, как будет работать шлюз RDP. Для тех, кто не знаком, RDP Gateway позволяет вам проксировать RDP-соединения через другой сервер. Удаленный рабочий стол будет прозрачно аутентифицироваться на сервере шлюза RDP и установить оттуда соединение с сервером конечных точек, что позволит вам обращаться к серверам конечных точек по частным IP-адресам или внутренним DNS-именам, ограничивая вашу уязвимость.
В настоящее время я думаю настроить переадресацию портов через SSH, чтобы каждый сервер, к которому мы должны иметь доступ за туннельным прокси, находился на другом порту, который пересылается промежуточным сервером. Однако это не кажется оптимальным решением, поэтому мне интересно узнать, есть ли лучший способ сделать это.
В терминах SSH вы часто говорите о хозяин бастиона или сервер перехода - отдельная машина (обычно в вашей демилитаризованной зоне), которая принимает входящие SSH-соединения и с которой вы затем можете установить SSH-соединение с реальными системами, которыми вы управляете.
==> | Server1 |
_________ ___________ / ---------
| user PC | ===(SSH on port 22)===> | jump host | ===(SSH on port 22)== ==+> | Server2 |
_________ ___________ \ _________
==> | Server3 |
Часто для повышения безопасности сервер перехода требует двухфакторной аутентификации и / или принимает входящие сеансы SSH только после установления соединения VPN.
Вместо первого входа на узел перехода и из командной строки запуск второго сеанса SSH OpenSSH позволяет настроить его с помощью одной команды.
Я предпочитаю устанавливать все настройки явно в моем ~/.ssh/config с коротким псевдонимом для каждого хоста. Таким образом, мне не нужно будет использовать какие-либо флаги командной строки, и я могу просто ввести меньше и использовать ssh Destination и покончить с этим.
Host jumphost
Hostname jumphost.example.com
User serverfault
ForwardAgent yes
AddKeysToAgent yes
UseKeychain yes # Specific to OS X
IdentityFile ~/.ssh/id_rsa.jumphost
Host server1
Hostname server1.int.example.com
User hbruijn
ForwardAgent yes
AddKeysToAgent yes
UseKeychain yes # Specific to OS X
IdentityFile ~/.ssh/id_rsa.int.example.com
ProxyJump jumphost
ProxyJump - относительно новая настройка, которую я считаю более интуитивно понятной, чем ProxyCommand. Сейчас ssh server1 будет делать именно то, что вам нужно, сначала создайте сеанс, используя serverfault@jumphost.example.com в качестве первого перехода, из которого вы туннелируете к следующему переходу, необязательно с другим ключом ssh и другим именем пользователя hbruijn@server1.int.example.com.
Вы также можете использовать команду ProxyJump непосредственно из командной строки:
ssh -J serverfault@jumphost.example.com hbruijn@server1.int.example.com
Другой подход обсуждается в этот вопрос и ответ
Каноническое решение - развернуть IPv6 (и / или VPN) и с самого начала избегать подобного обходного пути, но если вы не можете сделать это сегодня, то это называется переходным блоком или бастионным хостом или аналогичными терминами. Это просто машина, которую вы устанавливаете, чтобы ваши пользователи могли входить в систему по ssh, а затем по ssh на внутренние хосты, к которым этот ящик имеет доступ к сети. В ssh command даже имеет параметр командной строки, который автоматизирует подключение через узел перехода.
-J destination
Connect to the target host by first making a ssh connection to
the jump host described by destination and then establishing a
TCP forwarding to the ultimate destination from there. Multiple
jump hops may be specified separated by comma characters. This
is a shortcut to specify a ProxyJump configuration directive.
Note that configuration directives supplied on the command-line
generally apply to the destination host and not any specified
jump hosts. Use ~/.ssh/config to specify configuration for jump
hosts.