Отказано в доступе (открытый ключ). SSH с локального Ubuntu на сервер Amazon EC2

Отказано в доступе (открытый ключ). SSH с локального Ubuntu на сервер Amazon EC2

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

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

Кто-нибудь знает решение ошибки «Отказано в доступе»?

решение1

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

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

решение2

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

решение3

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

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

решение4

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

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

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

Связанный контент