Sshhh, somebody might hear you!

After thumbing through Lawn and Garden, you decide to order a lawn sprinkler. The salesperson who answers takes your name and address and asks for your credit card information. You read it off to him. Only then do you remember that you're in the Atlanta airport, 6 people are leaning in close (pen and paper in hand) to hear you, and one of them has the gall to ask you to repeat those last four digits!

Somewhat unlikely, perhaps, but it illustrates a point; we've learned how to protect credit card and phone numbers in the real world. But what about usernames, passwords and confidential computer data on the Internet?

It's quite common that we'll make connections to servers across the Internet and they'll ask for identification. When you read your mail from a POP or IMAP server or connect to a shell account with telnet, your username and password are sent from your machine through a series of routers to the server in question. Most of the time it's not an issue - but what happens if one of those machines chooses to listen to your conversation and display what you're typing or record your username and password for someone unfriendly to retrieve later?

This really isn't some theoretical possibility - it happens constantly! People find out that their username and password have been intercepted and someone has broken into their account. From that stolen account, the attackers may be able to gain complete control over the system and all its data. They may also choose to use your system to launch attacks against other systems. I've seen it happen and have had to clean up afterwards. The costs of doing so can be enormous.

The Internet's not going to rewire itself for you; you're going to continue to have machines in between you and the machines that want your password. How do you keep them from hearing that password? You encrypt it!

Much like agreeing with Yuri at Lawn-Sprinklers-R-Us to read off your credit card digits in Russian, you're going to carry on the same connections across the Internet, but hold the conversations in a manner that you and the server understand but the routers in the middle don't. If they can't see your password flying by, they're going to ignore you and look for other suckers going to read their mail.


OK, but is this going to be a long and painful process? Not at all. We'll go through it together.

If you don't already have the ssh software on your system (try running the command "ssh" to see), you'll need to download it. First, see if your distribution has ssh or openssh packages included (distributions created outside the US might, distributions created inside the US aren't likely to). One trick is to see whether there might be a server maintained outside the US that has software ready for your distribution; ftp.redhat.de is an excellent place to look for RedHat.

A more general place to look is ftp.zedz.net . Some of you may remember this as ftp.replay.com. This is a site that carries a wide range of encryption and security software. As it's operated outside of the US, you can download software without any concern for the US encryption regulations which are primarily in place to stop Americans from exporting software (there are some changes currently being made to these regulations, but I won't cover them here).

You'll need to download the ssh or openssh srpm package. I've generally used a licensed version of ssh in the past; openssh is a cleaned up version of the last freely available version of ssh. I had a small amount of trouble compiling it on a Redhat pre-6.0 system I was using as a testbed for this article, so I chose to stick with ssh for the moment. One final note about openssh; you'll need the openssl libraries and development package installed as well if you choose openssh. The two are likely to be found together.

If recompiling the source rpm doesn't work for you or you're not using an rpm-based system, download the .tar.gz and follow the instructions for compiling it on your system.


I generally recommend people compile their own copies of packages like ssh and pgp that are so intimately tied to system security. While I don't suggest you do this, the install can be just as easy as downloading the .i386.rpm's to an empty directory, changing to that directory and installing them with:

rpm -Uvh *.rpm

If you're willing to take just a little time, though, here's a quick and easy way to compile your own.

Place the .src.rpm in /usr/src

. nice rpm --rebuild ssh-1.2.27-1.src.rpm

I won't include all the output from the compilation. If all went well, the build process will create a .i386.rpm for you. Change to the /usr/src/redhat/RPMS/i386/ directory and type

rpm -Uvh ssh-1.2.27-1.i386.rpm ssh-server-1.2.27-1.i386.rpm

Here's approximately what you'll see:

[root@sparrow i386]# rpm -Uvh ssh-1.2.27-1.i386.rpm ssh-server-1.2.27-1.i386.rpm
ssh                         ##################################################
Generating 1024 bit host key.
Initializing random number generator...
Generating p:  ...................................++ (distance 442)
Generating q:  ...............................++ (distance 606)
Computing the keys...
Testing the keys...
Key generation complete.
Your identification has been saved in /etc/ssh_host_key.
Your public key is:
1024 33 161...(most of 309 digits deleted)...271 root@sparrow.net
Your public key has been saved in /etc/ssh_host_key.pub
ssh-server                  ##################################################

The RPM installation process installs the files and creates a matched pair of host keys (/etc/ssh_host_key and /etc/ssh_host_key.pub). You won't need to do anything with these files; the servers use these to identify each other.

Now lets start up the actual daemon:

[root@sparrow i386]# /etc/rc.d/init.d/ssh start
Starting sshd: ssh
[root@sparrow i386]# ps axf | grep ssh
 5314  ?  S    0:02 /usr/sbin/sshd

Now you need to carry the rpm over to a second computer and install it on that machine. Start the daemon up there as well. From one machine (sparrow), you'll connect to the other (goober) much like you would have with telnet:

[wstearns@sparrow wstearns]$ ssh goober
Host key not found from the list of known hosts.

Are you sure you want to continue connecting (yes/no)?
yes
Host 'goober' added to the list of known hosts.
wstearns's password: password_entered
You have mail.
[wstearns@goober wstearns]$ ls
dead.letter  mail         public_html  xfer
[wstearns@goober wstearns]$

As this is the first time you've connected, the remote system offers it's host key to you; you should accept it. Ssh automtically saves a copy of goober's host key in ~/.ssh/known_hosts on sparrow. When you connect next time, your ssh client will compare the host key it has with the key coming back from the server to make sure that it's the same system. It'll complain loudly if the key changes; it could be that someone has broken into or replaced your server.

Once you enter your password, you're able to do all the things you were able to do with telnet before. What have you gained? The big gain so far is that every character you type and every screen update that comes back from the server is encrypted; nobody can use a sniffer to see what your keystrokes or screen displays anymore.


Additional Resources:


What's next?

Next month we'll look at protecting other services such as POP and IMAP mail from prying eyes. We'll also look at some of the special tricks that make ssh easier to use and more powerful than telnet or rsh. Finally, we'll see a secure way to copy files between systems.


William is an Open-Source developer, enthusiast, and advocate from Vermont, USA.