Alternate Authentication Methods

I'm not going to go into too much depth here, because for most of us strong encryption with password authentication is plenty mucho security. You can, however, use a number of different ways to authenticate, including S/Key and Kerberos. If you do not know what these are, you almost certainly aren't using them.

The alternate authentication method I like best is the RSA/DSA authentication method. In this method, each user generates a key pair (using ssh-keygen ), and this key is used to authenticate the user.

Hosts always authenticate to one another using public-key and private-key pairs. A user may also authenticate to an account using a public-key and private-key pair. This can be much more secure, for several reasons:

· A passphrase is used to "unlock" the private key when the connection is made. A passphrase is much longer and much harder to guess than a password.

· A key may be tied to a host. Thus you can limit the hosts from which a key may be used.

· A script or program may be triggered on successful authentication. This can let you restrict a key to performing a single activity, like a backup.

· Port forward or X11 forwarding may be disabled on a key-by-key basis.

All of these things are done by creating a file called ~/.ssh/authorized_keys. This file exists in a user's .ssh directory, and it contains all of the public keys that will be allowed in. In order for someone to get in, they must have the private key that matches the public key, and that means that they must have both the key file and the passphrase that protects the key. This is considerably stronger than mere eight-character password authentication.

You generate a key by running ssh-keygen, which creates a secret key and a public key. The public key can be found in your .ssh directory in a file called identity.pub. You must add the contents of the file to the .ssh/authorized_keys file of any user account to which you will have access.

This brings up something I had neglected to mention. Suppose you do not have the same username on two different boxes? You can specify which user account you are trying to log in to, in two ways. One is with the -l command line switch:

  $ ssh -l altname frosting.bakery.org

The other (and, I find, preferable) way is this:

  $ ssh altname@frosting.bakery.org

I think the second method is more intuitive. You may have figured out by now that you can share your account with hordes of people this way. You could put the public keys of 50 people into your .ssh/authorized_keys file. I don't recommend this practice. Remember that anything they do in your account will look like you did it. They will be able to send e-mail as you, read any file you can read, or give themselves a setuid copy of a shell owned by you (which would let them become you at will, even if you delete their key from your .ssh/authorized_keys file).

Getting back to our story, once you have your public key in the authorized keys file, your login looks a little bit different:

  mschwarz@mars:~ ssh alienmystery

  Enter passphrase for RSA key 'mschwarz@mars':

  You have old mail in /var/spool/mail/mschwarz.

  Last login: Fri Oct 13 01:16:34 2000 from localhost

  Have a lot of fun...

  alienmystery:~$

Some notes: If you have StrictModes set to "yes" (and I recommend that you do), you will find that the files in .ssh/ will have to be set to 600 (read and write for owner only ) permissions or nothing will work. When SSH creates files, it generally gets this right for you, but when you create your own authorized_keys file, you must remember to do this.

If you do not have StrictModes set to "yes," then anyone with write permission on your authorized_keys file will be able to put a public key in there and gain full access to your account! This is what we computer security professionals call "a bad thing."

Once you have your authorized keys all worked out, I recommend you disable PasswordAuthentication. That will require that users attempting to connect must have the secret key that goes with a known public key, or they can't get in at all. This prevents anyone from attempting to use SSH to crack passwords through multiple attempts.