☰

У authorized_keys есть мой ключ, но он все равно отклонен

tag-icon • tag-icon ssh authentication public-key
У authorized_keys есть мой ключ, но он все равно отклонен

Я подключаюсь с машины M1 к машине M2 с помощью ssh (к тому же пользователю на другой машине). Я также должен упомянуть, что пользователь использует один и тот же ключ на обеих машинах. С аутентификацией по паролю все работает отлично; с аутентификацией по открытому ключу все работает отлично; я убедился, что ~/.ssh/authorized_keysна M2 ключ RSA является авторизованным, но все равно - ssh возвращается к аутентификации по паролю. Я получаю следующее с ssh -vvv:

debug2: key: /home/joeuser/.ssh/id_rsa (0x7f42679e8200),
debug2: key: /home/joeuser/.ssh/id_dsa ((nil)),
debug2: key: /home/joeuser/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/joeuser/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/joeuser/.ssh/id_dsa
debug3: no such identity: /home/joeuser/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/joeuser/.ssh/id_ecdsa
debug3: no such identity: /home/joeuser/.ssh/id_ecdsa: No such file or directory
debug2: we did not send a packet, disable method

Я должен упомянуть, что яявляюсьвозможность подключения с использованием аутентификации по открытому ключу с других машин (не с тем же ключом).

Каковы потенциальные причины сбоя аутентификации на основе ключей в этом случае?

Примечание: на обеих машинах установлена ​​ОС SLES (SuSE Linux Enterprise Server) 11.

решение1

Вы поступили правильно, используя ssh -vvvклиент, связав его с sshd в режиме отладки, вот так:

второй экземпляр сервера: # /usr/sbin/sshd -p 1234 -dddd

выделенный клиент для подключения: $ ssh -i .ssh/id_rsa-admuser admuser@server -p 1234 -vvvv

В моем случае оказалось, что важная информация была напечатана только на клиенте. Сервер прошел через

debug2: user_key_allowed: check options...
debug2: user_key_allowed: advance ...
debug2: key not found

а клиент придумал вот это:

debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa-admuser RSA SHA256:<censored> explicit agent
debug1: send_pubkey_test: no mutual signature algorithm

Так что же здесь происходило?

Сервер был настолько старым, что они не могли договориться о вспомогательном алгоритме; ключ также былдатированный, но в целом нормально.

Какой сейчас будет основной подход?

  1. запустить выделенный сервер на другом порту
  2. подключиться от клиента в новом сеансе
  3. сравните обмен ключами с обеих сторон, шаг за шагом
  4. проверить результаты с помощью вновь созданной второй пары ключей

В этом конкретном примере было четкое объяснение, что это был небезопасный старый метод, который устарел, т.е. описан здесь. https://confluence.atlassian.com/bitbucketserverkb/ssh-rsa-key-rejected-with-message-no-mutual-signature-algorithm-1026057701.html

Чтобы обновить этот старый ящик, я мог подключиться, добавив -o PubkeyAcceptedKeyTypes=+ssh-rsaв командную строку ssh на клиенте.

решение2

Проверьте основы:

  1. id_rsa и id_rsa.pub существуют как на M1, так и на M2
  2. id_rsa имеет разрешение 600 (т.е. только владелец может читать и писать) как на M1, так и на M2
  3. Файл authorized_keys содержит ключ, вставленный в виде одной строки (без переноса строки)
  4. Разрешение authorized_keys — 600
  5. Обычно разрешение на мою папку .ssh — 600 (по умолчанию)
  6. Проверьте права доступа к каждой папке /home вплоть до .ssh
  7. Я знаю, что вы хотите использовать RSA, но попробуйте ключ DSA и посмотрите, работает ли он. Если работает, то мы обнулим конфигурацию SSH и RSA.

решение3

Ошибка, которую вы получаете:

/home/joeuser/.ssh/id_dsa: No such file or directory

Убедитесь, что этот файл существует, содержит закрытый ключ, соответствующий открытому ключу, который вы добавили, принадлежит пользователю joeuserи имеет 600разрешения:

sudo chown joeuser /home/joeuser/.ssh/id_dsa
sudo chmod 600 /home/joeuser/.ssh/id_dsa

Вам также следует попытаться явно определить закрытый ключ следующим образом:

ssh -i ~/.ssh/id_rsa [email protected]

Если вы не уверены, что это правильный ключ, я бы рекомендовал создать новую пару ключей RSA.

ssh-keygen -b 4096

и добавьте содержимое открытого ключа ~/.ssh/id_rsa.pubв файл authorized_keys удаленного сервера. Убедитесь, что вы не перезаписали существующий закрытый ключ, который вам все еще нужен для входа на другие серверы!

Связанный контент