Por que eu preciso logar no ssh com minha senha uma vez por dia?

Question

Quando eu tento usar o ssh usando uma chave criptografada em ssh-agent, recebo o seguinte (usando 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

Eu consigo logar se eu forçar o uso de uma senha ( ssh -o PreferredAuthentications=keyboard-interactive -o PubkeyAuthentication=no ) e então, depois que eu desconectar (então não é uma coisa do ControlMaster), eu posso usar ssh usando chaves sem um problema:

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 [email protected] 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.

O servidor está usando o Active Directory para armazenar as informações do usuário, então eu suponho que tenha algo a ver com isso, mas eu trabalhei em ambientes onde o AD foi usado com o Linux no passado e não tive esse problema.

    

Answer 1

Sem saber os detalhes específicos de como a máquina está configurada, só posso oferecer uma hipótese. O diretório Microsoft Active é construído sobre o LDAP para informações de usuário / diretório e o Kerberos5 para autenticação / criptografia.

Então, aqui está o núcleo disso. Quando você se autentica no sistema Kerberos, você recebe um ticket. Este ticket são as credenciais criptográficas que o sistema operacional usa em seu nome para identificá-lo na rede, por exemplo. Esses tíquetes geralmente têm um tempo de vida padrão limitado. Meu palpite neste caso é de cerca de 10 horas.

Seu par de chaves ssh não funcionará porque algum componente nesse servidor está configurado de tal forma que ele requeira seu ticket e a emissão de um ticket do kerberos requer sua senha. Uma vez que foi emitido para você (naquela máquina), ele está disponível para qualquer componente configurado dependendo dele. Depois de expirar, você precisa se autenticar para obter um novo.

Estou familiarizado com o uso de pam_krb5 e libnss-ldapd para esse tipo de situação; Eu não estou familiarizado com os outros. Se meu palpite estiver correto, uma vez que você esteja no seu shell, digite 'klist -v' para ver se recebeu um tíquete.

Espero que isso ajude.