Аутентифікація publickey SSH - сервер приймає ключ, але автентифікація не вдається

5

Я допомагаю другові, який має проблеми з підключенням аутентифікації з відкритим ключем, до сервера, який підтримує мене. Auth із відкритим ключем працює чудово для пари інших користувачів. Звичайно, відкритий ключ мого друга знаходиться в авторизованому_кіс-файлі на сервері.

debug1: Host 'xxxxx' is known and matches the RSA host key.
debug1: Found key in /home/xxx/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/xxx/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: email@address.com
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/xxx/.ssh/id_dsa
debug1: Trying private key: /home/xxx/.ssh/id_ecdsa
debug1: Next authentication method: password

Наступний рядок для мене не має сенсу

Server accepts key: pkalg ssh-rsa blen 279

Оскільки здається, що сервер вважає, що відкритий ключ є абсолютно правильним, то чому він продовжує перевірку паролів замість автентифікації користувача?

ssh public-key

— nip3o
джерело

1

Подумайте про підвищення рівня налагодження. Я думаю, що debug1це найменш багатослівний. ssh -vvv

— Даніель Бек

Влучне зауваження. Однак проблема була вирішена, коли мій фріент видалив усі попередні ssh-ключі та створив новий.

— nip3o

6

Я вважаю, що ви показуєте вихідні дані про журнали / налагодження на стороні клієнта. Я б розглядав журнали на стороні сервера, як це зазвичай дає більш детальну інформацію про те, чому сервер відхилив спробу аутентифікації відкритого ключа.

Наприклад, небезпечні дозволи для домашніх або .ssh-каталогів користувачів.

— RedGrittyBrick
джерело

1

У моїй centosсистемі файл журналу був/var/log/secure

— Джаред Бек,

4

У моєму випадку проблема полягала в тому, що користувач намагався підключитися як root, і у мене був відключений кореневий ssh логін (що, мабуть, повинен зробити кожен). Отже, переконайтеся, що ваш друг намагається підключитися через правильний некористувальний обліковий запис користувача.

— Джефф
джерело

1

Я нещодавно це відчував із інтерфейсом SSH Герріта. Проблема полягала в тому, що мій локальний агент SSH запропонував купу різних ключів на сервер Gerrit, і після деякого обмеження сервер просто відмовився прийняти подальші ключі (але все ж відповів Server accepts key). Я не знаю, чи подібна поведінка характерна для Герріта або загальної речі OpenSSH.

Виправлення полягало в тому, щоб змусити вибрати потрібну клавішу в ~/.ssh/config:

Host gerrit.example.org
  IdentityFile ~/path/to/my_key
  IdentitiesOnly yes

Переконавшись, що ~/path/to/my_key.pubіснує (його можна створити за допомогою ssh-keygen -f ~/path/to/my_key -y > ~/path/to/my_key.pub), ssh агент міг надати ключ, не вводивши повторно фразу, але не надав жодних інших ключів.

— Тгр
джерело