Kerberos token status at login or in prompt?

[klauer]

• I forget to run kinit or aklog -d and try to do something on AFS and it fails
• Or tokens expire and I start getting permission errors, leaving me scratching my head

It might be neat if we:

1. Show kerberos token status reminders for interactive logins
2. Additionally (or in place of 1) we could show token status in PS1 by default

[ZLLentz]

It might even be safe to automatically run aklog in the bashrc- not sure if that makes a slowdown. From experience I've noticed that the kinit command isn't necessary on a fresh login, just on terminals that have been open for a long time.

I like the idea of showing kerberos status automatically- even if it's just like a "warning: your kerberos token has expired" or as you say a PS1 notice that it's not initialized correctly. On the NFS servers you should typically have 2 non-expired kerberos tokens, I think one for the passwordless login and one for AFS.

[klauer]

Checking speeds: klist gives a quick response: real 0m0.027s

I think the automatic kinit/aklog could be fine but potentially annoying when you're not ready for it.

Note to self or anyone else reading this issue: the next time you have an expired token, please list the output of klist in this issue so we can make a tool that warns you.

[ZLLentz]

From a fresh login:

zlentz@psbuild-rhel7-01:~$ time klist
Ticket cache: FILE:/tmp/krb5cc_14059_QTGCHA
Default principal: zlentz@SLAC.STANFORD.EDU

Valid starting       Expires              Service principal
06/14/2022 16:00:18  06/15/2022 17:00:16  krbtgt/SLAC.STANFORD.EDU@SLAC.STANFORD.EDU

real    0m0.018s
user    0m0.002s
sys     0m0.004s
zlentz@psbuild-rhel7-01:~$ time aklog

real    0m2.041s
user    0m0.005s
sys     0m0.011s
zlentz@psbuild-rhel7-01:~$ time klist
Ticket cache: FILE:/tmp/krb5cc_14059_QTGCHA
Default principal: zlentz@SLAC.STANFORD.EDU

Valid starting       Expires              Service principal
06/14/2022 16:00:18  06/15/2022 17:00:16  krbtgt/SLAC.STANFORD.EDU@SLAC.STANFORD.EDU
06/14/2022 16:01:55  06/15/2022 17:00:16  afs/slac.stanford.edu@SLAC.STANFORD.EDU

real    0m0.004s
user    0m0.001s
sys     0m0.003s

[klauer]

2 seconds for an aklog call is long enough to fall in the annoying territory for me. We could make it a configuration option "auto-login" or "just warn about expired tokens".

When the tokens expire, I think the message becomes something else, doesn't it? I hope it isn't just an expired date in the past...

[ZLLentz]

I'll open a tmux and we'll check klist in 24h

[ZLLentz]

Actually that doesn't work- my old tmux from last week updated with my new kerberos tokens
I'll leave it open regardless and see if something changes

[ZLLentz]

The tmux klist seems to get more complicated over time, including references to all the hosts I visited today while debugging gateway stuff. The afs token disappeared.

[ZLLentz]

One practical implementation would be to run klist and search for a token matching afs/slac.stanford.edu@SLAC.STANFORD.EDU, since that's the one that most commonly trips people up. If there isn't an afs token then you can't write to afs.

[ZLLentz]

Last data point from me before I stop doing this, same tmux session as before. Again, it has the servers I logged onto this morning and some other renewed tokens.

[klauer]

Thanks @ZLLentz! I think the above is probably sufficient to implement the feature when I (or someone interested in giving this a try) gets around to it.

[klauer]

Just saw this today - Kerberos token-wise, expired tokens are still listed. Meaning grep is insufficient here:

Valid starting       Expires              Service principal
07/01/2022 12:17:36  07/02/2022 13:17:32  krbtgt/SLAC.STANFORD.EDU@SLAC.STANFORD.EDU
07/01/2022 12:18:43  07/02/2022 12:18:43  krbtgt/PCDSN@SLAC.STANFORD.EDU

[ZLLentz]

Interesting: I wonder why in some cases the expired token is listed and others they are not. Perhaps I would have seen expired tokens in my session except they had already been renewed, replacing the original line?

[ZLLentz]

Here's a one-liner I found that runs kinit at login if needed, seems to work (small sample size so far). If it keeps working well for me I'll submit it as a commented-out line in a PR.

klist -s >/dev/null 2>&1 || kinit

klist -s sets the exit status based on whether or not there are expired tokens. It doesn't normally have any stdout but I think it can have stderr so I just redirect it. The kinit here gets evaluated only if the command has a nonzero exit status.

In my bashrc I am running the above if (and only if) I'm on a psbuild host, followed by my cron_aklog script that runs aklog on psbuild and on pscron (on pscron I have a cron job that needs kerberos auth, and it only works if I kinit "somewhere" and ssh/aklog there). A modified version of this might be useful in the shared dotfiles as well, pending the auto kinit working properly. Note that this runs aklog in the background which I'm not entirely sure is kosher but it does mean I don't have to wait on an aklog on login. Some more usage testing needed but it seems promising.

if [[ "${HOSTNAME}" =~ "psbuild-rhel7" ]]; then
  # kinit if it needs to be done, this is kind of annoying but it is helpful
  klist -s >/dev/null 2>&1 || kinit
  # Run aklog automatically for me
  ( ~/bin/cron_aklog >/dev/null & )
fi

$ cat ~/bin/cron_aklog
#!/bin/bash
aklog && ssh pscron aklog

So it might turn out that this snippit could be pretty good for the dotfiles:

# Uncomment this block if you want to ensure kerberos tickets on login
# Kerberos tickets are used for afs file permissions, for pushing to afs epics git repos for example
# if [[ "${HOSTNAME}" =~ "psbuild-rhel7" ]]; then
#   # kinit if it needs to be done, this is kind of annoying but it is helpful
#   klist -s >/dev/null 2>&1 || kinit
#   # Run aklog automatically
#   ( aklog > /dev/null & )
# fi

Maybe it could be improved as well (echo statements? aklog only if kinit succeeds?)