Accessing the FNAL Kerberos Realm from Nevis

The Computing Division at Fermilab is implementing a strong authentication model for their system security. This impacts how Nevis users connect to Fermilab's computers.

This web page was prepared by Bill Seligman.

Background

The Fermilab Computing Division is phasing in a strong authentication procedure for system security based on Kerberos. Use of this system will be required to access systems at FNAL as of 15-Dec-2000.

Unfortunately, Kerberos is not one of those security schemes that is 100% transparent to the user. If you wish to connect to systems at FNAL, you will have to learn about the following:

Obtaining a Kerberos Principal
Obtaining a Kerberos Ticket
Connecting to a computer at FNAL

Kerberos client software described below has been installed on all the machines on the Nevis Linux cluster.

Obtaining a Kerberos Principal

From the perspective of an individual user, your Kerberos Principal is an ID/password combination that grants you permission to access the Kerberos realm at Fermilab. Note that this is different from a computer account: an account allows you log on to a computer and use it; a principal is needed to even access the computer in the first place.

Fermilab has documented the procedure for obtaining a principal. Basically, you have to go through the Computing Division liaison for your group.

Hopefully, you will only have to do this once.

Obtaining a Kerberos Ticket on Linux systems

The principal is a general permission to ride on the train. To make a specific trip, you have to buy a ticket. You get a Kerberos ticket via the kinit command:

kinit <kerberos-user-id>@FNAL.GOV

Hopefully, your Kerberos user id will the same as your FNAL user id; if it must be different for some reason, the FNAL Computing Division will let you know. For now, you can leave out @FNAL.GOV (which must be in upper case) since that is the only Kerberos realm we access at Nevis; if we ever begin to access others you'll have to type in the realm explicitly.

Connecting to a computer at FNAL from Linux systems

Once you have your ticket, you can go between railway cars as often as you like while the ticket is good. To drop the analogy, you can use "Kerberized" versions of UNIX commands (telnet, ftp, etc.) to access the Fermilab systems for ten hours or until you log off; then you must request a new ticket.

The command you're most likely to want to use is ssh. Unfortunately, there is a substantive difference in the versions of ssh in Fedora Core systems and in the versions required by Fermilab. On "out-of-the-box" Fedora Core systems, when you use ssh to connect to systems at FNAL, you're likely to get a prompt for a Cryptocard response.

Here are the options for dealing with this issue:

You can use a system with the FNAL version of ssh installed. As of Feb-2007, none of the systems on the Linux cluster use the FNAL version of ssh.
You can request that the complete Kerberized version of the OpenSSH package be installed on your system; it's available from FNAL.
Frankly, I'm reluctant to do this. Installing the FNAL versions has proved problematic in the past; their support for Fedora Core-based systems is not good.
You can copy a Kerberized version of ssh into your home area: mkdir -p ~/bin cp ${NevisAppBase}/bin/ssh-kerberized ~/bin/ssh Most users have ~/bin included in their $PATH variable (type echo $PATH to make sure).
You can also use a shell alias, and use the Kerberized ssh directly:
alias ssh="${NevisAppBase}/bin/ssh-kerberized" # sh-style version alias ssh "${NevisAppBase}/bin/ssh-kerberized" # csh-style version
It's conceivable that you'll receive some messages about xauth if you try this. If this happens, let a sysadmin know about it; it means they have to execute the following command on your system:
ln -sf /usr/bin/xauth /usr/X11R6/bin/xauth This is needed because FNAL's Kerberized version of ssh looks in an "old" location for the xauth program. You also use the ssh -x option, which doesn't pass X11 authentication, but that's only of value if you don't want to run X11 applications on the remote system.
For commands such as scp and sftp, use the -S option; for example:
scp -S ${NevisAppBase}/bin/ssh-kerberized my-file.txt remote-system.fnal.gov:
You can also create aliases if you wish:
# sh-style alias alias sftp="sftp -S ~/bin/ssh"
WARNING: The -S option may not work on systems with Fedora core 5 or higher. The problem is that the versions of scp and sftp on those systems use the latest versions of OpenSSH, and pass an option to the remote host (PermitLocalCommand) that FNAL's older ssh versions don't recognize. To work around this issue, only issue scp and sftp commands on systems with older versions of Fedora Core, or copy the files with commands on the FNAL systems:
# On a Nevis system: ssh -x remote-system.fnal.gov "scp riverside.nevis.columbia.edu:/data/myfile.txt ~/data/myfile.txt"
You can also use telnet if you don't plan to use any X-Windows applications. You'll want to include some options: telnet -a -x -F remote-system.fnal.gov To save typing, an alias has been set up: ktelnet = telnet -a -x -F. You can just type: ktelnet remote-system.fnal.gov

Frequently Asked Questions

Are we going to install a Kerberos realm at Nevis?

Not at present; we don't have the same security issues that Fermilab has.

However, Fermilab is still permitting Kerberos connections from "non-trusted" hosts. At some point, they may decide to only permit connections from "trusted" hosts. It is not clear what their definition of a trusted host will be, nor if a Nevis system would be trusted even if we have a Kerberos server. We will have to deal with that situation when it happens.

to the Nevis Computing Page.

to the Nevis Home Page.

Send any comments or questions to the webmaster.