Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
add comment

1 Answer

up vote 5 down vote accepted

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.

share|improve this answer
    
klist -v produced an error for me, but klist by itself shows two things that started when I logged in and expire 10 hours later, so I am guessing those are the tickets. This is likely the culprit if it requires my password after the expires time. –  Chas. Owens Jan 23 at 17:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.