Obtaining tickets
The kinit command obtains the master Kerberos ticket that you use
to get tickets for other services. kinit creates a "ticket cache"
on your local system that stores all of your Kerberos tickets. If your
local username is different than your SUNet ID, you will need to tell
kinit your SUNet ID:
kinit sunetid
klist shows you all of your tickets and tells you when they will
expire. You can use klist to confirm that you have tickets and to
see what tickets Kerberos has obtained while using other services.
If you use AFS to store your files on a UNIX system, you will need to get
an AFS token after getting a Kerberos ticket. An AFS token is a Kerberos
ticket for the AFS service, stored in the kernel file system layer. Run
aklog after running kinit to obtain an AFS token and store
it in the right place.
The tokens command will show you your current AFS tokens and when
they expire.
(Note: Stanford historically made local modifications to
kinit so that it would automatically obtain AFS tokens. These
modifications are non-standard, however, and aren't present in the
Kerberos programs that come with current operating systems. Stanford is
moving away from maintaining local modifications to Kerberos and towards
using stock Kerberos programs. You should get used to running
aklog to get AFS tokens, even if it isn't currently necessary.)
Finally, kdestroy destroys your Kerberos ticket cache and
unlog destroys your AFS tokens. You need to run both to remove all
of your credentials from the system.
Logging on with ssh
Once you have Kerberos tickets, you can use Kerberos to log on to other UNIX systems if you have a Kerberos-aware ssh client and server. The version of ssh that comes with major Linux distributions and Solaris 10 is Kerberos-aware.
First, ensure that your home directory contains a .k5login file.
That file should be a single line, listing your Stanford Kerberos
identity. You can create that file with:
echo sunetid@stanford.edu > ~/.k5login
replacing sunetid with your SUNet ID. If you use an AFS home
directory. such a file is automatically created for you when your account
is created. If your account is older, you may have to create it and make
sure that it is world-readable. The following commands will work if you
have a world-readable public directory (one is created by default):
cd ~
echo sunetid@stanford.edu > public/.k5login
rm -f .k5login
ln -s public/.k5login .k5login
Once that's set up, you need to enable GSSAPI authentication in your ssh
client. (GSSAPI is an authentication protocol that ssh uses to support
Kerberos.) Many distributions enable this by default. You can usually
tell by looking in /etc/ssh/ssh_config. Check whether
GSSAPIAuthentication is set to yes.
If it is not set by default on your system, create a file named
~/.ssh/config and add:
Host *
GSSAPIAuthentication yes
to that file. This will attempt GSSAPI authentication to any host to
which you connect if the Stanford Kerberos servers know about this host,
but will fall back to other authentication mechanisms if Kerberos doesn't
work. You can also now use scp and sftp to copy files
between systems.
The above will only use Kerberos to authenticate. It won't forward your
Kerberos tickets to the remote system. That means that if you want to use
a service on that remote system, such as AFS, you won't be able to. If
you trust that system to protect your identity, you can also forward your
Kerberos identity to the remote system. Add a stanza like this to your
~/.ssh/config file:
Host host
GSSAPIDelegateCredentials yes
Replace host with exactly what you type on the ssh command line. (In other words, don't add ".stanford.edu" unless you type the host with ".stanford.edu" on the end.)
You should only enable this for hosts that you trust to protect your Kerberos tickets. You should not enable this for all hosts, since unlike authentication, this forwards your secure Kerberos tickets to the remote system, which is not safe if that system is compromised.
Logging on with rlogin/rsh
SSH is the most widely used way of logging on to UNIX systems these days, but Kerberos also provides versions of rsh and rlogin that use Kerberos. These are much simpler programs than SSH with far fewer options. However, they don't require the configuration that SSH requires.
If you want to use rlogin or rsh, first set up a .k5login file as
explained above.
Then, to log on to a system with rlogin, run:
rlogin -x system
The -x flag says to use encryption and should always be used. To
run a command on the remote system, use:
rsh -x system command
Similarly, you can use rcp -x to copy files (rcp just uses rsh
under the hood).
If your local username is different from your username on the remote
system, pass the -l username option to rlogin or rsh.
As with SSH, by default your Kerberos tickets will not be forwarded to the
remote system. If you trust the remote system and want to use services
that use Kerberos from it, you can forward your Kerberos tickets. To do
this, add the -f flag to the rlogin or rsh command. If you want to
forward forwardable tickets (so that you can then forward tickets from
that host to another), use -F instead of -f.
Be aware that rlogin and rsh do not work entirely correctly with load-balanced names, such as the timeshare cluster names. You may receive errors when connecting to the load-balanced name because rlogin or rsh will get tickets for one host and then try to connect to a different host due to the load-balancing. You can work around this by connecting directly to one of the underlying hosts. To find the current best host, run:
host system
It will tell you which system the load-balanced name is currently an alias for, and you can then connect directly to it. We hope to fix this bug in rlogin and rsh at some point in the future.
Note: Stanford used to provide wrappers called klogin and
krsh that supported Kerberos v4 as well as Kerberos v5 and adjusted
for deficiencies in Kerberos v4. Kerberos v4 is now obsolete, and those
wrappers are therefore no longer required. However, they still do DNS
canonicalization which works around the rlogin and rsh bug mentioned
above, so you may want t
