Why do I have to log into ssh with my password once per day?

Question

When I try to ssh using an encrypted key held in ssh-agent, I get the following (using 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

I can log in if I force it to use a password (ssh -o PreferredAuthentications=keyboard-interactive -o PubkeyAuthentication=no) and then, after I disconnect (so it isn't a ControlMaster thing), I can ssh using keys without a problem:

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.

The server is using Active Directory to store the user information, so I assume it has something to do with that, but I have worked in environments where AD was used with Linux in the past and not had this problem.

Answer 1

Without knowing the specific details of how the machine is set up, I can only offer you a hypothesis. Microsoft Active directory is built on LDAP for user/directory information and Kerberos5 for authentication/encryption.

So, here's the core of it. When you authenticate to the Kerberos system, you get issued a ticket. This ticket is the cryptographic credentials the operating system uses on your behalf to identify you across the network, for example. These tickets typically have a limited default lifetime. My guess in this case is around 10 hours.

Your ssh keypair won't work because some component on that server is configured such that it requires your ticket and getting issued a kerberos ticket requires your password. Once it's been issued to you (on that machine) it's available for whatever configured components are depending on it. Once it has expires, you need to authenticate to get a new one.

I'm familiar with using pam_krb5 and libnss-ldapd for this type of situation; I'm not familiar with the others. If my guess is correct, once you're at your shell, type 'klist -v' to see if you've been issued a ticket.

Hope this helps.