it-swarm.com.ru

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

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

Permission denied (publickey).

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

Дано: 

chmod  600 pem file.

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

ssh -i /home/kashif/serverkey.pem  [email protected]

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

Permission denied (publickey)

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

355
Kashiftufail

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

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

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

589
Thibault D.

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

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

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

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

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

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

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

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

48
Matteo Ceserani

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

ssh -i <key> [email protected]<ec2 ip>
43
Deepti Kohli

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

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

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

chown wellington:wellington key.pem
26
Wellington Lorindo

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

Sudo ssh -i mykey.pem [email protected]<ec2_ip_public_dns>

OR

Sudo ssh -i mykey.pem [email protected]<ec2_ip_public_dns>
23
Abhishek Gupta

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

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

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

22
Stepan

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

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

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

7
Rabinarayan Panigrahi

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

ssh -i pemfile.pem -l ubuntu dns
7
dc10

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

key_parse_private2: missing begin marker 

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

Используя следующее:

ssh -i ~/myKey.pem [email protected]<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

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

5
Ben Paz

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

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

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

ssh -i /path/my-key-pair.pem [email protected]
4
JohnP

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

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

3
Wade Anderson

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

ssh-add -K 

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

2
eiTan LaVi

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

2
Chetabahana

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

chmod 400 <key.pem>

ssh -i <key.pem> [email protected]_public_dns (for debian)

Первоначально я использовал часть [email protected], и я получил эту подсказку:

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

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

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

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

2
Seeker

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

eb ssh

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

2
JedA

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

ssh -i <.pem path> [email protected]

Вы получите сообщение, в котором рекомендуется использовать ec2-user

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

Так что используйте

ssh -i <.pem path> [email protected]

1
Jerome Anthony

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

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

1
Manoj Sahu

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

ssh -i ec2key.pem [email protected]
1
Prajith

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

ssh -i ~/keys/<key_name> [email protected]

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

ssh -i ~/keys/<key_name> [email protected]
1
Andre Araujo

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

1
Elimelech

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

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

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

1
Mehran

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

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

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

1
Greg Bell

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

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

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

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

1
Kuldeep Dangi

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

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

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

0
Tanmay

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

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

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

0
Mike Q

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

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
RNA