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.

Another is to use Kerberized rsh and give access with xauth, e.g.,:

% rsh -n -f -x <remote_host>.fnal.gov -l <username> \
  xauth add `xauth list $HOSTNAME:0`
% rsh -n -f -x <remote_host>.fnal.gov -l <username> \
xauth add `xauth list $DISPLAY` 

(Those are backquotes around xauth list $DISPLAY.) Executing a command like this can be made more convenient. You can create an alias or shell script that sends over your xauth magic cookie (or performs an xhost +<remote_node> locally, if you use xhost, but it's considerably less safe -- someone on that host could get access to your screen and keyboard). Run it before starting the connection program. Change the script to mode 755. Here is some sample content for such a script, which we call kxtelnet (it's been tested between Linux, Solaris and IRIX machines):

#!/bin/sh 

if [ $# -gt 2 -o $# -lt 1 ]; then 
  echo "usage: kxtelnet RemoteHostName [RemoteUserName]" 1>&2 
  exit 1 
fi 

host=$1
user=${2:-$USER}

case "$DISPLAY" in 
  :*) disp=`hostname`$DISPLAY;; 
  *)  disp=$DISPLAY;; 
esac 

/usr/krb5/bin/rsh -n -x -l $user $host \
    /bin/sh -c \
      "'PATH=/usr/X11R6/bin:/usr/openwin/bin:/usr/bin/X11:\$PATH; \
        export PATH; \
        xauth add `xauth list $disp`; \
        xauth list $disp'"

exec /usr/krb5/bin/telnet -x -l $user $host

(In the 9th line, :*) disp=`hostname`$DISPLAY;;, those are single backquotes around hostname. Same for xauth list $disp in 3rd to last line.) Instead of a script, you can set up an alias for a command like the following, and run it each time you restart Xwindows, before connecting to the remote host:

% xauth nlist <localnode>:0 | ssh <remotehost> xauth nmerge -
works on some machines and not others, while
% xauth nlist <localnode>:0 | rsh -f -x <remotehost> \
  xauth nmerge -
seems to work on those machines where ssh doesn't appear to work. (Often the failure is due to xauth not being in the default path.) % xauth nlist 
<localnode>:0 | rsh -f -x <remotehost> \
xauth nmerge -

Run this manually rather than with startx so that you can still get into Xwindows if for some reason this fails.

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. 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.

Note that default cron ticket lifetime is picked up from the [ftpd] in /etc/krb5.conf. This is important to know if you want to increase the time limit for a cron job ticket.

For no discernible reason, many systems have been found to have permission 701 on /var/adm, which stops kcroninit from working for any user in the group to which that directory belongs. Make sure this directory is set to mode 711 or 755 before trying kcroninit. A later version will fix this problem automatically when encountered.

To configure a cron job, follow this procedure:

1. 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.GOVfor the current user, host and domain, and will write the corresponding keytab file.) Run the commands:

   % kcroninit
   

2. 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
   

3. 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 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.)

Sending Data from Unstrengthened to Strengthened Machines

Sending data from the strengthened realm to an unstrengthened machine is straightforward via FTP, an r-command or scp.

If the strengthened target machine has a properly configured anonymous incoming FTP directory, an outside process (which can be running on an unstrengthened machine) can deposit data into it. If the target machine is not configured properly, the outside process can send an unauthenticated signal, e.g., an email or some other connection that signals "look for data now", and the strengthened target machine can initiate a pull.

CVS

Different groups may implement CVS differently under Kerberos at Fermilab. Here we discuss the Computing Sector's recommended configuration which is used for its CDCVS repository. This information was distilled from the Linux section of the Fermilab Redmine Wiki.

Fermilab supports Kerberized access to CVS repositories. The Fermilab CDCVS repository uses the cvsuser account. Users must be added to that account's .k5login or .k5users file. On the client side, users can access the CVS repository via ssh (Kerberized but authorized key access is allowed) or Kerberized rsh. So if you have been accessing a repository via (non-Kerberized) rsh, you'll need to convert. If you're using Kerberos rsh as the transport, and if your /etc/krb5.conf [appdefaults] says "forward = true" for rsh (or for all apps), then you have to have a forwardable ticket or create a wrapper script that does "rsh -N".  Fermilab recommends using Kerberized ssh to access CVS repositories.

Older informaton on this configuration and converting to it is documented at http://cdcvs.fnal.gov/connecting.html and http://www.fnal.gov/docs/products/cvs/cvs_ssh.html. Current information can be found at Linux section of the Fermilab Redmine Wiki.  Also information for Kerberized access to CVS for other operating systems and interfaces can be found starting at the Fermilab Redmin Wiki Start page.

See Also:

• Strong Authentication at Fermilab