kerberos credential cache filename with sshd causing problems for long running jobs

[Jason Keltz]

Hi.

I have a question about Kerberos credential caches with sshd and long 
running compute jobs.

If a user logs into our central SSH server, a kerberos credential cache 
is created in /tmp/krb5cc_<uid> as would be expected.

A user can run kinit -R before their 10 hour ticket expiry, up until the 
7 day hard expiry.  It all works the way I would expect.

However, users don't run their compute jobs on the central ssh server.  
They ssh from there to a variety of compute servers. This is where the 
problem occurs.

When the user SSHes to the compute server, the SSHd stores the 
credential cache at /tmp/krb5cc_<uid>_<randomchars> instead of just 
/tmp/krb5cc_<uid>.

As far as I can tell, there's no option to tell SSHd to just use 
/tmp/krb5cc_<uid>.

This creates various problems:

If, after sshing to the compute server, the user starts their compute 
job in the background, then logs out, even if their ticket would still 
have been valid for 10 hours, they soon thereafter lose access to their 
Kerberos NFS home directory because sshd deletes the credential cache 
when they log out.

I could potentially resolve this problem by configuring SSHD to *not* 
clean the credential cache on logout.  However, that creates a new 
problem because now the credential cache files will stay around forever 
(unless I clean them up manually).

If the user wants to say, run a cron/at job that will just run "kinit 
-R" periodically on the compute server to extend their ticket up to 7 
days, this won't work because kinit -R is going to renew the cache in 
/tmp/krb5cc_<uid>, and not /tmp/krb5cc_<uid>_<randomchars> unless the 
user explicitly specifies the cache file location (which will be 
different for each ssh session they start).

In addition, if the user wants to run a really long job, and that job 
will run for longer than 7 days, I can instruct the user to create a 
keytab file, then pass that to kinit periodically via cron, but I'll 
have the same problem -- they would have to specify the full path to 
their credential cache because kinit would otherwise assume the default 
location of /tmp/krb5cc_<uid>.

It all seems very complicated.

I assume that the reason that SSHd creates the sshd credential cache in 
/tmp/krb5cc_<uid>_<randomchars> is so that an ssh session will not share 
the same credential cache with say, a local workstation login.  I could 
imagine a case where you log out of the local workstation, thereby 
destroying your credential cache, but this stops a job running on the 
same workstation via ssh session which is using the same credential cache.

Let's assume that the user won't be logging into the local workstation 
and will only connect via SSH.  Would it be reasonable for me to 
manually copy /tmp/krb5cc_<uid>_<randomchars> to /tmp/krb5cc_<uid> when 
required, then change KRB5CCNAME to point to /tmp/krb5cc_<uid> instead 
of /tmp/krb5cc_<uid>_<randomchars> so that things just work? This way, 
sshd can delete it's cache as required on logout, and the user can 
continue to easily run their compute job (albeit being careful about 
local workstation login versus remote ssh login to the same machine).  
I'm surprised such an option doesn't exist in SSH to tell the daemon not 
to insert the randomchars, but I may be missing the point which is why 
I'm asking for clarification.

I know there are other mechanisms for credential cache.  In my case, 
those won't work on my current installation.

Any thoughts? Thanks for any information you can provide...

Jason.