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

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

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

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

То, что я подразумеваю под «можно сделать доступным для записи», заключается в том, что если какой-либо из родительских каталогов доступен для записи для кого-либо, кроме пользователя, пользователи, которым разрешено изменять эти каталоги, могут начать изменять разрешения таким образом, чтобы они могли изменять /заменять authorized_keys.

Это не будет отображаться с помощью ssh -v, оно будет отображаться в журналах, испускаемых sshd (обычно помещается в /var/log/secure или /var/log/auth.log, зависит от конфигурации distro и /var/log/auth.log).

От человека sshd (8):

syslogd

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

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

Я получил это сообщение в новом экземпляре, основанном на AMI Ubuntu. Я использовал параметр -i для предоставления PEM, но он все еще показывал «Permission denied (publickey)».

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

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

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

  

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

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

PasswordAuthentication no

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

sudo /etc/init.d/ssh restart

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

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

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

  

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

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

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

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

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

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

$ ec2-authorize default -p 22

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

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

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

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

Это редкий случай, но если у вас включен selinux и вы используете nfs для каталога с авторизованными ключами (например, общие домашние каталоги), вам нужно либо отключить 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>