В доступе отказано (publickey), когда SSH Доступ к Amazon EC2 экземпляр [закрыт]

Я хочу использовать свой экземпляр Amazon ec2, но столкнулся со следующей ошибкой:

Permission denied (publickey).

Я создал свою пару ключей и скачал .pem файл.

Данный:

chmod  600 pem file.

Затем эта команда

ssh -i /home/kashif/serverkey.pem  ubuntu@ec2-54-227-242-179.compute-1.amazonaws.com

Но есть эта ошибка:

Permission denied (publickey)

Кроме того, как я могу связаться с FileZilla для загрузки / скачивания файлов?

Это сообщение об ошибке означает, что вам не удалось пройти аутентификацию.

Это общие причины, которые могут вызвать это:

1. Попытка соединиться с неправильным ключом. Вы уверены, что этот экземпляр использует эту пару ключей?
2. Попытка подключиться с неправильным именем пользователя. ubuntuэто имя пользователя для дистрибутива AWS на основе Ubuntu, но на некоторых других это ec2-user(или adminна некоторых Debian, согласно ответу Богдана Кульбиды) (также может быть root,fedora смотрите ниже)
3. Попытка подключить не тот хост. Это тот хост, на который вы пытаетесь войти?

Обратите внимание, что 1.это также произойдет, если вы испортили /home/<username>/.ssh/authorized_keysфайл в своем экземпляре EC2.

О 2., информация о том, какое имя пользователя вы должны использовать, часто отсутствует в описании изображения AMI. Но некоторые из них можно найти в документации по AWS EC2, пункт с маркировкой4. : http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

Используйте команду ssh для подключения к экземпляру. Вы зададите файл с закрытым ключом (.pem) и имя_пользователя @ public_dns_name. Для Amazon Linux имя пользователя - ec2-user. Для RHEL5 имя пользователя - root или ec2-user . Для Ubuntu имя пользователя - Ubuntu . Для Fedora имя пользователя - fedora или ec2-user . Для SUSE Linux имя пользователя - root . В противном случае, если ec2-пользователь и root не работают, обратитесь к поставщику AMI.

Наконец , имейте в виду, что существует множество других причин, по которым аутентификация не удалась. SSH обычно довольно ясно говорит о том, что пошло не так, если вы хотите добавить -vопцию в вашу команду SSH и прочитать вывод, как объяснялось во многих других ответах на этот вопрос.

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

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

Вы можете выполнить следующие действия:

1. Доступ к консоли управления AWS
2. открыто эластичный бобовый стебель Tab
3. Выберите ваше приложение из всех приложений вкладке «
4. С левой стороны выберите Конфигурация».
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>

Другая возможная причина этой ошибки:

Когда домашний каталог пользователя доступен для записи в группе пользователя доступен для , пользователь не может войти в систему.

(Воспроизводится на экземпляре 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 сбрасывает хост через непреднамеренные глобальные настройки, как показано ниже. Первая строка Host не должна была быть комментарием.

$ 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), то новый экземпляр будет принимать только тот же ключ, который использовался экземпляром А. Это вполне понятно, но это сбивает с толку, потому что во время пошагового процесса создания нового экземпляра вас просят выбрать или создать ключ (на самом последнем шаге), который не будет работать.

Независимо от того, какой ключ вы создали или выбрали, новый экземпляр будет принят только тот ключ, который вы использовали, например, 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 конвертируются по PuTTYgen из файла PEM .

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

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. В документации AWS упоминался пользователь ec2-user, но у меня как-то не работает.

Мой закрытый ключ был установлен на разрешение 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> Он выдаст ошибку и даст вам доступное имя пользователя . затем войдите с этим пользователем.

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

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

Но был другой пользователь :

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

У меня была та же ошибка, но другая ситуация. для меня это случилось совершенно неожиданно после того, как я смог успешно подключиться к удаленному компьютеру. после долгих поисков решения моей проблемы были разрешения на доступ к файлам. это, конечно, странно, потому что я не менял никаких разрешений на своем компьютере или удаленном, принадлежащем файлам / каталогам 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.pem

Правильно: SSH ec2-user @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

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

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

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

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

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