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.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)