OPENSSH AND KERBEROS

Recent distributions of the Linux operating system that we use on MathLAN are configured, by default, to impose greater obstacles to system crackers and intruders than older versions did. One specific change is that network services that transmit unencrypted data from one computer to another, such as telnet, ftp, and rsh, are now usually turned off in the default configuration, so as to encourage users to adopt tools that provide greater security.

OpenSSH

The OpenSSH suite of tools constitute one possible replacement for the deprecated services. It includes ssh, which replaces the telnet, rlogin, and rsh programs; scp, which replaces the ``remote-copy'' program rcp; and sftp, which replaces the file-transfer program ftp. The main advantage of the OpenSSH programs is that they encrypt everything that is transmitted from one computer to another. This is, perhaps, especially important when you're typing in a password, but encryption also protects any private information that may be transferred as you run other application programs (an e-mail reader, for instance).

Although you can use OpenSSH to log in from one computer in MathLAN to another, it's mainly intended to make it possible to log in from outside MathLAN -- indeed, from anywhere in the world -- without ever transmitting an unencrypted password over the Internet. Indeed, OpenSSH encrypts your entire login session; it never sends any unencrypted information outside of your local computer.

Setting up

The first preliminary step towards using the OpenSSH tools is to choose a passphrase -- analogous to a password, but with no limit on its length. I recommend choosing a memorable but hard-to-guess phrase with digits and/or punctuation marks in it. Make it something that is not too difficult to type accurately, since you'll be typing it often without visual feedback -- the OpenSSH tools don't display your password on screen as you type it.

Once you have a passphrase in mind, you can create a keypair -- two long, random-looking character strings, called the public key and the private key. The computer that you're trying to log in on selects a ``challenge'' number, encrypts it using your public key, and sends the result back to the computer on which you're already logged in. This computer uses your private key to decrypt the challenge number and returns the decrypted, thus confirming that you are who you claim to be, since no one else has access to your private key.

To create the keypair, open a terminal emulator (click on the footprint-on-monitor icon on the front panel at the bottom of the screen) and type

ssh-keygen -t dsa

at the prompt. You'll be asked to specify the file in which the private key should be stored; it's best to accept the default location by simply pressing <Enter>:

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/spelvin/.ssh/id_dsa): 
Created directory '/home/spelvin/.ssh'.

The keys will be stored in separate files in the .ssh subdirectory of your home directory. The file id_dsa will contain your private key and id_dsa.pub your public key. Obviously, the authentication method described above doesn't really confirm your identity if someone else knows what your private key is, so it is essential to make sure that no one else can read or copy the file containing it (~/.ssh/id_dsa).

Next, you'll be asked to type in your passphrase, twice. (Remember that it doesn't show up on screen, so type carefully.)

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/spelvin/.ssh/id_dsa.
Your public key has been saved in /home/spelvin/.ssh/id_dsa.pub.
The key fingerprint is:
cf:99:da:74:36:5e:b4:c0:a8:de:b1:f0:25:3a:d3:16
$

The key fingerprint is a kind of checksum for the public key; if you record it, you can confirm later on that your public key hasn't changed. The command

ssh-keygen -l -f ~/.ssh/id_dsa.pub

recomputes the key fingerprint and displays it.

Finally, before you can use OpenSSH to log in on another computer, you must make sure that that computer has access to your public key. On MathLAN, you do this by creating a file called authorized_keys2 in your .ssh subdirectory. This file should simply be a copy of the file containing the public key, so you can create it by giving the command

cp ~/.ssh/id_dsa.pub ~/.ssh/authorized_keys2

at the prompt in the terminal emulator.

Incidentally, you may change your OpenSSH passphrase at any time. In the terminal emulator, type

ssh-keygen -p -f ~/.ssh/id_dsa

at the prompt. OpenSSH asks you for both your old passphrase and your new one, thus:

$ ssh-keygen -p -f ~/.ssh/id_dsa
Enter old passphrase: 
Key has comment 'dsa w/o comment'
Enter new passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved with the new passphrase.
$

Using the OpenSSH tools

To log in remotely on another computer, use the ssh command. For instance, if you type

ssh bourbaki.math.grinnell.edu

in the terminal emulator, ssh prompts you for your passphrase, authenticates you to bourbaki.math.grinnell.edu, and logs you in. (You don't need to supply your MathLAN password -- only your OpenSSH passphrase.) The whole exchange looks something like this on screen:

$ ssh bourbaki.math.grinnell.edu
Enter passphrase for key '/home/spelvin/.ssh/id_dsa': 
Last login: Mon Feb 30 13:54:00 2001 from nemo.math.grinnell.edu
$ 

The first time you log in on a particular computer, however, you'll also get a preliminary advisory message, reporting that the computer doesn't appear in your list of valid hosts:

The authenticity of host 'bourbaki.math.grinnell.edu (132.161.33.255)' can't be established.
RSA key fingerprint is e1:96:3d:44:0e:12:01:ab:9c:e1:6f:5e:c0:05:6b:70.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'bourbaki.math.grinnell.edu' (RSA) to the list of known hosts.

Despite the admonitory tone, this is the program's normal behavior and does not indicate that anything has gone wrong.

The ssh program can also be used to execute a single command on another computer. Type the command after the name of the computer on which you want to execute it.

$ ssh bourbaki.math.grinnell.edu /bin/cat /etc/hosts
Enter passphrase for key '/home/spelvin/.ssh/id_dsa':
127.0.0.1 localhost.localdomain localhost
132.161.33.255 bourbaki.math.grinnell.edu bourbaki
132.161.33.70 newton.math.grinnell.edu newton
132.161.33.153 hopper.math.grinnell.edu hopper
132.161.33.127 mail.math.grinnell.edu mail franklin.math.grinnell.edu franklin

Similarly, one can use the scp command to copy files from one computer to another, or the sftp command to transfer files by ftp. In each case, the interface is similar: you'll be prompted for the passphrase whenever you need to access another computer, and the whole interaction is encrypted.

Secure shells for other operating systems

Although OpenSSH is available only for operating systems derived from or designed to be very similar to Unix, there are analogous, free ``secure shell'' implementations that work under Windows (PuTTY) or on Macintosh computers (MacSSH). These implementations use the same protocols as OpenSSH and should be interoperable with the software on MathLAN, though the process of creating keypairs and the names of the files in which they are stored are likely to differ.

Kerberos

MathLAN also supports Kerberos, a network authentication protocol that relies on a centralized server. At the beginning of a work session, the user asks the server for an initial ticket -- an encrypted certificate establishing her identity -- and types in a password. The server stores the initial ticket in a file in the user's home directory. Later, when she wants to log in remotely to a different computer or to use some service on it, she runs a special ``Kerberized'' version of rlogin, rsh, rcp, or telnet, which submits her initial ticket along with the request. The computer that receives the request asks the central Kerberos server to confirm the initial ticket's authenticity; if all is well, the central Kerberos server responds by issuing a service ticket, which allows the user's request to proceed.

Each Kerberos ticket expires at a particular time, so that the access right can't be reused indefinitely. (Expired tickets are completely useless.) On MathLAN, an initial ticket expires ten hours after it is issued, and a service ticket expires at the same time as the initial ticket that was used to obtain it.

Setting up for Kerberos

In your home directory, create a file called .k5login. Each line of this file identifies a Kerberos user (in the jargon of the creators of Kerberos, a ``principal'') who will be allowed to access your home directory. So your .k5login file should contain just one line, thus:

spelvin@MATH.GRINNELL.EDU

(substituting your MathLAN user name for `spelvin'). The capital letters are important here; they make it clear that `MATH.GRINNELL.EDU' refers to a Kerberos realm rather than to an Internet domain.

Next, in order to use Kerberos, you'll need an entry in the database of principals that the centralized server maintains. Ask the MathLAN system administrator to create this entry and to assign you a Kerberos password. (This is not the same as your login password, by the way -- you'll supply this one only after you've logged in on one machine using your ordinary password.)

Once you have a Kerberos password, you can change it at any time by starting a terminal emulator and typing the command

/usr/bin/kpasswd

at the prompt. Kerberos asks you to type your old and new passwords and reports whether the attempt to change was successful, thus:

$ /usr/bin/kpasswd
Password for spelvin@MATH.GRINNELL.EDU: 
Enter new password: 
Enter it again: 
/usr/bin/kpasswd: Password mismatch while reading password

$ /usr/bin/kpasswd
Password for spelvin@MATH.GRINNELL.EDU: 
Enter new password: 
Enter it again: 
Password changed.
$

Using Kerberos

When you're ready to pick up an initial ticket, start up a terminal emulator and type

/usr/bin/kinit

at the prompt. Kerberos prompts you for your Kerberos password:

$ /usr/bin/kinit
Password for spelvin@MATH.GRINNELL.EDU:

Type it in. (It doesn't appear on screen as you type.)

If you like, you can confirm at this point that the central server issued a ticket. The command /usr/bin/klist prints out information about all your non-expired initial and service tickets that the computer you're using knows about:

$ /usr/bin/klist
Ticket cache: FILE:/tmp/krb5cc_203
Default principal: spelvin@MATH.GRINNELL.EDU

Valid starting     Expires            Service principal
02/30/01 15:21:53  02/31/01 01:22:33  krbtgt/MATH.GRINNELL.EDU@MATH.GRINNELL.EDU

Kerberos 4 ticket cache: /tmp/tkt203
klist: You have no tickets cached

The ``ticket cache'' is the file in which Kerberos chose to store your (encrypted) initial ticket. The ``default principal'' line specifies your user name and the Kerberos realm within which the ticket was issued. The next few lines indicate the date and time at which the ticket was issued, the date and time at which it will expire, and the service that issued it.

(There are actually two commonly used versions of Kerberos, version 4 and version 5. The software sets up a separate cache for each version, even though MathLAN's central Kerberos server issues only version-5 tickets. Thus the last two lines of the output, including the phrase ``You have no tickets cached,'' mean only that the version-4 cache is empty.)

As an alternative to running kinit, you can use your Kerberos password to log into MathLAN in the first place, either at the initial login screen or when making a remote connection. MathLAN workstations are set up to accept the Kerberos password as a fallback alternative to the normal login password. In this case, simply logging in stores the ticket on the workstation.

The /usr/bin directory contains Kerberized versions of the supported services: rlogin for remote logins, rsh for remote command execution, and rcp for remote file copying. Each of them supports the -x command-line option, which ensures that all interactions are encrypted. Thus Kerberos can be used within MathLAN for the same kinds of operations that OpenSSH can do. Kerberos has the advantage that the ticket negotiations are automatic and invisible; the user does not need to type the password before each request, as she does under OpenSSH, provided that she has an unexpired ticket to provide. So a typical remote login looks like this:

$ /usr/bin/rlogin -x bourbaki
This rlogin session is using DES encryption for all data transmissions.
Last login: Sun Feb 30 15:39:02 from nemo
$

and running a single command on another machine looks like this:

$ /usr/bin/rsh -x bourbaki cat /etc/hosts
This rsh session is using DES encryption for all data transmissions.
127.0.0.1 localhost.localdomain localhost
132.161.33.255 bourbaki.math.grinnell.edu bourbaki
132.161.33.70 newton.math.grinnell.edu newton
132.161.33.153 hopper.math.grinnell.edu hopper
132.161.33.127 mail.math.grinnell.edu mail franklin.math.grin.edu franklin
$

Although the ticket negotiations are invisible to the user, the klist program reports that a new ticket has been added to the cache:

02/30/01 15:38:02  02/31/01 01:22:33  host/bourbaki.math.grinnell.edu@MATH.GRINNELL.EDU

This means that bourbaki does not need to reconfirm the user's identity with the central Kerberos server before granting additional requests made before the expiration date.

MathLAN workstations also run ``Kerberized'' versions of the programs that approve file transfers by means of ftp and remote logins by telnet, so it is possible to use these programs without supplying passwords if you have a valid ticket.

The command /usr/bin/kdestroy forces the immediate expiration of all accessible tickets, just in case you want to make sure that they are invalid before you log out.

Kerberos under other operating systems

MinK is a free implementation of Kerberos that runs under Windows 95, Windows 98, Windows NT 4.0, or Windows 2000.

Kerberos for Macintosh is a free implementation of Kerberos (requiring MacOS 8.1 or later).

However, installing these programs will not automatically make it possible for users of ResNet or off-campus computers to obtain Kerberos tickets for services in the MATH.GRINNELL.EDU realm. Such machines would belong to a different Kerberos realm, which would have to register with the MathLAN Kerberos server in order to permit cross-realm authentication. ITS has expressed an interest in experimenting with a Kerberos server, but as far as I know it is not yet on line.


This document is available on the World Wide Web as

http://www.cs.grinnell.edu/mathlan/OpenSSH-and-Kerberos.xhtml

created July 23, 2001
last revised August 26, 2004

John David Stone (stone@cs.grinnell.edu)