TGT Forwarding and cleanup

Kerberos provides single sign-on. However, if you don’t take care, you will end up having to do a kinit on a remote machine. Not a big deal, but the TGT on the remote machine will not necessarily be cleaned up when you log out.

If you are used to ssh Key forwarding, you might be pleased to know that Kerberos provides a similar option: ssh -K will forward your ticket when you ssh in to the remote machine, and, more importantly, will remove it and related service tickets from the credentials cache when you log out.

[ayoung@ayoung530 stack]$ ssh -K ipa.cloudlab.freeipa.org
Last login: Wed May 28 17:23:29 2014 from vpn-60-114.rdu2.redhat.com
-sh-4.2$ klist
Ticket cache: FILE:/tmp/krb5cc_1387400001_Z9Vo1UZcbc
Default principal: ayoung@IPA.CLOUDLAB.FREEIPA.ORG

Valid starting       Expires              Service principal
05/28/2014 17:23:55  05/29/2014 17:05:19  krbtgt/IPA.CLOUDLAB.FREEIPA.ORG@IPA.CLOUDLAB.FREEIPA.ORG
-sh-4.2$ exit
logout
Connection to ipa.cloudlab.freeipa.org closed.
[ayoung@ayoung530 stack]$ ssh ipa.cloudlab.freeipa.org
Last login: Wed May 28 17:23:57 2014 from vpn-60-114.rdu2.redhat.com
-sh-4.2$ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1387400001)
-sh-4.2$ 

This behavior can be set as the default with the ssh config option: GSSAPIDelegateCredentials

[ayoung@ayoung530 stack]$ cat ~/.ssh/config 

Host *.cloudlab.freeipa.org
     GSSAPIDelegateCredentials  yes

[ayoung@ayoung530 stack]$ ssh ipa.cloudlab.freeipa.org
Last login: Wed May 28 17:19:20 2014 from vpn-60-114.rdu2.redhat.com
-sh-4.2$ klist
Ticket cache: FILE:/tmp/krb5cc_1387400001_Ca685gumJQ
Default principal: ayoung@IPA.CLOUDLAB.FREEIPA.ORG

Valid starting       Expires              Service principal
05/28/2014 17:21:14  05/29/2014 17:05:19  krbtgt/IPA.CLOUDLAB.FREEIPA.ORG@IPA.CLOUDLAB.FREEIPA.ORG
-sh-4.2$

2 thoughts on “TGT Forwarding and cleanup

  1. Thank you for this timely note.

    May I note that a login through gdm will also not clean-up the credential cache. A subsequent login through ssh will use the cached tickets. I observed that an ssh login did not auto mount the NFS /home file system until a gdm session had been initiated.

    Re-running the test with your information shows that while ssh -K will create and destroy the credential cache (as shown by klist), a subsequent ssh without the -K option will auto mount the NFS /home directory as if a ticket were available for NFS but klist shows there is no credential cache.

    I do not know whether I misunderstand what should be happening or if there is a problem.

  2. Dean, I’m not an NFS guru, but I do know that some wonky things go on with it. Is it possible that the /home subdir was never unmounted? I’d ask in freenode #freeipa.

Leave a Reply

Your email address will not be published. Required fields are marked *