BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


FreeBSD Basics The SSH Cryptosystem

by Dru Lavigne
11/14/2002

In the last article, you learned that a cryptosystem is used to protect the privacy, integrity, and authenticity of data as it traverses a network. In today's article, we'll see how the SSH cryptosystem provides these features.

If you're using at least FreeBSD version 4.0, your FreeBSD system uses OpensSSH and it is installed and ready to go. As the name implies, this is an open source implementation of the SSH cryptosystem. You can read more about it at the OpenSSH website.

In a previous article (see IP Packets Revealed), I demonstrated that the telnet utility can be used to login to a remote computer from another system. Once logged in, a user can do anything on that remote system as if he were physically sitting in front of it. That is, every keystroke is sent to the remote system and interpreted as if it had come from the keyboard attached to that remote system (even though that keyboard input first had to travel over a network). We also saw in that article that every single keystroke and response was sent in clear text, meaning that a sniffer could watch the entire session.

Related Reading

SSH, The Secure Shell: The Definitive Guide
By Daniel J. Barrett, Richard E. Silverman

Any SSH cryptosystem will allow a user to login to a remote system and work just as if he were physically there. However, before the user is given a login prompt, a key will be generated to encrypt and decrypt all of the data that will be passed between the two computers. That is, more is happening behind the scenes.

Since SSH is used to access another computer, a user account must exist on the computer to be accessed. Additionally, the computer being accessed is known as the SSH server and must be running the SSH daemon; by default, this daemon listens on TCP port 22. The machine you are sitting at is known as the SSH client; it will contact the daemon on the other machine.

Your FreeBSD system has default configurations that allow you to use SSH as is. I'll demonstrate the default configuration first, then move on to some changes you may wish to make to increase the security of SSH.

I'll be using two computers. 10.0.0.1 will be the SSH daemon, the computer I wish to access, and 10.0.0.2 will be the SSH client, the computer I'm sitting at. On both systems, I have created a user account called "genisis". You'll note that the cryptosystem is called OpenSSH. It uses a protocol usually written as uppercase SSH, and the commands you type, ssh and sshd, are written in lowercase. Also, you can use the ssh command to access either an IP address or a hostname. In this week's article, I'll purposefully use IP addresses. In the next article I'll take a closer look at name resolution issues when using SSH.

First, I need to check if the host keys have been created on the system that will be the server. At 10.0.0.1, I'll run this command:

ls /etc/ssh

If I get this output:

moduli			ssh_host_dsa_key.pub	ssh_host_rsa_key
ssh_config		ssh_host_key		ssh_host_rsa_key.pub
ssh_host_dsa_key	ssh_host_key.pub	sshd_config

I have the necessary keys. However, if I instead get this output:

moduli		ssh_config	sshd_config

there aren't any host keys and I will need to generate them before I can start the SSH daemon. If I'm impatient and try to start the SSH daemon before creating the keys, it will refuse to start and I'll instead receive this error message:

sshd
Could not load host key: /etc/ssh/ssh_host_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
Disabling protocol version 1. Could not load host key
Disabling protocol version 2. Could not load host key
sshd: no hostkeys available -- exiting.

There are several ways to generate those missing keys. If you are an advanced user who is comfortable with reading startup scripts, search for ssh in /etc/rc.network to see which commands your FreeBSD system uses to generate the host keys. I'll instead demonstrate the results of running that script. The easiest way to ensure the necessary keys are generated and that SSH starts whenever the system reboots is to add the following line to /etc/rc.conf:

sshd_enable="YES"

Once I've saved my changes, I'll type:

shutdown now

When I get a prompt back, I'll press enter and then type the word exit. As my startup scripts are reinitialized, I see the following message:

Starting final network daemons: creating ssh1 RSA host key
Generating public/private rsa1 key pair.
Your identification has been saved in /etc/ssh/ssh_host_key.
Your public key has been saved in /etc/ ssh/ssh_host_key.pub.
The key fingerprint is:
12:d9:3d:f3:95:92:0e:e7:6b:54:09:80:77:a0:3e:cf root@hostname
creating ssh2 RSA host key
Generating public/private rsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
4b:cf:7e:af:f1:a8:01:08:64:1b:c0:79:e3:a2:58:78 root@hostname
creating ssh2 DSA host key
Generating public/private dsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_dsa_key.
Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub.
The key fingerprint is:
22:69:d7:05:23:c6:db:d9:55:2a:20:a3:34:bd:f4:ef root@hostname

Let's take a look at that output. You'll note that three separate key pairs were generated: one for rsa1, one for rsa, and one for dsa. You should recognize the RSA and DSA acronyms from the last article on cryptographic terms. But why so many key pairs? There are two versions of the SSH protocol, and OpenSSH supports them both. Not surprisingly, the rsa1 keypair is used by SSH version 1. You can see from the output that ssh2 (version 2) supports both RSA and DSA.

Pages: 1, 2

Next Pagearrow





Sponsored by: