In the past, the way to authenticate in AFS was a command called klog (or klog.krb). When we switched our authentication mechanism to kerberos5, we announced that klog would become deprecated.
Over time we have convinced most users to employ the kerberos5 command "kinit" and the number of klogs has decreased a lot. However, we still see a tail of klog usage, which we would like to bring to zero.
We have identified five main ways that klog is being used today.
1. Users typing klog because they always obtained/refreshed their CERN AFS tokens in this way. On centrally maintained machines we already provide a wrap-up around klog, reminding users that klog is deprecated and kinit should be used instead.
2. Users who have to use klog to get AFS tokens for other, external AFS cells. This will continue to work. For example, the wrapper described above does not interfere with such requests.
3. Users requesting a CERN AFS token from outside CERN. There are ways to achieve the same result with kerberos5's kinit.
4. Users who save their password on some local disk and use "klog –pipe" to automatically obtain an AFS token within some script. For such users a replacement is already available and we encourage them to move to kinit as soon as possible.
5. People using an old unmaintained script "reauth" to get their token automatically refreshed. We are providing a replacement (k5reauth) with improved capabilities.
How do you replace klog?
For case 1, habit: it is clear that kinit can be used instead even if things are not as well integrated as they were in the klog times. Two commands are needed: kinit then aklog. So, to help people, CERN distributions of Linux provide /usr/sue/bin/kinit, a script available on the top of the search path, which packages the two commands together.
For case 2, external cells: until the target external site moves to kerberos5, the following command:
klog –cell xxxx user
continues to work. This is the only case where a user is invited to type klog.
For case 3, remote klog into CERN: the author can successfully create a replacement based on kerberos5 at some remote site (e.g. in2p3.fr). The setup is as follows:
• Have a kerberos5 client installed (generally comes preinstalled in all modern Linuxes, but with a default configuration describing a non-existing EXAMPLE.COM realm).
• Have "aklog" installed (this comes out of openAFS distribution). At worst, copy it locally.
• Have a "good" krb5.conf file, describing the CERN.CH realm. If this is not distributed system-wide in /etc/krb5.conf, then get a copy from any CERN lxplus node and save it locally.
• Create a two-line script, which runs:
kinit user@CERN.CH
aklog -c cern.ch -k CERN.CH
Watch out for the order (-c before -k).
• If you run with a local copy of krb5.conf, add a first line to the script above:
KRB5_CONFIG=local path to krb5.conf; export KRB5_CONFIG
For case 4, saved password: you can simply replace:
cat file | klog -pipe
with:
cat file | /usr/sue/bin/kinit
or alternatively:
klog -pipe < i>file
with:
/usr/sue/bin/kinit < i>file
However, keeping a plain text password is not safe and is strongly discouraged. Kerberos5 offers a similar but slightly safer solution called a keytab. A keytab contains a one-way encrypted copy of the user's password, which kinit can understand, but that cannot be used anywhere else. Getting hold of someone's keytab can do lots of damage, as in the saved password case, but at least it cannot be used to visit EDH or NICE.
When user nopc3 wants to create a keytab for their account on their local machine, they have to run (assuming AFS and the arc command are installed):
arc –h afskrb5m kas ext nopc3 > safe_local_file
chmod 600 safe_local_file
Then user nopc3 can replace on their local machine:
klog –pipe nopc3 < i>local_password_store
with:
/usr/sue/bin/kinit –k –t safe_local_file nopc3
But remember that a keytab must never be exposed to thieves. So the safe_local_file must be readable only by the user.
For case 5, reauth: we are providing a replacement called k5reauth. This script works differently from the old reauth. It used to be started from a shell as a disconnected child, which was then "forgotten". It is not uncommon to see several copies of reauth refreshing a token on an lxplus node, which is now useless because the "token owner" has logged off days before.
We designed k5reauth to start a sub-process and watch it. When the child process terminates, k5reauth stops. The started process could be a shell, so it could be left running until the user logs off. k5reauth also accepts keytabs, so it could be used in cron jobs.
At the time of reading, this utility should already be available on SLC machines.