Отказано в доступе (открытый ключ)

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

два идентичных сервера. Вошел в систему как "Боб".

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

разрешение отклонено (publickey).

на обоих серверах:

rm -r ~/.ssh

на server1:

ssh-keygen
ssh bob@server2

разрешение отклонено (publickey).

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

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

разрешение отклонено (publickey).

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

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

21
задан pulsarjune
05.04.2023 16:11 Количество просмотров материала 2925
Распечатать страницу

1 ответ

на обоих серверах:

rm -r ~/.ssh

на сервере server1:

ssh-keygen
ssh bob@server2

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

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

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


Хорошо, давайте заставим его использовать пароль:

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

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

использовать authentenableication пароль, вы должны сначала разрешить оно в сервере /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.

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

просмотрите также весь файл sshd_config. Это могло бы быть настроено для поиска authorized_keys в совершенно другом, нестандартном местоположении.

0
отвечен grawity 2023-04-06 23:59

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх