it-swarm-ru.tech

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

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

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

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

217
Vorleak Chy

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

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

143
Greg Hewgill

Как явно не упоминалось, 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 когда закончите!

76
Kjetil Joergensen

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

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

37
pkmk

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

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

19
user60587

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

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

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

16
Znarkus

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

PasswordAuthentication no

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

Sudo /etc/init.d/ssh restart
10
Sudipta Chatterjee

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

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

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

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

6
Eric Hammond

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

5
Patrick Collins

Если вы пытаетесь подключиться к телефону 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

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

2
Naftuli Kay

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

2
uichin

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

$ ec2-authorize default -p 22

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

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

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

1
Ajit Verma

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

1
Cian

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

Супер чертовски досадно, что ошибка, которую вы получаете, - Permission Denied, подразумевая, что было установлено какое-то соединение, грр.

1
chichilatte

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

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

0
Jacob Tomlinson

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

0
Reese