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

[James Ralston]

On Wed, Jul 7, 2021 at 8:20 PM Jason Keltz <jas at eecs.yorku.ca> wrote:

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

The reason why sshd creates the Kerberos file credential cache with
mkstemp() is to avoid race condition attacks, where an attacker
leverages the fact that a user's credential cache file is in a
predictable location to either execute a denial-of-service attack or
steal the victim's credentials.

This is also why there is no option to disable it.

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

Running long jobs that need Kerberos credentials is really a problem
for k5start(1).  Is there a reason why you can't use it?

https://www.eyrie.org/~eagle/software/kstart/k5start.html

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

If you can't use k5start, your effort would probably be best spent in
finding a way to make other credential cache types (e.g.,
KEYRING:persistent: or KCM:) usable on your installation, as the
issues you are encountering with the FILE: cache type are inherent
limitations.