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

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

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

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

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

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

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

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

Кроме того, если /home/username/.sshкаталог не принадлежит пользователю и, следовательно, у пользователя нет прав на чтение ключа, вы можете столкнуться с проблемами:

drwxr-xr-x 7 jane jane 4096 Jan 22 02:10 /home/jane
drwx------ 2 root root 4096 Jan 22 03:28 /home/jane/.ssh

Обратите внимание, что Джейн не владеет .sshфайлом. Исправить это через

chown -R jane:jane /home/jane/.ssh

Такого рода проблемы с разрешениями файловой системы не будут отображаться ssh -v, и они даже не будут отображаться в журналах sshd (!), Пока вы не установите уровень журнала на DEBUG.

• Редактировать /etc/ssh/sshd_config. Вы хотите строку, которая читает LogLevel DEBUGгде-то там. Перезагрузите сервер SSH, используя механизм, предоставленный дистрибутивом. ( service sshd reloadна RHEL / CentOS / Scientific.) Изящная перезагрузка не удалит существующие сессии.
• Попробуйте авторизоваться снова.
• Определите, куда попадают ваши журналы аутентификации, и прочитайте их. (IIRC, /var/log/auth.logо дистрибутивах на основе Debian; /var/log/secureна RHEL / CentOS / Scientific.)

Намного легче понять, что происходит с выводом отладки, который включает ошибки разрешения файловой системы. Не забудьте отменить изменение, /etc/ssh/sshd_configкогда закончите!

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

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

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

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

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

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

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

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

PasswordAuthentication no

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

sudo /etc/init.d/ssh restart

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

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

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

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

Странно, но моя проблема заключалась в том, что сервер был перезапущен и ему было выдано новое DNS-имя. Я использовал старое имя DNS. Я знаю, это звучит глупо, но мне потребовалось время, чтобы понять это.

Если вы пытаетесь подключиться к телефону CyanogenMod, работающему с Dropbear, вам следует запустить следующие строки, чтобы убедиться, что все права разрешены:

chmod 600 /data/dropbear/.ssh/authorized_keys

или же

chmod 700 /data/dropbear/.ssh/authorized_keys # In case of MacOS X 10.6-10.8

а также

chmod 755 /data/dropbear/ /data/dropbear/.ssh

Это исправило это для меня, иначе ничто не может соединиться.

Если вы используете CentOS 5, вы можете установить StrictModes noв /etc/ssh/sshd_config. Я разделяю / home каталог, используя NIS / NFS, и я правильно установил все разрешения, но он всегда запрашивал у меня пароль. После того, как я установил StrictModes no, проблема исчезла!

В ответе Грега объясняется, как лучше его устранить, однако на самом деле проблема заключается в том, что у вас установлен ключ ssh на одной стороне транзакции (клиент), который пытается выполнить аутентификацию с открытым ключом, а не на основе пароля. Поскольку у вас нет соответствующего открытого ключа в экземпляре EC2, это не сработает.

У меня была та же самая проблема, и после попытки множества решений, которые не работали, я открыл порт SSH на брандмауэре моего маршрутизатора (панель управления брандмауэра моего маршрутизатора - беспорядок, поэтому трудно сказать, что происходит). Во всяком случае, это исправлено :)

Супер кровавый раздражает , что ошибка , которую вы получаете Отказано, подразумевая , что есть какая - то связь сделал, ГРР.

У меня была та же проблема, хотя я, вероятно, следовал за всеми шагами, включая

$ ec2-authorize default -p 22

Тем не менее, я начал свою работу в регионе us-west-1. Таким образом, приведенная выше команда должна также указать это.

$ ec2-authorize default -p 22 --region us-west-1

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

Это редкий случай, но если у вас включен selinux и вы используете nfs для каталога с authorized_keys (например, общие домашние каталоги), вам нужно либо отключить selinux (не рекомендуется по соображениям безопасности, но вы можете временно отключить его). чтобы увидеть, вызывает ли это проблему) или разрешить selinux использовать домашние каталоги nfs. Я не знаю деталей, но у меня это сработало setsebool -P use_nfs_home_dirs 1

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

Я обнаружил, что это было причиной, запустив tail -f /var/log/secureмашину и увидев ошибку Authentication refused: bad ownership or modes for directory /home/<username>.