Отказано в разрешении (publickey) при SSH-доступе к экземпляру Amazon EC2 [закрыто]

в этом случае проблема возникает из-за потерянной пары ключей. Об этом:

• невозможно изменить пару ключей на экземпляре. Необходимо создать новый экземпляр, использующий новую пару ключей.
• вы можете обойти проблему если ваш экземпляр используется приложением на Эластичный Бобовый Стебель.

вы можете выполнить следующие шаги:

1. доступ к управление AWS Консоль
2. открыть Эластичный Бобовый Стебель Tab
3. выберите приложение Все Приложения Tab
4. С левой стороны menù выберите конфигурация
5. нажмите на кнопку экземпляров шестерня
6. на сервер форма проверки EC2 пара ключей введите и выберите новую пару ключей. Возможно, вам придется обновить список, чтобы увидеть новую пару ключей ты просто создан.
7. сохранить
8. Elastic Beanstalk создаст для вас новые экземпляры, связанные с новой парой ключей.

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

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

1. доступ к управление AWS Консоль
2. открыть вкладка EC2
3. С экземпляров списке выберите экземпляр, который вас интересует
4. на Описание чек на имя Группа Безопасности ваш экземпляр, используя.
5. раз в Описание нажать на кнопку правила и проверьте, есть ли у вашей группы безопасности правило для входящего трафика ssh на порту 22
6. Если нет, то в Сеть И Безопасность меню выберите Группа Безопасности
7. выберите Группа Безопасности используется вашим экземпляром и нажмите Входящий
8. слева от вкладки входящие вы можете составить правило для входящего трафика SSH:
   • создать новое правило: SSH
   • источник: IP-адрес или подсети, из которых вы хотите получить доступ к пример
   • Примечание: если вы хотите предоставить неограниченный доступ к вашему экземпляру вы можете указать 0.0.0.0/0, хотя Amazon не рекомендует эту практику
9. клик Добавить Правило а то Применить Изменения
10. проверьте, можете ли вы теперь подключиться к своему экземпляру через SSH.

надеюсь, это может помочь кому-то, как помог мне.

вот как я решил проблему

ssh -i <key> ec2-user@<ec2 ip>

я решил проблему просто поставив sudo до

sudo ssh -i mykey.pem myec2.amazonaws.com

но правильное решение-сначала изменить владельца, а затем подключиться как обычный пользователь, как сказал Янус Трольсен ниже. В моем случае это было бы:

chown wellington:wellington key.pem

попробуйте использовать

sudo ssh -i mykey.pem ubuntu@<ec2_ip_public_dns>

или

sudo ssh -i mykey.pem ec2-user@<ec2_ip_public_dns>

еще одна возможная причина этой ошибки:

когда домашний каталог-это group writeable, то пользователь не может войти.

(воспроизводится на экземпляре Ubuntu.)

для экземпляра ubuntu 12.04 lts micro мне пришлось установить имя пользователя в качестве опции

ssh -i pemfile.pem -l ubuntu dns

вам нужно сделать следующие шаги:

1. откройте ssh-клиент или терминал, если вы используете Linux.
2. найдите файл закрытого ключа и измените каталог.
   cd <path to your .pem file>
3. выполните следующие команды:
   chmod 400 <filename>.pem
ssh -i <filename>.pem ubuntu@<ipaddress.com>

если ubuntu пользователь не работает, то попробуйте с ec2-user.

я боролся с тем же разрешением отказано ошибка, по-видимому, из-за

key_parse_private2: missing begin marker 

в моей ситуации причиной был файл конфигурации ssh текущего пользователя (~ / .ssh / config).

используя следующие кнопки:

ssh -i ~/myKey.pem ec2-user@<IP address> -v 'exit'

начальный вывод показал:

debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config

... здесь вырезано много строк отладки ...

debug1: Next authentication method: publickey
debug1: Trying private key: /home/ec2-user/somekey.pem
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

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

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

$ cat config
StrictHostKeyChecking=no
#Host myAlias
        user ec2-user
        Hostname bitbucket.org
#        IdentityFile ~/.ssh/somekey
#        IdentitiesOnly yes

Host my2ndAlias
        user myOtherUser
        Hostname bitbucket.org
        IdentityFile ~/.ssh/my2ndKey
        IdentitiesOnly yes

Я надеюсь, что кто-то еще находит это полезным.

Я забыл добавить имя пользователя (ubuntu) при подключении моего экземпляра Ubuntu. Поэтому я попробовал это:

ssh -i /path/my-key-pair.pem my-ec2-instance.amazonaws.com

и правильный путь был

ssh -i /path/my-key-pair.pem ubuntu@my-ec2-instance.amazonaws.com

Это случилось со мной несколько раз. Я использовал Amazon Linux AMI 2013.09.2 и Ubuntu Server 12.04.3 LTS, которые находятся на свободном уровне.

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

вот возможные разочаровывающие сценарии, которые вызывают эту ошибку:

Если вы обедаете новый экземпляр из AMI, созданного из другого экземпляра (скажем, экземпляр xyz), то новый экземпляр будет принимать только тот же ключ, что и используемый экземпляр A. Это совершенно понятно, но это сбивает с толку, потому что во время пошагового процесса создания нового экземпляра вас просят выбрать или создать ключ (на самом последнем шаге), который не будет работать.

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

Я тоже некоторое время боролся с этим, пока не нашел следующее:

eb ssh

когда вы используете это из каталога проекта, bingo-bango no muss no fuss, вы находитесь в

В моем случае, я сделал следующее:

chmod 400 <key.pem>

ssh -i <key.pem> ec2-user@ec2_public_dns (for debian)

Я изначально использовал root@ часть, и я получил это приглашение:

Please login as the user "ec2-user" rather than the user "root".

Я в Windows с помощью WinSCP. Он отлично работает как на File Explorer, так и на PuTTY SSH Shell для доступа к моей Amazon EC2-VPC Linux. Нет ничего общего с chmod pem file как он использует myfile.ppk преобразовать by генератор puttygen С Пэм.

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

ssh-add-K

повторно добавлен ключ, затем команда ssh для подключения вернулась к работе.

эта проблема может быть решена путем входа в Ubuntu с помощью команды ниже:

ssh -i ec2key.pem ubuntu@ec2-public-IP

У меня дважды были ключи и правильная командная строка ssh (я знаю, потому что я дублирую рабочий экземпляр Ubuntu 14.04), но просто не смог ssh в новый экземпляр, даже после ожидания 5 минут, как предложил Уэйд Андерсон выше.

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

Итак, если у вас есть эта проблема, попробуйте это.

вы должны проверить несколько вещей:

1. убедитесь, что ваш IP-адрес правильный
2. убедитесь, что вы используете правильный ключ
3. убедитесь, что вы используете правильное имя пользователя, можно попробовать: 3.1. администратор 3.2. ec2-пользователь 3.3. ubuntu

У меня была та же проблема, и она была решена после того, как я изменил имя пользователя на ubuntu. В документации AWS упоминался пользователь ec2-user, но почему-то не работает для меня.

мой закрытый ключ был установлен в permission 400 и привело к тому, что разрешение отказано в установке его на " 644 " помогло мне .

key_load_private_type: доступ запрещен это конкретная ошибка, которую я получал

устранение: Sudo chmod 644 <key.pem>

Примечание: установить на 644 необходимо, он не работал с 400

когда вы пытаетесь делать

ssh -i <.pem path> root@ec2-public-dns

вы получаете сообщение, советующее вам использовать ec2-user.

Please login as the user "ec2-user" rather than the user "root".

чтобы использовать

ssh -i <.pem path> ec2-user@ec2-public-dns

У меня была такая же проблема и очень странная. Если ты веришь, что делаешь все хорошо, то следуй этому.: Несколько раз возникает путаница в отношении пользователя для экземпляра EC2!! Несколько раз вы получаете ec2-user, ubuntu, centos и т. д. Так что Проверьте свое имя пользователя для machie!!

войти с пользователем root ssh -i yourkey.pem (400 permission) root@<ip> он выдаст ошибку и даст вам доступное имя пользователя. затем войдите в систему с этим пользователем.

это основная вещь, но всегда подтверждайте, какой пользователь вы пытаетесь сделать логин. Im мой случай было просто отвлечение. Я пытался использовать root пользователь:

ssh -i ~/keys/<key_name> root@111.111.111.111

но другой пользователь:

ssh -i ~/keys/<key_name> dedeco@111.111.111.111

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

для локальной машины делать это:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ecdsa

для удаленной машины сделайте это:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

после этого мой ssh снова начал работать без разрешения отказано (publickey) вещь.

еще одна возможная проблема: неправильный идентификатор входа

Проверьте "Инструкции По Использованию"

все хорошие предложения выше, но я столкнулся с тем, что я выбрал предварительно сделанный экземпляр. После запуска экземпляра ознакомьтесь с инструкциями по использованию. Я неправильно использовал идентификатор входа закрытого ключа, когда в инструкциях я должен был использовать ' bitnami '(например, bitnami@domain-I key.pem)

у меня была аналогичная ошибка

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: xxxx.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

моя проблема заключалась в том, что экземпляр не запустился должным образом из-за ошибки при запуске сценария запуска из Step 3: Configure instance detail под Advanced details:

то, что я думал, я ввел:

#include
 https://xxxx/bootstrap.sh


что на самом деле ломает экземпляров

#include

https://xxxx/bootstrap.sh

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

чувствительно к регистру.

неправильно: SSH EC2-пользователь @XXX.XX.XX.XX-i MyEC2KeyPair.Пем!--1-->

правильно: SSH ec2-пользователь @XXX.XX.XX.XX-i MyEC2KeyPair.Пем!--1-->

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

Я понял это, получив открытый ключ от моего закрытого ключа, Вот так:

ssh-keygen -y -f ./myprivatekey.pem

то, что вышло, не соответствовало тому, что было в ~/.ssh/authorized_keys на экземпляре EC2.

все выше ответы верны и должны работать в большинстве случаев. В том случае, если они не так, как было в моем случае, я просто избавился от своего ~/.ssh/known_hosts файл на машине, с которой я пытался ssh, и это решило проблему для меня. После этого я смог подключиться.