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

Question

Я пытаюсь выяснить плюсы и минусы различных подходов при доступе к серверу 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 наиболее удобным, но не уверен насчет его безопасности.

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

Answer 1

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

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

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

На man-странице 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.