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

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

Попробуйте 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.

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

1 ответ1

0

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

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. Он может быть настроен на поиск авторизованных ключей в совершенно другом, нестандартном месте.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .