Почему я получаю “Разрешение, отклоненное (в открытом ключе)” при попытке к SSH с локальной Ubuntu на сервер Amazon EC2?

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

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

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

Я получил это сообщение на новом экземпляре, базирующемся от AMI Ubuntu. Я использовал-i опцию обеспечить PEM, но это все еще показывало "Разрешение, отклоненное (в открытом ключе)".

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

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

PasswordAuthentication no

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

sudo /etc/init.d/ssh restart

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

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

Обратите внимание, что jane не владеет .ssh файл. Зафиксируйте это через

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

Эти виды проблем разрешения файловой системы не обнаружатся с ssh -v, и они даже не обнаружатся в журналах (!) sshd, пока Вы не установите уровень журнала для ОТЛАДКИ.

• Править /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 при выполнении!

При попытке подключить к телефону CyanogenMod рабочий Dropbear, необходимо выполнить следующие строки, чтобы удостовериться, что все - все permission'd право:

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

Это зафиксировало его для меня, иначе ничто не может соединиться.

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

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

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

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

$ ec2-authorize default -p 22

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

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

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

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

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

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

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

Perhaps not relevant to the current poster, but might help others who find this when searching for answers to similar situations. Instead of letting Amazon generate the ssh keypair, I recommend uploading your own, standard, default public ssh key to Amazon and specifying that when you run an EC2 instance.

This lets you drop the "-i" type syntax in ssh, use rsync with standard options, and also lets you use the same ssh key across all EC2 regions.

I wrote an article about this process here:

Uploading Personal ssh Keys to Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys

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

Я обнаружил, что это причина, запустив tail -f / var / log / secure на машине и обнаружение ошибки В аутентификации отказано: неправильное владение или режимы для каталога / home / .

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

Если ваш каталог .ssh имеет более 1 ключа (например: id_rsa.pub и id_ed25519.pub), попробуйте убедиться, что вы выполняете ssh с , явно добавив его путь в качестве аргумента (и пока вы это делаете, также может явно передать too):

ssh -i ~/.ssh/<correct_key_file> <correct_username>@<host_server_address>

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