Miscellaneous Kerberos Topics for the User
Intended for:
Kerberos users and system administrators.
Scenario/Use case:
This article describes the following common operations that work differently in the Fermilab Kerberized environment:
- Running Xwindows.
- Setting up automated processes.
- Sending data from unstrengthened machines to strengthened machines.
- Accessing CVS.
Instructions:
Running Xwindows
UNIX/Linux
Typically, a process on a remote kerberized host isn't automatically given access to your local X display (as it is when you use ssh). There are a few solutions to this. One is to use the kerberized OpenSSH; in particular using the -Y option for a trusted X11 forwarding back to your client. This is the Fermilab supported method for X forwarding.
Go to your remote system and edit "/etc/ssh/sshd_config" file:
# vi /etc/ssh/sshd_config
Add/modify following line:
[...] X11Forwarding yes
Windows
Information on forwarding Xwindows to Windows client systems is pending further work including a recommendation on a Xserver for Windows to be paired with PuTTY.
Macintosh
Fermilab recommends using ssh on the Macintosh for forwarding X-windows (same as for Linux).
Automated Processes
Specific-User Processes (cron Jobs)
The kcron package is provided for setting up cron jobs in a Kerberized environment. It gets installed automatically as part of Scientific Linux Fermi by the RPM package krb5-fermi-addons. This is no longer available with CentOS 8. kcroninit creates the necessary cron principal and keytab file so that cron jobs may be authenticated under the user's principal. kcroninit can be used on each node where cron jobs need to be authenticated, for example for remote access to other Kerberos systems.
To configure a cron job, follow this procedure:
- First, create the cron principal and keytab file. You will need to enter your Kerberos principal and password, so you must be on a secure channel. (The kcroninit program will create the new principal <user>/cron/<host>.<domain>@FNAL.GOV for the current user, host and domain, and will write the corresponding keytab file.) Run the commands:
% kcroninit
- Use the kcron command to initiate the cron jobs in an authenticated manner. Note that you will need to specify the full path to kcron, since this is not normally in your $PATH at the start of a cron job. In the following sample crontab entry, the command /home/files/myjob -(arguments as required by job)is authenticated as <user>/cron/<host>.<domain>@<REALM>:
0 2 * * 0,4 /usr/krb5/bin/kcron /home/files/myjob -xyz
- For access to remote systems, the .k5login file on the remote end must allow access to <user>/cron/<host>.<domain>@FNAL.GOV. If you're just creating this file, don't forget to add your <user>@FNAL.GOV principal, too.
To destroy the principal and keytab file (and prevent authenticated cron jobs from running under your account on this node), run:
% kcrondestroy
Processes Running as root
If you're setting up an automated process such as a cron job, you have to arrange for it to get credentials when it runs. If the process is running as root, it is simplest, both conceptually and practically, to consider that the host on which the job runs is the party responsible for the accesses it initiates, and to have it use the /etc/krb5.keytab to obtain credentials as host/<hostname>.<domain>. To do so, first set the variable KRB5CCNAME, e.g.,:
% KRB5CCNAME=FILE:/tmp/krb5cc_root_$$
Then run kinit:
% /usr/krb5/bin/kinit -k host/<hostname>.<domain>
When you're done, get rid of the tickets:
% /usr/krb5/bin/kdestroy
Alternately, automated root processes can use Special Kerberos Principals to obtain Kerberos credentials.
Non-root, Non-Specific-User Processes
Here are schemes that work for jobs that run neither as root nor as a specific Kerberos user.
Another scheme that is particularly useful for shared accounts that need to run cron jobs with Kerberos credentials is detailed in Create and use a group cron or project Kerberos principal. This builds upon the fact that even user cron principals are just a specific instance of the more general Special Kerberos Principals. In this case, the Special Kerberos Principal that is requested is a cron principal for the non-user account and the /usr/krb5/config/make-cron-keytab (only in SL7) script creates the keytab file so that the kcron utility can be used in this account's cron job just as for a normal Kerberos user's cron job.
Special Kerberos Principal Name Requirements
Special Kerberos principals are compound principal names consisting of 3 fields separated by slashes ("/"). The last (third) field is always a fully qualified domain name (FQDN) such as fiddlesticks.fnal.gov. The second or middle field is the group or project or experiment name. The first field is then a username or a jobname as defined by the user. Some examples of Special Kerberos Principal names are thus nagy/cron/fiddlesticks.fnal.gov, tissue/cd/abby.fnal.gov, enstore/cd/rip4.fnal.gov, acnet/bd/cns72pc.fnal.gov and archiver/minos/minos-offline2.minos-soudan.org.
Using a Special Kerberos Principal in Running a Task
In all your scripts, include a kinit command as follows:
% kinit -k -t /path/to/keytab/file <special-principal-name>
This must occur in the script before the script initiates a network access. (If the hostname is properly set to the full domain name, you could just use `hostname` in the last argument.)