Take the 2-minute tour ×

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

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


2 Answers 2

up vote 8 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
NOTE: This sentence is incorrect: "S1 sends a TGS-REQ and receives a TGS-REP containing the TGT." Incorrect because TGT's come as part of the AS_REP. A Service Ticket will come back with the TGS_REPn –  jouell May 30 at 2:03
@jouell: Correct it in the post, then –  grawity May 30 at 6:08

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
Answering a question which asks for details with "I don't see the benefit of elaborating on the details" seems quite rude to me. –  Massimo May 30 at 2:13

Your Answer


