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.)


3 Answers 3


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 an AS-REQ and receives a AS-REP containing the TGT.
      • New style (with preauth): S1 uses your password to encrypt the current time stamp, and attaches it to the AS-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 AS-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 requests a ticket for host/s2.example.com@EXAMPLE.COM, by sending a TGS-REQ with the TGT to the KDC, and receiving a TGS-REP with the service ticket from it.
  • S1 generates an "AP-REQ" (authentication request) and sends it to S2.
  • 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.

  • 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.
    – PhilR
    Nov 11, 2011 at 13:13
  • 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, 2014 at 2:03
  • 1
    Recent versions of OpenSSH have key exchange. I think 4.2p1 was the first version to have the patches. (sxw.org.uk/computing/patches/openssh.html)
    – quinnr
    Feb 10, 2017 at 20:48
  • No they don't. Those are third-party patches. That's what I meant by "not accepted into official OpenSSH"
    – user1686
    Feb 10, 2017 at 21:31

To put the long story short: ideally, Kerberos tickets should be obtained on your terminal (L), either with kinit command or as part of the local login sequence in a so-called "single sign-on" setup. The remote systems (S1, S2) would then be accessible without password prompts. A chained access (L→S1→S2) would be possible by employing a technique known as "ticket forwarding". Such a setup requires, in particular, the KDC to be directly accessible from the terminal (L).

The other answer by grawity explains this approach in details.


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.

  • 3
    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, 2014 at 2:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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