В доступе отказано (publickey)

347
user4893295

Это преследовало меня годами.

Два ИДЕНТИЧНЫХ сервера. Вы вошли в оба как «Боб».

Попробуйте ssh с bob @ server1 на bob @ server2.

В доступе отказано (publickey).

На ОБАХ серверах:

rm -r ~/.ssh 

На сервере1:

ssh-keygen ssh bob@server2 

В доступе отказано (publickey).

Итак, давайте заставим его использовать вместо этого пароль:

mv ~/.ssh ~/oldssh ssh bob@server2 

В доступе отказано (publickey).

Я даже пытался поместить содержимое id1rsa.pub сервера server1 в author_keys на server2 и server2 в server1.

Ничего из этого не имеет смысла!

0
Как вы заставили его использовать пароль, если он может быть настроен без аутентификации по паролю в sshd_config? Fanatique 6 лет назад 0

1 ответ на вопрос

0
grawity

На ОБАХ серверах:

rm -r ~/.ssh 

На сервере1:

ssh-keygen ssh bob@server2 

Откуда server2 знает, что он должен принять новый ключ, который вы только что сделали? Это не так. После создания ключа с помощью ssh-keygen вы должны скопировать его в файл server2 ~ / .ssh / authorized_keys.

Я даже пытался поместить содержимое id_rsa.pub сервера server1 в авторизованные ключи на server2

Да, это в основном требуется.


Итак, давайте заставим его использовать вместо этого пароль:

mv ~/.ssh ~/oldssh ssh bob@server2 

В сообщении об ошибке указывается, какие механизмы сервер предлагает вам. В этом случае, поскольку он предлагает толькоpublickey аутентификацию, клиенты не могут заставить его использовать пароль или любой другой метод.

Чтобы использовать аутентификацию с помощью пароля, сначала необходимо разрешить его на сервере /etc/ssh/sshd_config(используя параметры PasswordAuthentication и ChallengeResponseAuthentication).

Как только это будет сделано, вы даже можете использовать, ssh -o PreferredAuthentications=password bob@server2чтобы предпочесть конкретный механизм. Таким образом, вам не нужно будет временно убирать ключи или перемещать их назад.


Это преследовало меня годами.

Похоже, пришло время проверить системные журналы server2. Служба SSH может сообщить вам, почему она отклоняет или игнорирует ваши ключи. Вам понадобится опция sshd_config, LogLevel DEBUGчтобы получить от нее максимум информации.

Все сообщения журнала sshd попадают в журнал безопасности, обычно /var/log/auth.logили /var/log/security, или, по крайней мере, journalctl -bесли используется systemd.

Наиболее распространенная причина заключается в том, что «сломанный» сервер отказывается читать ваш файл author_keys из-за «слишком открытых» прав доступа к файлу. Например, если ~ / .ssh / доступен для записи во всем мире или даже принадлежит другому пользователю, это считается проблемой безопасности и приводит к тому, что sshd игнорирует ваш файл. На Linux используйте, namei -l ~/.ssh/authorized_keysчтобы проверить это.

Просмотрите также весь файл sshd_config. Он может быть настроен на поиск авторизованных ключей в совершенно другом, нестандартном месте.

Похожие вопросы