by Marcel Gagné

Once upon a time, when the Earth was green, plain text communications was the norm. We used TELNET to connect to systems where we needed to get work done. From a security perspective, plain-text communications is frought with dangers. Anyone running a network sniffer program, of which there are many, can snoop on every packet sailing across your network. If you are logging in using TELNET, that person can see your user name and password plain as day.

One way around this dilemma is to use the secure shell. OpenSSH is an open-source implementation of the secure shell protocol that comes with almost every major Linux distribution. The secure shell is much more than a simple way to keep your passwords to yourself. Logging securely certainly qualifies as the basics for OpenSSH and it’s certainly useful, but there are some seriously cool SSH features that should make you wonder why you would use anything else to communicate (well, almost). For instance, it’s possible to tunnel ports you may not have access to (if the machine is behind a firewall) through the SSH port. SSH makes it possible to run remote graphical sessions easily. You can even securely log in without a password. SSH is a veritable Swiss Army knife of OS toys.

Yes, I’ll cover all those things later. First, the basics.

You can run out to www.openssh.org to get the latest and greatest, but you probably already have it on your system. That said, keeping up to date with the latest version of OpenSSH is essential if you want to maintain security. So, if your version of OpenSSH is more than a few months old, you may want to consider checking for an update.

OpenSSH has several components: a client and server, utilities for generating public and private encrypted keys for strong authentication and a secure FTP server. Before you log in using a secure shell, you need to start a secure server, which usually happens at boot time through a script in /etc/init.d or /etc/rc.d/init.d, depending on your system. Look there for a script called simply sshd. You also can start the sshd daemon by typing sshd at the shell.

To log in to the remote system named speedy, I then would use the command:

   ssh speedy 

By default, the sshd daemon (or server) runs on TCP port 22 — check it out by doing a more or less on your /etc/services file — but you can specify a different port with the -p option. Say you wanted to run the server on port 2222, to make it a little more difficult for unwanted guests to probe your system.

To change this, simply type:

   sshd -p 2222

By the way, you can run multiple sshd dæmons on however many ports you like, but that’s probably not necessary. Because your server is now running on port 2222, you also would use the -p option to connect to speedy, the same as you did for the server.

   ssh -p 2222 -l inewton speedy

Yes, I did add another option. The -l option tells the system to log in using the user name inewton. Actually, you can save yourself a couple of keystrokes by using the ‘@’ sign in this fashion.

   ssh inewton@speedy

By default, an ssh login uses whatever your current logged-in user name happens to be. You may then see a rather strange little message followed by a request for your password.

Warning: Permanently added 'speedy,192.168.22.3' (RSA) to the list of known hosts.
marcel@speedy's password:

Simple enough. At this point, you would enter your password, log in, and start your work session. The message above, though, is not the only one you could receive. I’ll cover some others in a moment. For now, I want you to look at the words list of known hosts. In your home directory ($HOME), you should find a directory called .ssh that contains a file called known_hosts. This is where the key information is stored; in the above case, it stored the RSA key. It looks something like this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for speedy has changed,
and the key for the corresponding IP address 192.168.22.3
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/mgagne/.ssh/known_hosts:3
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
28:68:a6:e7:6c:d6:24:d1:32:60:d1:25:e7:2f:2a:df.
Please contact your system administrator.
Add correct host key in /home/mgagne/.ssh/known_hosts to get rid of this message.
Offending key in /home/mgagne/.ssh/known_hosts:59
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
X11 forwarding is disabled to avoid man-in-the-middle attacks.
Permission denied (publickey,gssapi-with-mic,password).

Yes, it does sound nasty and it could very well be, but it may in fact also be harmless. As the message says, it is also possible that the RSA host key has just been changed. If you know and trust the system, you can edit your ~/.ssh/known_hosts file and delete the line containing the offending key. The connect error message conveniently lets you know which line number you can jump to; in this case, it’s line 59. If, like me, you tend to use vi, here’s a cool trick for getting there quickly:

vi +59 ~/.ssh/known_hosts

The +59 takes you right to line 59. Once there, a quick dd gets rid of the offending line for you.

Of course, you can use something other than vi (or vim) If you prefer something *ahem* friendlier.

I’m going to leave it here for today. Next time, I’ll show a little of what happens on the server side.

— Marcel