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

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 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:

http://www.ssh.fi. The company started by Tatu Ylonen (ssh's author)
to develop and market ssh.

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.