Когда я пытаюсь использовать ssh, используя зашифрованный ключ, хранящийся в ssh-agent, я получаю следующее (используя ssh -vvv):
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/cowens/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: BLAH
debug3: sign_and_send_pubkey: RSA BLAH
debug3: input_userauth_banner
Access denied
Access denied
Connection closed by BLAH
Я могу войти, если заставлю его использовать пароль (ssh -o PreferredAuthentications=keyboard-interactive -o PubkeyAuthentication=no), а затем, после отключения (так что это не вещь ControlMaster), я могу без проблем использовать ssh с помощью ключей:
debug1: Offering RSA public key: /home/cowens/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: BLAH
debug3: sign_and_send_pubkey: BLAH
debug1: Authentication succeeded (publickey).
Authenticated to BLAH ([BLAH]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug1: Requesting authentication agent forwarding.
debug2: channel 0: request auth-agent-req@openssh.com confirm 0
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
Сервер использует Active Directory для хранения пользовательской информации, поэтому я предполагаю, что это как-то связано с этим, но я работал в средах, где AD использовался с Linux в прошлом, и у меня не было этой проблемы.
Не зная конкретных деталей того, как устроена машина, я могу предложить вам только гипотезу. Каталог Microsoft Active Directory построен на LDAP для информации о пользователях / каталогах и Kerberos5 для аутентификации / шифрования.
Итак, вот суть. Когда вы аутентифицируетесь в системе Kerberos, вы получаете билет. Этот билет представляет собой криптографические учетные данные, которые операционная система использует от вашего имени, например, для вашей идентификации в сети. Эти билеты обычно имеют ограниченный срок действия по умолчанию. Я предполагаю, что в этом случае около 10 часов.
Ваша пара ключей ssh не будет работать, потому что какой-то компонент на этом сервере настроен так, что для него требуется ваш билет, а для получения билета Kerberos требуется ваш пароль. После того, как он был выдан вам (на этой машине), он доступен для любых настроенных компонентов, в зависимости от него. По истечении срока его действия вам необходимо пройти аутентификацию, чтобы получить новый.
Я знаком с использованием pam_krb5 и libnss-ldapd в таких ситуациях; Я не знаком с остальными. Если мое предположение верно, как только вы окажетесь в своей оболочке, введите «klist -v», чтобы узнать, был ли вам выдан билет.
Надеюсь это поможет.