Вопрос: Почему я получаю «Permission denied (publickey)» при попытке SSH от локального Ubuntu до сервера Amazon EC2?


У меня есть экземпляр приложения, работающего в облаке на экземпляре Amazon EC2, и мне нужно подключить его из моего локального Ubuntu. Он отлично работает на одном из местных ubuntu и ноутбуков. Я получил сообщение «Permission denied (publickey)» при попытке доступа к SSH к EC2 на другом локальном Ubuntu. Это так странно для меня.

Я думаю, что некоторые проблемы с настройками безопасности на Amazon EC2, которые имеют ограниченный доступ к IP-адресам для одного экземпляра или сертификата, возможно, нуждаются в регенерации.

Кто-нибудь знает решение?


209
2017-07-13 07:38


Источник


«Раньше это работало» - до какие? - womble♦
У меня есть экземпляр EC2 из эластичного бобового стежка. По состоянию на август 2013 г. решение заключалось в том, чтобы получить доступ к экземпляру в качестве пользователя ec2-пользователя, из-за которого ошибка отказа от разрешения (publicKey) исчезла. Виз: ssh -i ./mike-key-pairoregon.pem ec2-user@ec2-some-address.us-west-2.compute.amazonaws.com. Конечно, у вас есть все остальные вещи в соответствии с stackoverflow.com/questions/4742478/... - mikemay
Вы получаете эту проблему, если указали неправильное имя пользователя. Документы aws (docs.aws.amazon.com/AWSEC2/latest/UserGuide/...) в настоящее время приводят пример с именем пользователя ec2-user [ssh -i /path/my-key-pair.pem ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com], тогда как мой ( old) ubuntu имеет имя пользователя ubuntu, поэтому, когда я использовал этот пример, я получил эту ошибку, изменив правильное имя пользователя. - david.barkhuizen
@ david.barkhuizen, ваш комментарий помог мне. У меня была аналогичная проблема; оказалось, что это связано с именем пользователя. Благодарю. - NaijaProgrammer


Ответы:


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

В своем обновлении к вашему вопросу вы указываете «на другом локальном Ubuntu». Вы скопировали секретный ключ ssh на другой компьютер?


139
2017-07-13 07:44



Я скопировал секретный ключ ssh на другую машину, как предположил @Greg. Он работает сейчас. Благодаря! - Vorleak Chy
FYI вы можете использовать флаг -i, чтобы указать на путь ключей без их установки - Jorge Vargas
В моем случае я использовал bitnami .ami и не понимал, что вам нужно войти в систему, как пользователь, называемый битнами, например: ssh -i <keyfile> bitname@<ec2-address>, К сожалению, -v вариант не помог мне найти это, но все же очень полезно проверить! - Matt Connolly
ну, в моем случае я использовал неправильное имя пользователя. использовал «ubuntu» вместо «битнами». вот так: ssh -i key.pem bitnami @ hostaddress - Lucas Pottersky
Хорошим результатом является также сам удаленный узел, изучите /var/log/auth.log, иногда вы увидите следующие сообщения: Authentication refused: bad ownership or modes for file /var/lib/jenkins/.ssh/authorized_keys или что-то другое - Jonas Libbrecht


Поскольку это явно не упоминалось, sshd по умолчанию очень строгий по разрешениям для authorized_keys файлы. Так что если authorized_keys является записываемый для любого, кроме пользователя или может быть сделана доступной для записи любым пользователем, кроме пользователя, он откажется от аутентификации (если sshd не настроен с StrictModes no)

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

Это не будет отображаться с ssh -v, он будет отображаться в журналах, испускаемых sshd (обычно помещается в /var/log/secure или /var/log/auth.log, зависит от дистрибутива и syslogd конфигурации).

От человека sshd (8):

 ~/.ssh/authorized_keys
         Lists the public keys (RSA/DSA) that can be used for logging in
         as this user.  The format of this file is described above.  The
         content of the file is not highly sensitive, but the recommended
         permissions are read/write for the user, and not accessible by
         others.

         If this file, the ~/.ssh directory, or the user's home directory
         are writable by other users, then the file could be modified or
         replaced by unauthorized users.  In this case, sshd will not
         allow it to be used unless the StrictModes option has been set to
         “no”.

73
2018-01-05 14:38



Это «можно сделать доступным для записи», это то, что меня достало - wmarbut
FWIW правильные разрешения для файлов ключей - 600 (см. Вот) - Matt Lyons
Да, мой файл .authorized_keys был доступен для записи группой, поэтому он отказался принять. - Aditya M P
Я бил головой о стену! Моя папка пользователя имела неправильные разрешения. Спасибо! - XJones
то же самое касается самой папки ~ / .ssh. вы можете получить следующее сообщение об ошибке: Authentication refused: bad ownership or modes for directory - Yevgeniy M.


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

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


37
2018-04-01 21:51



ssh host -l user такой же как ssh user@host, правильно? - Znarkus
@ Znarkus да, это то же самое. - cregox
Да, это решило мою проблему, вызвав ошибку «Разрешить отказ (publickey)». - Brooks Moses
Это была проблема для меня. Я ожидал, что пользователь «root» будет работать, но я использовал изображение Ubuntu EC2, у которого был пользователь по умолчанию «ubuntu». - Cerin


Я получил это сообщение в новом экземпляре, основанном на AMI Ubuntu. Я использовал параметр -i для предоставления PEM, но он все еще показывал «Permission denied (publickey)».

Моя проблема заключалась в том, что я не использовал правильного пользователя. Запустив ssh с помощью ubuntu @ ec2 ... он работал, как обычно.


19
2017-11-17 16:29



Да ... Я выполнял команду с sudo, поэтому он не работал. - thaddeusmt


Что-то, что легче читать, чем ssh -i (на мой взгляд, конечно), tail -f /var/log/auth.log, Это должно выполняться на сервере, к которому вы пытаетесь подключиться, при попытке подключения. Он будет показывать ошибки в виде обычного текста.

Это помогло мне решить мою проблему:

Пользователь [имя пользователя] из xx.yy.com не разрешен, потому что ни одна из групп пользователя не указана в AllowGroups


16
2018-02-01 14:07



Я думаю, вы имели в виду -v - Tim Tisdall
это журнал сервера. для RHEL / CentOS 7: tail -f /var/log/secure - Gianfranco P.


Проверьте свои / И т.д. / SSH / sshd_config файл. Там найдите строку, в которой говорится:

PasswordAuthentication no

Эта строка должна быть изменена, чтобы сказать «да» вместо «нет». Кроме того, перезапустите сервер sshd.

sudo /etc/init.d/ssh restart

10
2017-12-10 06:15



Это сделает сервер менее безопасным. - Znarkus
Это была проблема, с которой я столкнулся: я хотел настроить учетную запись для другого пользователя, аутентифицируя только паролем. Я также хотел иметь возможность войти в систему как я из тех мест, где у меня не было своего личного ключа. - Daniel
Как мы можем пойти /etc/ssh/sshd_config - если мы даже не можем попасть на сервер? - kyo
Чтобы попасть в сам сервер, вы должны использовать файл PEM, который они выдали, когда вы создали экземпляр. После этого инструкции следуют. - Sudipta Chatterjee


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

Это позволяет отбросить синтаксис типа «-i» в ssh, использовать rsync со стандартными параметрами, а также использовать один и тот же ключ ssh во всех регионах EC2.

Я написал статью об этом процессе:

Загрузка личных ключей ssh ​​в Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys


6
2017-09-29 21:15



+1 Посмотрел этот вопрос именно по этой причине. - John Riselvato
Я вижу эту ошибку в следующей статье. region = $ (ec2-describe-regions | cut -f2) Необходимая опция '-K, --prkey-key KEY' отсутствует (-h для использования) - KashifAli
@KashifAli Вам нужно настроить учетные данные инструмента командной строки API-интерфейса EC2, чтобы вам не всегда приходилось передавать учетные данные в каждой командной строке. - Eric Hammond