Как подключить SSH к экземпляру ec2 в частной подсети VPC через сервер NAT

16

Я создал VPC в AWS с общедоступной подсетью и частной подсетью. Частная подсеть не имеет прямого доступа к внешней сети. Итак, в общедоступной подсети есть NAT-сервер, который перенаправляет весь исходящий трафик из частной подсети во внешнюю сеть.

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

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

Может кто-нибудь перечислить, что мне нужно настроить, чтобы сделать это возможным.

Наименования являются:

ноутбук (любое устройство вне VPC)

nat (сервер NAT в публичной подсети)

назначение (сервер в частной подсети, к которому я хочу подключиться)

Не уверен, что следующие ограничения или нет:

«Назначение» не имеет общедоступного IP-адреса, только ip подсети, например 10.0.0.1. «Назначение» не может подключиться к «nat» через общедоступный nat. Есть несколько серверов «назначения», мне нужно настроить один для каждого?

Благодарность

— jasonfungsing
источник

Эта ссылка описывает шаги, необходимые для подключения к экземплярам EC2 в частной подсети через переадресацию агента SSH.

— Шайлендер Рават

25

Вы можете настроить хост-бастион для подключения к любому экземпляру в вашем VPC:

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

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

Если вы создадите новый экземпляр в качестве обзора, вы:

1) создайте группу безопасности для вашего хоста бастиона, которая позволит SSH-доступ с вашего ноутбука (обратите внимание на эту группу безопасности для шага 4)

2) запустить отдельный экземпляр (бастион) в публичной подсети в вашем VPC

3) назначить этому бастионному хосту публичный IP либо при запуске, либо назначив Elastic IP

4) Обновите группы безопасности каждого из ваших экземпляров, которые не имеют общедоступного IP-адреса, чтобы разрешить SSH-доступ с хоста бастиона. Это можно сделать с помощью идентификатора группы безопасности хоста бастиона (sg - #####).

5) использовать переадресацию агента SSH (ssh -A user @ publicIPofBastion), чтобы сначала подключиться к бастиону, а затем один раз в бастион SSH к любому внутреннему экземпляру (ssh user @ private-IP-of-Internal-Instance). Переадресация агента обеспечивает переадресацию вашего личного ключа, поэтому его не нужно хранить в экземпляре бастиона ( никогда не храните личные ключи в любом случае !! )

Сообщение в блоге AWS, приведенное выше, должно быть в состоянии предоставить некоторые подробности относительно процесса. Я также включил ниже, на случай, если вы хотите получить дополнительную информацию о хозяевах бастиона:

Концепция бастионных хозяев: http://en.m.wikipedia.org/wiki/Bastion_host

Если вам нужны разъяснения, не стесняйтесь комментировать.

— jca-
источник

3

Обязательно разрешите SSH / 22 на входе и исходе на бастионе.

— user464180

Это настолько критический момент, что он должен быть частью ответа!

— Тарик

В дополнение к принятому ответу, который помогает, но не полностью, я должен был убедиться, что группы безопасности разрешают входящий и исходящий трафик. На первый взгляд это выглядело так, как будто они уже сделали, но, поскольку я использовал шаблон CloudFormation, я не заметил, что источником входящего трафика в частную подсеть был мой ELB. Таким образом, он разрешил весь трафик, но только от ELB. Изменение этого в моей общедоступной подсети решило проблему.

— Милан Маркович

1

Единственный способ, которым я мог заставить это работать.

1) Убедитесь, что группа безопасности для этого частного экземпляра имеет во входящем правиле группу безопасности из общедоступной подсети.

Порты Протокол Источник
Все Все SG-0b6616e070b9ea2d (группа общественной безопасности)

2) Используя прокси-команды, настройте свой конфигурационный файл ssh, чтобы иметь что-то вроде этого

vim ~/.ssh/config

Host publichost
   HostName 24.123.34.45
   User ubuntu
   IdentityFile ~/mypem.pem
   ProxyCommand none
Host privatehost
   HostName 10.0.2.133
   User ubuntu
   IdentityFile ~/mypem.pem
   ProxyCommand ssh publichost -W %h:%p

Запустите ssh privatehost это должно работать

— Леонардо Ампуэро
источник

0

Просто чтобы уточнить: как только вы подключитесь по ssh'd к вашему бастионному хосту, вам нужно ssh на хост NAT как пользователь ec2-user. Это немного меня взволновало, так как обычно пользователь ubuntu - это Ubuntu на AWS. Так я и сделал:

laptop> ssh -A ubuntu@ssh_bastion
ssh_bastion> ssh ec2-user@nat_private_dns_or_private_ip

Также помните, что у вашего ssh_bastion должно быть правило для исходящих сообщений, которое разрешает трафик на другие хосты и sg.

— Joel
источник

Это имя 'ec2_user' в результате раскручивания Amazon AMI, уже настроенного для службы NAT? Итак, как «ec2-пользователь» получил учетную запись на частной машине?

— Деннис