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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)