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.

Suppose I have four computers, Laptop, Server1, Server2, Kerberos server:

  • I log in using PuTTY or SSH from L to S1, giving my username / password
  • From S1 I then SSH to S2. No password is needed as Kerberos authenticates me

Describe all the important SSH and KRB5 protocol exchanges: "L sends username to S1", "K sends ... to S1" etc.

(This question is intended to be community-edited; please improve it for the non-expert reader.)

share|improve this question
add comment

migrated from superuser.com Nov 10 '11 at 20:24

This question came from our site for computer enthusiasts and power users.

2 Answers

up vote 6 down vote accepted

First login:

  • L sends username and SSH authentication request to S1
  • S1 returns available SSH authentication mechanisms, with "password" as one of them
  • L picks "password" and sends the plain password to S1
  • S1 gives username and password to PAM stack.
  • On S1, PAM (usually pam_krb5 or pam_sss) requests a TGT (ticket-granting ticket) from the Kerberos KDC.
    1. S1 obtains a TGT.
      • Old style (without preauth): S1 sends a TGS-REQ and receives a TGS-REP containing the TGT.
      • New style (with preauth): S1 uses your password to encrypt the current time stamp, and attaches it to the TGS-REQ. The server decrypts the timestamp and verifies that it is within the allowed time skew; if decryption fails, the password is immediately rejected. Otherwise, a TGT is returned in the TGS-REP.
    2. S1 attempts to decrypt the TGT using a key generated from your password. If the decryption succeeds, the password is accepted as correct.
    3. The TGT is stored to a newly created credential cache. (You can inspect the $KRB5CCNAME environment variable to find the ccache, or use klist to list its contents.)
  • S1 uses PAM to perform authorization checks (configuration-dependent) and open the session.
    • If pam_krb5 is called in authorization stage, it checks whether ~/.k5login exists. If it does, it must list the client Kerberos principal. Otherwise, the only allowed principal is username@DEFAULT-REALM.

Second login:

  • S1 sends username and SSH authn request to S2
  • S2 returns available auth mechs, one of them being "gssapi-with-mic" 1
  • S1 generates an "AP-REQ" (authentication request) and sends it to S2.
    • To do this, S1 requests a service ticket for host/s2.example.com@EXAMPLE.COM from the Kerberos KDC.
  • S2 attempts to decrypt the request. If it succeeds, authentication is done. (PAM is not used for authentication.)
    • Other protocols such as LDAP may choose to encrypt further data transmission with a "session key" that was included with the request; however, SSH has already negotiated its own encryption layer.
  • If authentication succeeds, S2 uses PAM to perform authorization checks and open the session, same as S1.
  • If credential forwarding was enabled and the TGT has the "forwardable" flag, then S1 requests a copy of the user's TGT (with the "forwarded" flag set) and sends it to S2, where it gets stored to a new ccache. This allows recursive Kerberos-authenticated logins.

Note that you can obtain TGTs locally as well. On Linux, you can do this using kinit, then connect using ssh -K. For Windows, if you are logged in to a Windows AD domain, Windows does that for you; otherwise, MIT Kerberos can be used. PuTTY 0.61 supports using both Windows (SSPI) and MIT (GSSAPI), although you must enable forwarding (delegation) manually.

--

1 gssapi-keyex is also possible but was not accepted into official OpenSSH.

share|improve this answer
    
Could you elaborate on the relationship between the password, TGT, and response from the KDC? It's not clear how PAM decides whether the password is correct. –  Phil Nov 11 '11 at 13:13
    
@Phil: Updated. See step 2 under the TGT obtaining process. –  grawity Nov 11 '11 at 13:54
add comment

The only non-obvious step here would be that there is a PAM module on S1 that used your credentials to perform a kinit and gets you a ticket granting ticket from K (client authentication). Then, when you SSH to S2 using Kerberos authentication, an client service authentication takes place. I don't see the benefit of going through all the tedious exchanges message by message.

Throw a -vvv on your ssh command if you want to see every message and read the Wikipedia description of Kerberos.

share|improve this answer
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.