У меня есть экземпляр приложения, работающий в облаке на экземпляре Amazon EC2, и мне нужно подключиться к нему с моего локального Ubuntu. Он отлично работает на одном локальном Ubuntu и также на ноутбуке. Я получил это сообщение, , Permission denied (publickey).
при попытке SSH к EC2 сдругойлокальная Ubuntu.
Я думаю, что могут быть проблемы с настройками безопасности на Amazon EC2, который ограничивает доступ по IP-адресу одним экземпляром; или, возможно, необходимо повторно сгенерировать сертификат.
Кто-нибудь знает решение ошибки «Отказано в доступе»?
решение1
Первое, что нужно сделать в этой ситуации, это использовать опцию -v
to 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