Skip to content Skip to site navigation Skip to service navigation

UNIX Kerberos Commands

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 > ~/.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 > 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 "" unless you type the host with "" 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

Last modified March 2, 2010