SSH-клиент не предлагает открытый ключ для SSH-сервера
У меня есть два пользователя без полномочий root на одном сервере Linux. Если я устанавливаю SSH-соединение (аутентификация на основе ключа) с одним конкретным SSH-сервером под первым пользователем, то оно преуспевает:
/* debug messages removed for brevity */
debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '.ssh/id_rsa':
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Теперь под вторым пользователем, где я указываю файл закрытого ключа с помощью -i .ssh / SD , аутентификация на основе ключа не выполняется. Все сообщения отладки клиента SSH точно такие же, пока здесь:
/* debug messages removed for brevity */
debug1: Next authentication method: publickey
debug1: Trying private key: .ssh/SD
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '.ssh/SD':
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
Почему клиент SSH во втором случае не предлагает открытый ключ? Это обязательный этап аутентификации на основе ключей, не так ли?
Why doesn't SSH client in second case offer the public key?
Открытый ключ предлагается клиентом, если он существует (т.е. файл существует и находится в той же папке, что и закрытый ключ с тем же именем + ".pub" ).
This is a mandatory step in key-based authentication, isn't it?
Нет, предлагать открытый ключ необязательно. Обязательным является только доказательство того, что клиент владеет закрытым ключом.
Дополнительные пояснения можно найти здесь :https://security.stackexchange.com/a/152638
Чтобы проиллюстрировать оба случая:
- Предложение открытого ключа с последующим подтверждением наличия у клиента закрытого ключа
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: RSA SHA256:3btAL+lsfo8D3Z8PVWLG04j8BqShS2ImfxqwMFPS8BM '.ssh/id_rsa'
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug2: input_userauth_pk_ok: fp SHA256:3btAL+lsfo8D3Z8PVWLG04j8BqShS2ImfxqwMFPS8BM
debug3: sign_and_send_pubkey: RSA SHA256:3btAL+lsfo8D3Z8PVWLG04j8BqShS2ImfxqwMFPS8BM
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
- Только подтвержденный клиент имеет закрытый ключ
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: '.ssh/id_rsa'
debug3: sign_and_send_pubkey: RSA SHA256:3btAL+lsfo8D3Z8PVWLG04j8BqShS2ImfxqwMFPS8BM
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Обратите внимание, что если открытый ключ с именем .ssh/SD.pubсуществует и НЕ связан с закрытым ключом.ssh/SD(из-за предыдущей генерации ключа, например ), соединение не будет установлено. Согласно журналу, предоставленному ОП, здесь это не так, но это проблема, с которой я столкнулся, когда дошел до этого вопроса. В этом случае журнал на стороне клиента выглядит следующим образом (и не содержит явных сведений о том, почему авторизация не удалась):
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:p5eJ+CJ1aRR9xeEcQUDCkbnQ3VUxa8cxjlWUhsYfla4 '.ssh/id_rsa'
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password