У меня есть экземпляр приложения, работающего в облаке на экземпляре Amazon EC2, и мне нужно подключить его из моего локального Ubuntu. Он отлично работает на одном из локальных ubuntu, а также на ноутбуке. Я получил сообщение «Permission denied (publickey)» при попытке доступа SSH к EC2 на другом локальном Ubuntu. Мне это так странно.
Я думаю, что какие-то проблемы с настройками безопасности на Amazon EC2, который имеет ограниченный доступ IP-адресов к одному экземпляру или сертификату, возможно, потребуется восстановить.
Кто-нибудь знает решение?
Первое, что нужно сделать в этой ситуации, - использовать -v возможность ssh, чтобы вы могли видеть, какие типы аутентификации используются и каков результат. Помогает ли это прояснить ситуацию?
В обновлении вашего вопроса вы упоминаете «на другом локальном Ubuntu». Вы скопировали закрытый ключ ssh на другой компьютер?
Как не упоминалось явно, 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
Обратите внимание, что Джейн не владеет .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.) Изящная перезагрузка не приведет к удалению существующих сеансов./var/log/auth.log в дистрибутивах на основе Debian; /var/log/secure на RHEL / CentOS / Scientific.)Намного проще понять, что не так с выводом отладки, который включает ошибки разрешений файловой системы. Не забудьте отменить изменение на /etc/ssh/sshd_config когда готово!
Я получил эту ошибку, потому что забыл добавить -l вариант. Мое локальное имя пользователя не было таким же, как в удаленной системе.
Это не ответ на ваш вопрос, но я пришел сюда в поисках ответа на свою проблему.
Я получил это сообщение на новом экземпляре, основанном на Ubuntu AMI. Я использовал параметр -i для предоставления PEM, но он все еще отображал «Permission denied (publickey)».
Моя проблема заключалась в том, что я использовал неправильного пользователя. Запустив ssh с ubuntu @ ec2 ... он работал нормально.
То, что легче читать, чем ssh -v (на мой взгляд конечно), это tail -f /var/log/auth.log. Это должно быть выполнено на сервере, к которому вы пытаетесь подключиться, при попытке подключения. Он покажет ошибки в виде обычного текста.
Это помогло мне решить мою проблему:
Пользователь [имя пользователя] с xx.yy.com не разрешен, поскольку ни одна из групп пользователей не указана в AllowGroups.
Проверьте свои / и т.д. / SSH / sshd_config файл. Там найдите строку, в которой говорится
PasswordAuthentication no
Эту строку нужно изменить, чтобы она говорила «да», а не «нет». Кроме того, после этого перезапустите сервер sshd.
sudo /etc/init.d/ssh restart
Возможно, это не имеет отношения к текущему плакату, но может помочь другим, кто найдет это при поиске ответов на похожие ситуации. Вместо того, чтобы позволять Amazon генерировать пару ключей ssh, я рекомендую загрузить в Amazon свой собственный стандартный общедоступный ключ ssh по умолчанию и указать его при запуске экземпляра 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. Я делюсь домашним каталогом с помощью NIS / NFS, и я правильно установил все разрешения, но он всегда запрашивал пароль. После того, как я установил StrictModes no, проблема исчезла!
Ответ Грега объясняет, как лучше решить эту проблему, однако реальная проблема заключается в том, что у вас есть ключ ssh, установленный на одной стороне транзакции (клиент), который пытается выполнить аутентификацию с открытым ключом, а не аутентификацию на основе пароля. Поскольку у вас нет соответствующего открытого ключа на экземпляре EC2, это не сработает.
У меня была та же проблема, и после того, как я попробовал множество решений, которые не сработали, я открыл порт SSH на брандмауэре своего маршрутизатора (панель управления брандмауэром моего маршрутизатора в беспорядке, поэтому трудно сказать, что происходит). Во всяком случае, это исправило :)
Супер чертовски раздражает то, что вы получаете ошибку Permission Denied, подразумевая, что было установлено какое-то соединение, grr.
У меня была такая же проблема, хотя я предположительно выполнял все шаги, включая
$ ec2-authorize default -p 22
Однако я запустил свой экземпляр в районе us-west-1. Таким образом, приведенная выше команда также должна указать это.
$ ec2-authorize default -p 22 --region us-west-1
После этой команды я смог подключиться к экземпляру по ssh. Я потратил немного времени, прежде чем осознал проблему, и надеюсь, что этот пост поможет другим.
Это редкий случай, но если у вас включен 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>.
TL; DR - убедитесь, что вы используете правильное имя пользователя - ubuntu / ec2-user / etc.
Я использую бастион-хост (ec2), который представляет собой ОС Amazon Linux, (ec2-user) и попытался перейти с хоста-бастиона на частный хост (ec2), который представляет собой ОС Ubuntu 18.04 (ubuntu)
Это может показаться забавным, поскольку вы должны знать имя пользователя машины, к которой вы подключаетесь по SSH, но поскольку я использую SSH для нескольких машин, иногда я делаю эти ошибки.