Дозвіл відмовлено (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, але на деяких інших це ec2-user(або adminна деяких Debians, згідно з відповіддю Богдана Кульбіда в) (також може бути root, fedoraдивіться нижче)
3. Спроба підключити неправильний хост. Це правильний хост, в який ви намагаєтесь увійти?

Зауважте, що 1.це теж станеться, якщо ви переплутали /home/<username>/.ssh/authorized_keysфайл у своєму екземплярі EC2.

Щодо того 2., інформації про те, яке саме ім'я користувача слід використовувати, часто не вистачає в описі зображення AMI. Але їх можна знайти в документації AWS EC2, точка 4.: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInsancesLinux.html

Використовуйте команду ssh для підключення до екземпляра. Ви вкажете файл приватного ключа (.pem) та ім'я користувача @ public_dns_name. Для Amazon Linux ім'я користувача ec2-користувач. Для RHEL5 ім'я користувача є root або ec2-користувачем . Для Ubuntu ім'я користувача - ubuntu . Для Fedora ім'я користувача є fedora або ec2-користувач . Для SUSE Linux ім'я користувача є root . В іншому випадку, якщо користувач ec2 та root не працюють, зверніться до свого постачальника послуг AMI.

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

У цьому випадку проблема виникає внаслідок втраченої пари Key. Про це:

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

Ви можете виконати наступні дії:

1. Доступ до консолі управління AWS
2. Відкрити вкладку Elastic Beanstalk
3. Виберіть свою програму на вкладці " Усі програми"
4. Меню зліваù виберіть Конфігурація
5. Клацніть на інстанції Gear
6. У серверній формі перевірте вхід EC2 Key Pair і виберіть свою нову пару ключів. Можливо, вам доведеться оновити список, щоб побачити нову створену пару ключів.
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 мені довелося встановити ім'я користувача як опцію

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 config поточного користувача (~ / .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, які обидва є вільним рівнем.

Кожен раз, коли я запускаю екземпляр, у мене в дозволі відмовляється з'являтися. Я ще не перевірив цього, але моя теорія полягає в тому, що сервер не повністю налаштований до того, як я спробую ввійти в нього. Після кількох спроб з дозволом відмовлено, я зачекаю кілька хвилин, а потім можу підключитися. Якщо у вас є ця проблема, я пропоную почекати п'ять хвилин і спробувати ще раз.

Ось можливий розчаровуючий сценарій, який спричиняє цю помилку:

Якщо ви обідаєте новий екземпляр з AMI, який ви створили з іншого екземпляра (скажімо, екземпляр xyz), то новий екземпляр прийме лише той самий ключ, що і екземпляр A. Це цілком зрозуміло, але це стає заплутаним, оскільки під час поетапного процесу створення нового екземпляра вас просять вибрати або створити ключ (на самому останньому кроці), який не працюватиме.

Незалежно від ключа, який ви створюєте або вибираєте, новим екземпляром буде прийнятий лише той ключ, який ви використовували, наприклад, XYZ.

Я також боровся з цим певний час, поки не виявив наступне:

eb ssh

Коли ви використовуєте це з каталогу проектів, bingo-bango no muss no fos, ви входите

У моєму випадку я зробив наступне:

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

У мене була така ж проблема, і вона вирішилася після того, як я змінив ім'я користувача на ubuntu. У документах AWS згадувався користувач ec2-користувач, але якимось чином не працює для мене.

Мій приватний ключ був встановлений на дозвіл, 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-користувача, 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. тож з хорошого вікі архіванулікса тут:

Для локальної машини зробіть це:

$ 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-користувач @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

Мені вдалося SSH з однієї машини, але не з іншої. Виявляється, я використовував неправильний приватний ключ.

Я зрозумів це, отримавши відкритий ключ із мого приватного ключа, наприклад:

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

Те, що вийшло, не відповідало тому, що було в ~/.ssh/authorized_keysінстанції EC2.

Усі вищезазначені відповіді вище є точними і повинні працювати у більшості випадків. У випадку, якщо вони не такі, як було в моєму випадку, я просто позбувся свого ~/.ssh/known_hostsфайлу на машині, з якої я намагався схилити Ssh, і це вирішило для мене проблему. Після цього я зміг підключитися.