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.
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,
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:
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
/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
Once I've saved my changes, I'll type:
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