Way back when, on this very corner, I did a series of articles on encryption and hiding your tracks, something I called the High Tech How Not to be Seen. In that series, I talked about the dangers of plain-text communications to security. Here's a quick recap for those who still might be connecting to remote systems using telnet. Anyone running a program like sniffit (reptile.rug.ac.be/~coder/sniffit/sniffit.html) 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. Look at Figure 1, and see if you can guess the user nessie's password. This should dissuade you from using telnet for any kind of communication where security is even remotely important.

Figure 1. Can you guess nessie's password from this screenshot?

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

The secure shell is more than a simple way to keep your passwords to yourself. In this series, I take you from the basics through some nifty features that should make you wonder why you use anything else to communicate (well, almost).

Ssh has several components: a client and server, utilities for generating public and private encrypted keys for strong authentication and a secure FTP server. Before we log in using a secure shell, we need to start a secure server, which usually happens at boot time through a script in /sbin/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 dæmon by typing sshd at the shell.

To log in to the remote system named speedy, I then would use this command, ssh speedy.

By default, the sshd dæmon (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. Let's 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 natika speedy

Okay, so I added another option. The -l option tells the system to log in using the user name natika. By default, an ssh login uses whatever your current logged-in user name happens to be.

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

Simple enough. At this point, you would enter your password, log in and start your work session, much as you would have done with telnet, only safer. The message above, though, is not the only one you could receive, and 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 should contain 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.

speedy,192.168.22.3 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAw4MQ4ubLTHuQCW9rlksXLME9wnYYege1z/
K3J3caMpzkFy7DpJ1VQjIspf03wyHgdAbg3jaV6NBbN7y35UOLy2oqJ/vk3QISdgKca/OqH/
UpeesyXB0kMb0HMCX8LD8tJVaCzEtoi2BZNSAOZNheHx7znz80uTWUTA2cQkk7gs0=

Nice, huh? Don't worry. I don't expect you do sit there and read it with anything other than curiosity. Remember this file, though, because from time to time, on connect, you may receive a message like this:

   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
   @    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
   76:3f:54:71:22:48:36:5b:c8:8c:42:e5:e7:db:60:60.
   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:119
   Password authentication is disabled to avoid man-in-the-middle attacks.
   X11 forwarding is disabled to avoid man-in-the-middle attacks.
   Permission denied (publickey,password,keyboard-interactive).

Yes, it does sound nasty, but it may in fact 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 119. If, like me, you tend to use vi, here's a cool trick for getting there quickly.

     vi +119 ~/.ssh/known_hosts

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

I mentioned that on connect, you might see different messages. To refresh your memory, here's the message I received when connecting to the host speedy:

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

Another common message I could have received is:

     The authenticity of host 'speedy (192.168.22.3)' can't be established.
     RSA key fingerprint is 83:9f:6b:3f:69:02:2a:94:c5:ef:5f:35:f9:42:71:17.
     Are you sure you want to continue connecting (yes/no)?

The difference has to do with yet another configuration file. Both the sshd dæmon and the ssh command itself have global configuration options that can be found in the /etc/ssh directory. If you built OpenSSH from source, you may find it in /usr/local/etc/ssh instead. The sshd dæmon's configuration file is named sshd_config, while the ssh client's configuration file is named ssh_config. For the moment, I'm going to concentrate on the ssh_config file:

     Host *
       ForwardX11 yes

As you might guess from the asterisk at the end of the Host paragraph, you can set up different parameters for different hosts. This is a global setting. I'll talk about X forwarding later, but if this is all you have in your ssh_config file, you can expect messages asking you to verify the authenticity of any new system into which you connect. Let's delete the key entry from known_hosts and try again. This time, we add one line to the global ssh_config file:

     StrictHostKeyChecking no

Connecting to my host now results in a simple acceptance of the host's RSA key. But what, you may be asking, would happen if you set StrictHostKeyChecking to Yes?

     Host *
     ForwardX11 yes
     StrictHostKeyChecking yes

When I try to connect to speedy now, this message is returned instead:

     $ ssh -l mgagne speedy
     No RSA host key is known for speedy and you have requested strict checking.
     Host key verification failed.

And that, my friends, is where I am going to leave things today. Keys, key generation and key management will be the subjects of my next column.

Marcel Gagné is Linux Journal's Chef Français and a Linux true believer. His new book, Moving to Linux: Kiss the Blue Screen of Death Goodbye! will be out in August. You can find out more from his web site.