Kerberos ticket not found - KRB5CCNAME not set

[lariks240]

Hi all,

I recently setup a JupyterHub (using default authenticator & spawner). The machine on which JupyterHub is running is setup to check credentials against an AD server and get a ticket from a Kerberos server on login. When I login via ssh a kerberos ticket of the form /tmp/krb5cc_{uid}{random} is created (or refreshed) and the environment variabele KRB5CCNAME is set. Klist shows this credential cache - all works. When I login in JupyterHub a ticket is also created (or refreshed) but no environment variabele KRB5CCNAME is set - so it seems the authencation worked fine, the ticket is there, but can not be found. Apparently, because the KRB5CCNAME is not set: a default /tmp/krb5cc{uid} (without extra random extension is expected).
If I manually set the KRB5CCNAME (via a python notebook eg) to point to the correct ticket everything works as expected.

Any ideas, insights or pointers in the right direction in how to get this fixed (or at least understand what is happening)?

[njwhite]

I've managed to solve this: basically PAM returns the KRB5CCNAME value to Jupyterhub (in my case -- RHEL 7 -- via sssd and pam_sss.so). However, nothing in the Jupyterhub code reads it (from the PAM session) and puts it into the OS environment so kernels can use it. I've raised minrk/pamela#10 to expose the PAM functions that allow you to get PAM environment values - you'll want to make a PAMAuthenticator subclass (like the one in this repo) call pamela.authenticate with close_txn=False from my PR, call get_env("KRB5CCNAME") on the handle it returns and stash the value in os.environ. Finally, don't forget to add KRB5CCNAME to c.Spawner.env_keep in your jupyterhub_config.py so the value gets passed to the per-user jupyter instances (and so on to their kernels).

[Hoeze]

@njwhite Do you have an example config for that? I'd like to use the user's krb5 cache for spawning a singleuser instance: c.SlurmSpawner.exec_prefix = 'ksu {username} -e /usr/bin/env' My intention is to run jupyterhub without root, but still being able to submit slurm jobs as the user.