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


355

Я хочу использовать свой экземпляр 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
Что касается вашего второго вопроса, свяжитесь с filezilla для загрузки / скачивания файлов, проверьте это для пошаговых инструкций - y2u.be/e9BDvg42-JI
Yasitha Chinthaka

2
вы уверены, что вы не использовали «sudo chmod 600 pem file», это вызвало бы эту ошибку и означало бы, что вам нужно будет использовать sudo до ssh
felbus

Также для некоторых ОС Debian используется имя пользователя admin. По крайней мере, для версий 6.5 и 7.0.
Разработчик

2
Если ваше имя пользователя ec2-user, убедитесь, что вы не используете ec2_user:)
grisaitis

2
Убедитесь, что пользователь, к которому вы пытаетесь подключиться, имеет ключ, указанный в его / ее $HOME/.ssh/authorized_keys файле.
ILMostro_7

Ответы:


589

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

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

  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 и прочитать вывод, как объяснялось во многих других ответах на этот вопрос.


2
Я не думаю, что интерфейс предлагает вам добавить ключ к работающему экземпляру, поэтому вам придется запустить новый, если вы потеряли ключ к своему работающему экземпляру.
Тибо Д.

81
# 2 исправил мою проблему, спасибо!
Rackehoe

4
Этот ответ решил это для меня. Имя пользователя по умолчанию для этого экземпляра было «ubuntu», а не ec2-user, как сказано в руководстве по AWS. Попробуйте использовать'ec2-user@_your_EC2_IP.amazonaws.com
эдс

7
Что касается # 1, неправильный ключ, добавление -v (многословно) в командную строку ssh показало мне, какие ключи он пытался, и это привело меня к пониманию, что это не тот ключ, который я сгенерировал, потому что я назвал его как-то иначе, чем id_rsa или id_dsa.
KC Baltz

3
«Ubuntu - это имя пользователя для дистрибутива AWS на основе Ubuntu», - вот что меня покорило. Использовался для ec2-пользователя, просто предполагал, что это всегда имя пользователя.
Нейт Рид

48

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

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

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


1
Вторая часть вашего ответа неверна. Вы не можете получить «Отказано в доступе (publickey)». если вы не правильно установили настройки брандмауэра (группы безопасности). «В доступе отказано (publickey)». сообщение об ошибке от SSH и является доказательством правильности конфигурации вашей группы безопасности. Вместо этого вы получили бы «ssh: connect to host xxxx port 22: Отказано в соединении»
Thibault D.

Короче говоря: сообщение об ошибке говорит о том, что эта проблема не имеет никакого отношения к вашей конфигурации групп безопасности.
Тибо Д.

Вы правы. Вторая часть посвящена другому типу проблем. Я исправил пост.
Маттео Чезерани

Если вы потеряли ключ, я думаю, что одним из возможных способов его решения было бы сделать снимок экземпляра, а затем запустить новый с новым ключом. В этом случае Amazon добавляет новый открытый ключ в .ssh / authorized_keys, поэтому обязательно удалите старый. (и будьте осторожны, чтобы не удалить новый, или вы вернулись к своей первой проблеме)
Тибо Д.

43

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

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

1
Мне показалось, что ключом здесь был DNS-адрес хоста против IP. ec2-user @ <ip> работал на меня.
Зак

1
Решение также.
Тпойка

26

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

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

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

chown wellington:wellington key.pem

Работал для меня (пришлось обновить некоторые пакеты после того, как хотя)!
user1429980

4
правильное решение - сначала сменить владельца, а затем подключиться как обычный пользователь. использовать sudo chown wellington:wellington key.pem.
Янус Троелсен

в вашем случае это работает, потому что вы пытаетесь войти в ту виртуальную
машину

Я сделал whoami, затем sudo chown user_name_given_by_whoami xxxx.pem
Чираг Пурохит

23

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

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

ИЛИ

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

1
Это помогло мне. Спасибо за совет! : D
Jehzlau

22

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

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

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


1
+1 Жаль, что я прочитал это 4 часа назад !!! Решил мою проблему, когда rsync -a переписывал разрешение моей папки ec2-user.
Майкл Хоббс

После того, как я просмотрел свой домашний каталог, я не смог войти.
Роберт Мун

Итак, как вы входите в систему на машине, на которую это влияет, и вообще не можете войти на нее?
PKHunter

Исправление прав доступа к каталогу / home у меня тоже работает, спасибо! @AlexPetralia, ваша ссылка не работает = /, но на форуме aws есть сообщение, в котором говорится об этом: forums.aws.amazon.com/message.jspa?messageID=334402
Liko

Может ли кто-то вроде Алекса Петралиа или @Michael Hobbs перепостить (или переформулировать) решение этой проблемы?
Якуб Лангр

7

для экземпляра Ubuntu 12.04 LTS Micro мне пришлось установить имя пользователя в качестве опции

ssh -i pemfile.pem -l ubuntu dns

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

7

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

  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.


5

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

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

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


4

Я забыл добавить имя пользователя (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

Легит новичка, ошибка. Если вы забыли добавить имя пользователя, оно будет использовать имя пользователя, с которым вы вошли на локальном компьютере.
Тибо Д.

3

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

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


Я ждал 5 минут. и это сработало. Я тоже на свободном уровне. спасибо
Эмека Мбах

2

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

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

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


Вау, я никогда не думал об этом. Использование старого ключа решило проблему для меня. Спасибо.
Толгаморф

Обычно он добавляет новый открытый ключ в файл author_keys, что делает его пригодным для использования. Хотя прошло много времени с тех пор, как я проверил, но это то, чего я ожидал
Тибо Д.

2

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

eb ssh

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


2

В моем собственном случае я сделал следующее:

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".

2

Я в Windows с WinSCP . Он отлично работает как в File Explorer, так и в PuTTY SSH Shell для доступа к моему Amazon EC2-VPC Linux. Там нет ничего , чтобы сделать с chmod pem fileкак он использует myfile.ppk конвертируются по PuTTYgen из файла PEM .


2

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

ssh-add -K

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


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


1

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

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

1
Пожалуйста, дайте некоторые детали.
Сайеда Зунайра

1

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

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

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


1

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

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

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


1

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

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

Решение: Sudo chmod 644 <key.pem>

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


1

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

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


1

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

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


1

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

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

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

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

1

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


0

Другая возможная проблема: неверный логин

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

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


0

У меня была похожая ошибка

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

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


0

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

Неправильно: SSH EC2-пользователь @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

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


-1

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

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

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

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


-1

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


Хотя удаление known_hostsможет решить проблему при подключении к серверу, который изменил свой ключ хоста (в любом случае, это плохой подход), я почти уверен, что он не может решить ошибку «Permission denied (publickey)» .
Мартин Прикрыл
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.