Introduction
Fermilab tries to use kerberos for all authentication whenever possible. Fermilab's
policies on kerberos can be found at
In pursuit of all authentication being kerberized Fermilab has released it's own
flavor of Kerberos. It is basically MIT's
Kerberos with a few tweaks that were wanted here. The main improvement is that
Fermilab's kerberos allows you to use a 'cryptocard' to authorize yourself.
The cryptocard allows you to use 'one time' passwords, and so you may
authenticate yourself from a non-kerberized machine.
Fermilab's kerberos is compatible with MIT's kerberos. It is not
necessary for a linux machine to use Fermilab's kerberos to log into the Fermilab realm.
Fermilab's kerberos can also be installed alongside MIT's kerberos. In the various
Fermi Linux distributions, we install both MIT's kerberos and Fermilab's kerberos. They
are in two different directories (/usr/kerberos and /usr/krb5). We simply put Fermilab's
kerberos in your path.
Fermilab's Kerberos RPM's
KERBEROS
krb5-libs-fermi
krb5-workstation-fermi
The binaries and man pages from the kerberos product.
These get installed in /usr/krb5.
It doesn't do any configuration. But krb5-workstation-fermi
does put /usr/krb5/bin in your path.
krb5-fermi-krb5.conf
This rpm gives you are krb5.conf file setup to work with the FNAL.GOV
kerberos realm. If you already have a krb5.conf, it saves the old one off.
krb5-fermi-config
This does the configuration that you need to be fully kerberized. It edits
your krb5.conf, services, and sshd_config. It will also edit your
config files in xinetd.d.
Each of these configurations are a scripts that is stored in /usr/krb5/config/ for if you want to
re-do one or all of them.
It also has a script called 'makehostkeys' This script is used to create your
host or ftp principle. This script must be run by hand after you get a host principle
password by filling out
The above rpm's are available at
You will need to go into the appropriate directory for your linux release and get the rpm's.
The rpm's that end in current.rpm are links to the latest stable releases of the rpm's. At times there might
be several versions of some of these rpm's. When you don't know which one to get, get the current.rpm.
OPENSSH
We have patched openssh to work with our kerberos, and cryptocards. It is compatible with other versions
of openssh (and ssh v1) that work with kerberos and the gssapi ticket passing protocol.
Many people see that our version of openssh is version 3.5, and think that it does not have the latest
security patches associated with later versions of openssh. Our version HAS been patched with all latest
security patches. It is up to date with all the latest security updates as of this writting.
Our version of openssh is available at
Note: The openssh-3.5p1f11 rpm's have been tested and work on RedHat 7.1, 7.2, 7.3, 8.0, 9, RHEL 3,
RHEL 4, Mandrake 8.x, 9.x, 10.x, Fedora Core 1, 2, 3, Fermi Linux 7.3.x, 9.0.x, LTS 3.0.x, Scientific Linux
3.0.x. They have not been tested on anything Debian based, or SUSE. If you try them and find that they do
work on them, let us know.
Fermilab's Kerberos Config Files
The kerberos config file usually is at /etc/krb5.conf
The kerberized openssh config file is usually at /etc/ssh/sshd_config
(before openafs 3.9)
Setup - Basic Steps
There are two ways you can have kerberos configured. You can have your machine configured to be Outbound Only,
or you can configure it to be both Outbound and Inbound.
If you are only going to be logging into other machines, and noone
is supposed to log into your machine over the network, this
is considered an Outbound Only setup. This is the common setup of
laptop's, because most people expect their laptops to travel, and
their IP address to change all the time, and basically noone should be
logging into them.
If you plan on people logging into your machine over the network using kerberos, then you need to follow the sets for Outbound
and Inbound setup. This is usually for machines that are servers, or desktops that people log into.
Outbound Only
- Get kerberos on your machine.
Most modern linux distributions have kerberos, and most all of them work with Fermi's kerberos. You can use MIT's
kerberos, Hemdal's kerberos, the kerberos that came with your distribution. Most any of them will work.
I personally install Fermilab's kerberos from rpm's, on all my non-Fermi Linux distributions I am running. It goes
in it's own directory, so it isn't stepping on anyone's toes, and I have found that it works the best behind NAT's.
Just remember that while all of them work together ... not all of them have the same command line arguments.
- Get kerberized openssh, that uses gssapi protocol, on your machine
Not all ssh's that say they are kerberized, will work when trying to connect to a Fermi kerberized box. It has to
be able to use the gssapi protocol, otherwise it will not be able to trade kerberos tickets correctly.
We have been collecting various versions of openssh that have the gssapi patch's in our contrib area. You can check
and see if your distribution has a version there. It is at
- Put the Fermi settings in your krb5.conf.
You can do this by installing one of the config rpm's listed above, or useing one of the above config files. Or if
you are bound to several kerberos realms, you can edit your krb5.conf and just put the important stuff from our config
files, into your config files.
The default area for a krb5.conf file is /etc/krb5.conf
Outbound and Inbound
- Get kerberos on your machine.
Most modern linux distributions have kerberos, and most all of them work with Fermi's kerberos. You can use MIT's
kerberos, Hemdal's kerberos, the kerberos that came with your distribution. Most any of them will work.
I personally install Fermilab's kerberos from rpm's, on all my non-Fermi Linux distributions I am running. It goes
in it's own directory, so it isn't stepping on anyone's toes, and I have found that it works the best behind NAT's.
If you plan on letting people log into your machine with a Cryptocard, you must have Fermi's Kerberos installed and
being uses as the servers.
Just remember that while all of them work together ... not all of them have the same command line arguments.
- Get kerberized openssh, that uses gssapi protocol, on your machine
Not all ssh's that say they are kerberized, will work when trying to connect to a Fermi kerberized box. It has to
be able to use the gssapi protocol, otherwise it will not be able to trade kerberos tickets correctly.
We have been collecting various versions of openssh that have the gssapi patch's in our contrib area. You can check
and see if your distribution has a version there. It is at
If you plan on letting people log into your machine with a Cryptocard, you must have Fermi's openssh installed and
being uses as the openssh server.
- Put the Fermi settings in your krb5.conf.
You can do this by installing one of the config rpm's listed above, or useing one of the above config files. Or if
you are bound to several kerberos realms, you can edit your krb5.conf and just put the important stuff from our config
files, into your config files.
The default area for a krb5.conf file is /etc/krb5.conf
- Kerberize your openssh deamon config file.
The easiest way is to just replace your sshd_config file with the one shown above.
The default area for a sshd_config file is /etc/ssh/sshd_config
Setup - Fermi Linux
Fermi Linux 7.3.x
Outbound Only
Nothing. Fermi Linux 7.3.x comes kerberized out of the box with Fermi Kerberos already installed and properly configured.
Outbound and Inbound
- Get a host principal password
- /usr/krb5/config/makehostkeys ( use password from previous step )
- Get the openssh server rpm if it isn't already installed
yum install openssh-server
Scientific Linux Fermi 3.0.x (LTS 3.0.x)
Outbound Only
Nothing. SL-Fermi 3.0.x (which includes
LTS 3.0.x) comes kerberized out of the box with Fermi Kerberos already
installed and properly configured.
Outbound and Inbound
- Get a host principal password
- /usr/krb5/config/makehostkeys ( use password from previous step )
- Get the openssh server rpm if it isn't already installed
yum install openssh-server
Setup - Scientific Linux
Scientific Linux 3.0.x and RHEL 3
Outbound Only
- Optional: Install Fermilab's kerberos
This is optional because RedHat's kerberos works just fine.
I have found that Fermilab's kerberos works better behind
NAT's than RedHat's default kerberos.
You do not have to remove RedHat's kerberos to install Fermilab's. They live in different directories and can both be on
the machine with no side affects.
rpm -Uvh
ftp://linux.fnal.gov/linux/contrib/kerberos/lts3x/krb5-libs-fermi-current.rpm
rpm -Uvh
ftp://linux.fnal.gov/linux/contrib/kerberos/lts3x/krb5-workstation-fermi-current.rpm
- Configure your krb5.conf in either of the following ways
- Install a kerberized openssh that does gssapi authentication
- mkdir openssh
- cd openssh
- lftp ftp://linux.fnal.gov/linux/contrib/openssh/sl30x/
cd to your appropriate arch, usually 'cd i386'
mget *.rpm
quit - rpm -Fvh openssh*.rpm
Outbound and Inbound
Note: Inbound kerberos connections can be handled with RedHat's kerberos. The only difference is that you will not have
Cryptocard support. If you want Cryptocard support, or you just want your machine to be like a SL-Fermi machine, do the
instructions that start with Cryptocard:.
- Cryptocard: Install Fermilab's kerberos
You do not have to remove RedHat's kerberos to install Fermilab's. They live in different directories and can both be on
the machine with no side affects.
rpm -Uvh
ftp://linux.fnal.gov/linux/contrib/kerberos/lts3x/krb5-libs-fermi-current.rpm
rpm -Uvh
ftp://linux.fnal.gov/linux/contrib/kerberos/lts3x/krb5-workstation-fermi-current.rpm
- Configure your krb5.conf in either of the following ways
- By Hand
Edit /etc/krb5.conf to look like either of the following
- By RPM
Cryptocard:rpm -Uvh ftp://linux.fnal.gov/linux/contrib/kerberos/lts3x/krb5-fermi-config-current.rpm
or
rpm -Uvh ftp://linux.fnal.gov/linux/contrib/kerberos/sl30x/krb5-fermi-krb5.conf-current.rpm
- Install a kerberized openssh that does gssapi authentication
- mkdir openssh
- cd openssh
- lftp ftp://linux.fnal.gov/linux/contrib/openssh/sl30x/
cd to your appropriate arch, usually 'cd i386'
mget *.rpm
quit - rpm -Fvh openssh*.rpm
OR
Cryptocard:- mkdir openssh
- cd openssh
- lftp ftp://linux.fnal.gov/linux/contrib/openssh/rh7x/
mget *.rpm
quit - rpm -Fvh openssh*.rpm
- edit /etc/yum.d/yum.cron.excludes
add openssh* to the end of the line
- edit /etc/yum.conf
add exclude=openssh* up in the [main] section
- Get a host principal password
- This is the one step, where installing Fermilab's kerberos makes things easier.
Cryptocard:/usr/krb5/config/makehostkeys ( use password from previous step )
OR
kadmin -r FNAL.GOV -p host/{full.host.name}@FNAL.GOV -w {password} -q "ktadd host/{full.host.name}@FNAL.GOV"
Where {full.host.name} is the full name for the computer. Basically what you put down on the form in the previous step.
And {password} is the password sent to you in the previous step.
Setup - Generic Linux
Fedora Core 2
Outbound only: So that you can log into fermilab and it's computers, but you don't expect anyone to log into your machine.
- become root, and do all the following as root
- rpm -Uvh ftp://linux.fnal.gov/linux/contrib/kerberos/fedora/krb5-fermi-krb5.conf-current.rpm
- mkdir openssh
- cd openssh
- lftp ftp://linux.fnal.gov/linux/contrib/openssh/fedora2/
mget *.rpm
quit - rpm -Fvh openssh*.rpm
Log In and Out: So that other people can log into your machine.
NOT DONE YET
SuSE 9.2
Sent in by Juerg Beringer
Outbound only: So that you can log into fermilab and it's computers, but you don't expect anyone to log into your machine.
The SuSE 9.2 DVD comes with Heimdal Kerberos (0.6.2-8) and
OpenSSH (3.9p1-3). The former works fine for Fermilab, but I couldn't
get the latter to work (OpenSHH 3.9 uses a newer version of GSSAPI that is not backwards compatible).
I downloaded and installed your rpms (using --force --nodeps)
openssh-askpass-3.5p1f11-4rh7x
openssh-clients-3.5p1f11-4rh7x
openssh-server-3.5p1f11-4rh7x
openssh-3.5p1f11-4rh7x
Because the RH and SuSE startup scripts are different and in different
locations, I kept the original SuSE sshd startup script (/etc/init.d/sshd)
and set YaST to ignore any conflicts.
With this everything seems to work fine.
If you have any comments or questions please write to
who is the maintainer of
this page.
December 22, 2004
阅读(891) | 评论(0) | 转发(0) |
