• kerberos credential cache filename with sshd causing problems for l

    From James Ralston@21:1/5 to jas@eecs.yorku.ca on Wed Jul 7 21:13:46 2021
    On Wed, Jul 7, 2021 at 8:20 PM Jason Keltz <jas@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.

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