Как правильно подключить SSH к серверу за NAT, поддерживая максимально возможную безопасность?

Question

У меня есть VPC в Amazon AWS. В публичной подсети работает сервер NAT, который подключается к интернет-шлюзу. У меня есть несколько серверов, работающих в различных частных подсетях в VPC. Я хотел бы использовать SSH на серверах, которые находятся в частной подсети. Все мои серверы работают под управлением AWS Linux (CentOS).

В настоящее время я могу использовать SSH на сервере NAT, используя свой закрытый ключ. Сервер NAT разрешает соединения SSH только с моего текущего IP-адреса разработки. Тогда я смогу подключиться к SSH на серверах в частных подсетях, только если я настрою SSH Login на этих серверах или если я помещу файл ключа на сервер NAT, а затем использую их для SSH. В целях безопасности кажется, что я не должен делать ни одну из этих вещей.

Есть ли предпочтительный лучший способ сделать это соединение? Похоже, должен быть способ подключения с помощью одного SSH-вызова с моей домашней машины разработки под управлением Apple OSX.

Answer 1

Я провел некоторое исследование и нашел статью, которая, кажется, связана с тем, о чем вы спрашиваете.

SSH и бастионные серверы

По умолчанию экземпляры Linux в EC2 используют файлы ключей SSH для аутентификации вместо имен пользователей и паролей SSH. Использование файлов ключей может снизить вероятность того, что кто-то попытается угадать пароль, чтобы получить доступ к экземпляру. Но использование пар ключей с хостом бастиона может представлять проблему - для подключения к экземплярам в частных подсетях требуется закрытый ключ, но вы никогда не должны хранить закрытые ключи на бастионе.

Одним из решений является использование переадресации агента SSH (ssh-agent) на клиенте. Это позволяет администратору подключаться с бастиона к другому экземпляру, не сохраняя закрытый ключ на бастионе. Этот подход я расскажу в этом посте.

http://blogs.aws.amazon.com/security/post/Tx3N8GFK85UN1G6/Securely-connect-to-Linux-instances-running-in-a-private-Amazon-VPC

Надеемся, что вы найдете решение в создании бастионного сервера и использовании переадресации агента SSH на своем клиенте, как рекомендует статья.

Answer 2

Вы не должны ставить свой секретный ключ на шлюз, и вам не нужно :-)

настройте локальную конфигурацию SSH, чтобы вы могли использовать NAT-шлюз для переадресации портов, когда вам это нужно:

создайте запись в вашем ~/.ssh/config которая устанавливает локальные перенаправления на хосты, к которым вы хотите подключиться:

Host natgw-fwd
        User ec2-user
        HostKeyAlias natgw-fwd.my.domain
        HostName 54.182.32.11
        LocalForward 1025 10.0.2.1:22

затем добавьте по одной записи на хост, перенаправленный с HostKeyAlias:

Host internal-one
        User ec2-user
        HostKeyAlias internal-one.ec2.internal
        HostName localhost
        Port 1025

привести туннель в одну раковину:

ssh -C -v natgw-fwd

и подключиться к внутренним хостам в другой оболочке:

ssh internal-one

При использовании большого количества «быстрых + коротких» соединений в дополнение к оболочке или двум, как, например, для такого инструмента, как dsh, задержка для настройки и разрыва отдельных соединений становится более заметной, и я использую ControlMaster и ControlPath для включения общего доступа к соединениям. Ограничения меня не беспокоят, потому что я редко использую агент или X11 в таком сценарии.

Answer 3

Ответ @Don King был очень полезным, и вот руководство, которое он предложил. В нем есть инструкции для OSX и Windows.

Вот краткое изложение того, что я сделал при входе в систему с локальной машины OSX. Это предполагает, что базовая инфраструктура в вашем VPC уже правильная. Смотрите этот урок для деталей.

1. Откройте исходящее соединение SSH в группе безопасности NAT, которое разрешает соединения с группой безопасности сервера в частной подсети.

2. Откройте входящее SSH-соединение в группе безопасности сервера в частной подсети, которое разрешает соединение из группы безопасности NAT.

3. В OSX добавьте ваш public_key.pem в локальную цепочку ключей: ssh-add -K .aws/public_key.pem

4. SSH с локального компьютера на NAT с использованием -A (ssh-agent): ssh -A ec2-user@ip_of_nat

5. SSH от NAT к серверу в общедоступной подсети: ssh ec2-user@ip_of_private_server

Потенциальные проблемы:

• убедитесь, что для ForwardAgent установлено значение yes в вашем файле OSX /etc /ssh_config. Это должно быть да по умолчанию.