2016-03-05 3 views
-2

У меня есть два экземпляра EC2 в той же подсети, но я, когда я пытаюсь SSH от одного экземпляра к другому я получаю ОткрытыйКлюч отказано сообщение, он не запрашивает парольНевозможно SSH экземпляров EC2 в той же подсети

[корень @ ip-10-0-21-156 ~] # ssh [email protected] Разрешение отклонено (публикация).

+0

Вы настроили ssh на этом сервере для использования паролей вместо ssh-ключей? Поскольку он не запрашивает пароль, это звучит так, как будто вы этого не сделали. –

ответ

0

По умолчанию экземпляры EC2 настроены для обеспечения аутентификации SSH через общедоступные/закрытые ключи. Итак, точно так же, как вам нужен секретный ключ (вероятно, вы загрузили файл .pem, когда вы создали пару ключей IAM), установленную на вашем локальном компьютере, чтобы получить SSH в экземпляр, вам также нужен закрытый ключ, установленный на экземпляре, чтобы SSH из этого экземпляра в другой экземпляр.

То, что вы не видели позади, было то, что когда вы запустили экземпляр и указали имя пары ключей, EC2 позволяет загружать закрытый ключ (файл .pem), автоматически создавал пользователя в экземпляре (например, на Ubuntu AMI, имя пользователя - «ubuntu», а в AMI Amazon Linux - имя пользователя «ec2-user»), и он поместил открытый ключ, который соответствует закрытому ключу в файл ~/.ssh/authorized_keys. Все это должно произойти, прежде чем вы сможете использовать SSH в экземпляре.

Итак, предположим, что вы запустили два экземпляра с той же ключевой парой, чтобы SSH из экземпляра A в экземпляр B, все было сделано для вас. EXCEPT для размещения закрытого ключа (файла .pem) в ~/.ssh. AWS считает сохранение секретного ключа на примере угрозой безопасности и, следовательно, не делает это автоматически. Так, просто поставить секретный ключ в каталог .ssh на экземпляр А, а затем добавить его в связках или вы можете указать ключ в команде SSH, как так:

ssh -i ~/.ssh/PRIVATE_KEY.pem [email protected]_B_LOCAL_IP 

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

Кроме того, вы действительно не должны использовать созданную пользователем учетную запись EC2 (то есть ubuntu @ или ec2-user @) для повседневной работы или даже для обслуживания или другой работы с системным администратором. Вы действительно должны создать свою собственную учетную запись, потому что созданная EC2 учетная запись по сути является учетной записью root.

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

Единственное, что вам нужно сделать при создании дополнительных учетных записей (на основе пароля или на основе ключей), - это убедиться, что ваша персонализированная учетная запись имеет доступ к sudo, поэтому вы можете делать то, что требует доступа root. В Ubuntu, вы можете сделать это, добавив следующую строку в файл /etc/sudoers.d/90-cloud-init-users:

USERNAME ALL=(ALL) NOPASSWD:ALL 

Пока вы там, рассмотреть отключение доступа SUDO для EC2 создал имя пользователя. Даже если никто не будет иметь ключ, каждый будет знать, что есть учетная запись ubuntu, которая имеет доступ к sudo. Как и с паролями, знание имени пользователя является существенной частью работы хакеров.

Надеюсь, это поможет.

Смежные вопросы