OpenSSH and Kerberos / Active Directory authentication problems: Credentials cache permission incorrect / No Credentials Cache found

Douglas E. Engert deengert at
Thu Dec 1 07:48:43 EST 2005

Matthias Gerstner wrote:

>>>Douglas E. Engert wrote:
>>During login using a password, Kerberos should get you two tickets,
>>one it the ticket granting ticket, the other is a service ticket for the local
>>host. The second ticket is need to avoid an attack where a user replaces
>>the network, and the KDC with ther own version then use the password
>>stored in their KDC to login to the host. This attack will not
>>work if the host tries to get the second ticket, as it holds the
>>real key for the host in the krb5.keytab, and can detect a bogus
> Ok, this part sounds okay to me. Is OpenSSH automatically trying to
> receive the service ticket?

Sort of. Either pam_krb5 (if using "ChallangeResponse yes") or sshd
directly with "KerberosAuthentication yes" will use the username and password
to get a ticket granting ticket (TGT). The TGT is then used to get a
service ticket for the host. The host will then verify that it is
encrypted in the key of the host. Both these tickets both wind up in
the ticket cache of the user on the server side.

If you are using Kerberos via gssapi, then things work differently. In
this case the user on the ssh client side already has Kerberos tickets.
They could have been from kinit or login, or a previous sshd doing the
above or below.

The ssh client calls gssapi the uses the user's ticket cache on the client to
get a service ticket for the host then uses this to authenticate to the
host which verifies it against the key of the host. This ticket is cached
in the client's ticket cache. If the client has "GSSAPIDelegateCredentials yes",
the client will request from the KDC a *new* TGT to be usable at the server,
The client will send this to TGT to the sshd server, protected by the session key
contained in the server ticket. The server will then save this new TGT in the user's
ticket cache.

In all these cases the user's ticket cache should be pointed at by the
KRB5CCNAME environment variable. The TGT could then be used for example by the
AFS aklog to get an AFS token (pam_krb5afs, pam_afs2, pam_afs_session can do this)
or the user could start an ssh session with gssapi to some other host later on.

> I wonder that I haven't noticed anything about this topic until now.

The need to verify a host service ticket is well known in the Kerberos
community, and is considered standard practice. The fact that your
pam_krb5 makes this an option is a security risk.

>>I bet that with the pam_krb5 you have not set the validate option
>>or some thing similiar. This option does the above check. On a peronal
>>workstaion, you may be willing to live with the above attack.
>>OpenSSH gets the  service ticket. The man sshd_config states
>>in the kerberosAuthentication sesion that you must have a servtab.
>>Also if you use gssapi for authenticaiton you must have the
>>krb5.keytab or servtab as well.
> Thank you for this information. I've read the man pages of course but
> somehow skipped that important part completely.
>>>>Does the host have a host/<fqdn>@<REALM> principal in the
> Just to get this right:
> Lets say the OpenSSH server's fqdn is
> Then I have to create principal for
> host/ at MYDOMAIN.NET
> on the active directory side and extracting a keytrab entry for this
> principal for use in the krb5.keytab on ossh.
Yes assuming the AD domain name is The realm name is the
upper case of the AD domain.

> If I got this right now then it shouldn't be too hard to get this working.

With AD, you would use the ktpass command to get the keytab. See
Its old, but has all the steps.

> I'll try it as soon as possible.
> Best regards,
> Matthias Gerstner


  Douglas E. Engert  <DEEngert at>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

More information about the openssh-unix-dev mailing list