O+Cez+e2UvoiahCW3IWlmBFBZ8HJUoGzkC0+wVmZzZ0=

−−−−−END RSA PRIVATE KEY−−−−−

...............................................................................................

If these files don't exist, or don't look basically like this, you didn't run openssl properly. Go back and try it again or mail req.pem to your Certificate Authority, who should send you back a file that looks much like one of the preceding files. Save that response to a file named signature.pem and run this command:

...............................................................................................

# cat signature.pem >> cert.pem

........................................................................

This will copy the signature onto the end of the certificate and create a complete signed certificate. This certificate is good for anything on the host it's for; you can use it for a Web page, for a pop3ssl connection, or anything else that requires a certificate.

Being Your Own CA

When you're first learning, you probably won't want to go through the trouble and expense of having a Certificate Authority sign every certificate you create. Chances are, too, that you'll want a couple of certificates just to learn with. Signing a certificate is a simple mathematical process, and perfectly easy to do yourself.

Note If you sign your own certificates, client software will generate warnings that the "certificate signer is unknown." This is expected—after all, people outside my office have no idea who Michael Lucas is, or why he's signing Web site certificates! VeriSign and other CAs are trusted. I'm trusted by the people who know me,[2] not trusted to verify the identity of other people.

To sign your own certificates, first create a directory readable only by root and do all your CA work here:

...............................................................................................

#mkdir ca

#chown root.wheel ca

#chmod 700 ca

...............................................................................................

Then run the following openssl command to create a certificate authority key:

...............................................................................................

# openssl genrsa −des3 −out ca.key 1024

...............................................................................................

Enter a passphrase when prompted, and be sure to remember it, or the key you've just created is worthless. (You cannot use the certificate without the passphrase!) Finally, use the key you've just created to create a certificate for your CA:

...............................................................................................

302

# openssl req −new −x509 −days 365 −key ca.key −out ca.crt

...............................................................................................

Enter your passphrase when prompted (if you've forgotten it already, the only thing you can do is create a new key), and you'll enter a series of questions and answers identical to the one you saw when you created your certificate request. You now have a CA key (ca.key) and a CA certificate (ca.crt) that you can use to sign the request you created earlier. The preceding command, while long, never varies, so we won't go over it in any detail. Just trust me.

You'll be asked for your passphrase again. Once you type it, the actual signing process is very quick, and you should see a file named signature.pem, the signature file that a CA would send back to you. Just append it to your public key as discussed in the previous section, and you have a complete certificate!

NoteDon't use a self−signed certificate on a system where the public will see the self−signed certificate, because the warnings will confuse or annoy them or even scare them away. Spend the hundred dollars or so and have a real CA sign your production certificates. (Of course, if you're only using these certificates internally, you can download your corporate certificate and install it in your company's Web browsers. On Netscape 6, you'll find this option under Edit • Preferences • Advanced • Privacy & Security • Certificates. Different versions of Internet Explorer have this in different places.)

[1]This is a true story. Guard your private keys!

[2]Well, most of them, anyway. Many of them. A few, at least. Oh, never mind.

SSH

One of UNIX's great strengths is its remote administration ability. Whether the server is in front of you or in the basement of a locked laboratory in a maximum−security military installation surrounded by savage guard dogs and rabid weasels, if you have network access, a username, and a password, you can control it.

For many years, telnet(1) was the standard way to access a remote server. Telnet is nifty. You can use it to connect to an arbitrary TCP port on a host and manually talk to servers across the network. (We'll use it later in this chapter to test various services.) However, as a remote administration protocol, telnet has one crushing problem: Everything you send over most versions of telnet is unencrypted. Anyone sitting anywhere along your connection with a packet sniffer can grab your password, and not even the best password−selection scheme in the world will protect you against a packet sniffer. I've seen packet sniffers on Internet backbones and on small local networks. The only defense against a packet sniffer is to handle connections in such a way that intruders will get no useful information from them.

That's where SSH, or secure shell, comes in. SSH behaves much like telnet in that it gives you a highly configurable terminal window on a remote host. But unlike telnet, everything you send across the network is encrypted. SSH ensures not only that your passwords can't be sniffed, but also that the various commands you type (and their output) are scrambled. While telnet does have a few advantages over SSH (it requires less CPU time, and it's simpler to configure), its advantages are heavily outweighed by SSH's security advantages.

If you're looking for more information, SSH, The Secure Shell, by Daniel Barrett and Richard Silverman (O'Reilly & Associates), is perhaps the best book about SSH on the market today.

303

Testing SSH

Unlike some of the other protocols we're going to look at, SSH is difficult to test by hand. One thing you can do is confirm that the SSH daemon is running by using telnet to connect to the TCP port that SSH is supposedly running on:

...............................................................................................

# telnet localhost 22

Trying ::1...

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

SSH−1.99−OpenSSH_2.3.0 FreeBSD localisations 20010713

...............................................................................................

The last line of this output tells us that SSH is running and accepting connections.

Now, unless you're capable of encrypting packets by hand, on the fly, this is about as far as we can go. Hit the escape character (CONTROL–]) to close the connection, and you'll return to the local command prompt.

Enabling SSH

If your system isn't already configured to enable SSH at boottime, just add the following to /etc/rc.conf:

...............................................................................................

sshd_enable="YES"

...............................................................................................

On your next reboot, SSH will be enabled. If you don't want to reboot now, just type sshd as root to run SSH.

Basics of SSH

SSH uses public−key cryptography. The SSH daemon offers the public key to clients and keeps the private key to itself. Each chunk of data you send over the connection is handled as a message, which your local system encrypts with the public key; the server then decrypts the data with the private key. Since both public and private keys are necessary to complete this transaction, your data is secure; even if someone captures your SSH traffic, all she'll see is garbage.

Creating Keys

If your system lacks /etc/ssh/ssh_host_key or /etc/ssh/ssh_host_dsa_key, you can create them like this:

...............................................................................................

#/usr/bin/ssh−keygen −N "" −f /etc/ssh/ssh_host_key

#/usr/bin/ssh−keygen −d −N "" −f /etc/ssh/ssh_host_dsa_key

304

...............................................................................................

Note The SSH protocol is several years old, and is beginning to show its age. While it's still secure, people need more flexibility than it provides. For that reason, the Secure Shell 2 standard is becoming more common. Unless specified, you can assume that everything that follows applies to both versions of SSH. If a feature is found only in original SSH1 or in SSH2, it will be noted. Some files differ depending on the version of SSH being used, and those are noted as well.

Confirming SSH Identity

The whole process of public−key cryptography goes south if you get an incorrect public key for a host, which can happen either through user error or malice. The most accurate way to check host identification is to compare the public key on the server with the public key available over the network. Your public key defaults to /etc/ssh/ssh_host_key.pub for version 1; the version 2 default is /etc/ssh/ssh_host_dsa_key.pub. Since the two versions of SSH have different protocol requirements, they need different keys.

While you could copy both the SSH version 1 and SSH version 2 public keys to every host you want to connect from, and manually compare keys before connecting, host keys can be hundreds of characters long. This is not merely a pain, it's enough of a pain to prevent anyone from actually performing the check. Fortunately, SSH allows you to generate a key fingerprint, which is a much shorter version of a key. You cannot use the fingerprint to encrypt traffic or negotiate connections, but the chances of two unrelated keys having the same fingerprint are astronomical. To generate a fingerprint for a SSH version 1 key enter this command:

...............................................................................................

# ssh−keygen −lf /etc/ssh/ssh_host_key.pub

1024 7c:07:0f:1e:74:1a:42:11:b9:08:41:e4:f3:c9:05:a7

root@petulance.blackhelicopters.org

...............................................................................................

The response to this command is the key fingerprint. The first number, 1024, is the number of bits in the key (1024 is standard nowadays). The hexadecimal string starting with "7c" and ending with "a7" is the public−key fingerprint. You should copy this key fingerprint from the original server to a place where you can access it from your clients, either on a Web page or on a list. You'll need to use it the first time you connect.

You can use the same command on an SSH2 key, if you substitute the file that holds the SSHv2 key on the command line.

Note If your server provides both SSH1 and SSH2, as FreeBSD does by default, it's a good idea to prepare fingerprints for both public keys. You have no way to tell which version a user will use to connect.

SSH Clients

Your main problem with SSH will be finding a client that works on your preferred desktop system. If you use a BSD desktop, SSH comes with your system, and other UNIX operating systems usually

305