Как получить доступ к SSH через NAT в VPC

Я пытаюсь выяснить плюсы и минусы различных подходов при доступе к SSH сервер внутри VPN через NAT сервер

Необходимое условие:

1- key.pem:.pem Файл для обоих серверов (предположим, что оба сервера используют один и тот же.pem):

2- публичный сервер доступа к порту SSH 22 за NAT сервер: 55.55.55.55

3- частный доступ с сервера NAT к порту SSH 22 на сервере позади NAT сервер: 10.0.0.100

Насколько я знаю, есть три подхода:

1- Использование переадресации портов -L опция:

от первого терминала:

ssh -i key.pem -L 5555:10.0.0.100:22 user@55.55.55.55

от терминала два:

ssh -i key.pem -p 5555 user@localhost

2- Использование переадресации агента

  ssh-add -K key.pem

  ssh –A user@55.55.55.55

Затем из другого терминала:

  ssh user@10.0.0.100

3- использование прокси-команды путем настройки / etc / ssh / ssh_config (по крайней мере, в Ubuntu не уверен насчет других ОС)

добавив следующее к /etc/ssh/ssh_config

Host 10.0.0.100
    IdentityFile <ABSOLUTE FOLDER PATH>/key.pem
    ProxyCommand ssh -q -W %h:%p -i <ABSOLUTE FOLDER PATH>/key.pem user@55.55.55.55

затем из терминала использовать:

  ssh user@10.0.0.100

Я нашел вариант 3 наиболее удобным, но не уверен насчет его безопасности.

Таким образом, мой вопрос заключается в том, при каких обстоятельствах следует использовать каждый подход? какие плюсы и минусы?

Источник

1 ответ

Этот метод называется SSH-ing через бастионный хост или Jumphost. Вот небольшая статья, которую я написал об этой технике.

(1) и (3) безопасны, но (3) является наиболее удобным. Это, так сказать, кошерный способ сделать это. Основное отличие в (3) состоит в том, что -W заставляет SSH прослушивать стандартный ввод и перенаправляет пакеты в конечную конечную точку SSH через Jumphost. -L прослушивает сокет TCP, который открыт на вашем клиенте.

(2) небезопасно, поэтому, пожалуйста, не используйте его. Прочитайте эту замечательную рецензию для получения дополнительной информации. Короче, -A открывает сокет на хосте переадресации, который перенаправляет запросы аутентификации SSH обратно клиенту. Если сокет скомпрометирован, злоумышленник может использовать сокет для аутентификации на любом хосте, к которому у вас есть доступ.

sshНа странице руководства пользователя есть предупреждение:

 -A      Enables forwarding of the authentication agent connection.  This can also be specified on a per-host basis in a configuration file.

         Agent forwarding should be enabled with caution.  Users with the ability to bypass file permissions on the remote host (for the agent's UNIX-domain
         socket) can access the local agent through the forwarded connection.  An attacker cannot obtain key material from the agent, however they can perform
         operations on the keys that enable them to authenticate using the identities loaded into the agent.
Источник
Другие вопросы по тегам