Блог

Главная - Вопросы по программированию - Попытка подключиться к экземпляру EC2 в частной подсети с сервера bastion

Попытка подключиться к экземпляру EC2 в частной подсети с сервера bastion

#amazon-web-services #amazon-ec2 #ssh

#amazon-web-services #amazon-ec2 #ssh

Вопрос:

У меня есть 2 экземпляра EC2 — один находится в частной подсети, подключенной к шлюзу nat, а другой — в общедоступной подсети, подключенной к интернет-шлюзу. У меня есть сервер jenkins в частной подсети и сервер bastion в общедоступной подсети.

Я использовал scp для копирования ключа pem, используемого при создании моего экземпляра jenkins, на мой сервер bastion, и теперь пытаюсь подключиться к экземпляру jenkins через bastion.

Я запускаю команду ssh -i pem.key ubuntu@privateipaddress , но продолжаю получать сообщение об ошибке «отказано в разрешении» (publickey).

Я проверил настройки своей группы безопасности для обоих экземпляров, и они проверяются. Входящие правила для группы безопасности jenkins разрешают трафик SSH и HTTP из группы безопасности bastion, а исходящие правила для группы безопасности jenkins в настоящее время разрешают весь трафик.

У меня обратная ситуация для группы безопасности bastion.

РЕДАКТИРОВАТЬ: подробный:

 OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 10.0.1.49 [10.0.1.49] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file key.pem type -1
debug1: key_load_public: No such file or directory
debug1: identity file key.pem-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 10.0.1.49:22 as 'ubuntu'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:EgAjWBAxVLz8L MQNQXZeIwh51QZOPxPhvugsxv1XGs
debug1: Host '10.0.1.49' is known and matches the ECDSA host key.
debug1: Found key in /home/ubuntu/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: key.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
ubuntu@10.0.1.49: Permission denied (publickey).

Комментарии:

1. Если вы получаете эту ошибку, то это не похоже на проблему группы безопасности. Попробуйте добавить -v в ssh команду, чтобы получить более подробный вывод.

2. Я отредактировал вопрос, чтобы включить подробный вывод

3. Где хранится этот файл «key.pem»?

4. я использовал scp, чтобы скопировать его в bastion. Он находится в папке .ssh на этом экземпляре

Ответ №1:

Мне удалось устранить эту проблему, следуя этому руководству: https://aws.amazon.com/blogs/security/securely-connect-to-linux-instances-running-in-a-private-amazon-vpc/

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

Комментарии:

1. Для вашего первого подхода использование ssh-агента не требовалось, почему это не сработало, полагается, конечно, где-то еще, имя пользователя правильное, файл ключа правильный? Но в любом случае лучшим подходом является пересылка ключей ssh. Не рекомендуется загружать ваш закрытый ключ на хост bastion, поскольку его может получить любой, у кого есть доступ к экземпляру!