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

James Ralston <[email protected]>
Newsgroups gmane.comp.encryption.kerberos.general
Message-ID <CAEkxbZugmAiayYhLnP4DX3wPJESrxxqsbt=GGxCuu9mL_fD3yQ@mail.gmail.com>
On Wed, Jul 7, 2021 at 8:20 PM Jason Keltz <[email protected]> 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.
________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.