Secure Shell (SSH)

Secure Shell (SSH)

We've already looked at public-key cryptography and we've shown you how you can use GPG to secure your e-mail. Now we are going to show you another program that uses similar cryptographic techniques to encrypt data streams between client and server programs on different machines. This section will show the basics: Using SSH to have "encrypted Telnet" sessions and using SCP (secure copy) to have "encrypted FTP." In the next section we will go over advanced applications of SSH, such as using it to go through firewalls but in a secure manner.

If you are already familiar with the R tools, RSH (remote shell) and RCP (remote copy), then you can think of SSH and SCP as encrypted work-alikes. If you are not familiar with the R tools, do not bother. Using RSH is like leaving your Porsche running with the door open while you go for a five- hour walk. Many system administrators simply remove these tools from their systems ”they are that big a security hole. Instead, we will concentrate on comparing SSH to Telnet, and SCP to FTP.

In a Telnet session, a TCP socket is opened from the client machine to the server machine. There is some application-level protocol activity to set some terminal behavior preferences, but once the connection is established, it is literally keystrokes in one direction and screen output in the other. All the data passes over the network "in the clear." It is trivial, as demonstrated in Chapter 11 , to reconstruct everything communicated in a Telnet session, including login passwords.

SSH works differently. SSH uses a public-key crypto system similar to that used by PGP. It's a bit more complicated, since keys are used to authenticate hosts to one another, and they may optionally be used also to validate users at hosts.

When the SSH server, known as SSHD, is first installed, a key pair is generated. Actually, two key pairs are generated, one for encryption and the other for DSA, the Digital Signature Algorithm. You generally don't need to worry about these. The key-generation process looks like this:

 Generating RSA keys: ...ooooooO........ooooooO 

 Key generation complete. 

 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: 

 f8:fc:e8:43:be:15:59:c4:b5:44:48:ae:1b:d1:9e:a1 root@mars 

 Generating DSA parameter and key. 

 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: 

 f9:cc:4d:9c:da:50:ea:ad:a7:12:3a:4b:2d:11:50:13 root@mars 

Once the host key exists, the server may be started.

 [root@mars /root]# sshd 

 [root@mars /root]# 

Of course, you should check to see if it is already running!

Now let's see what happens when you attempt to connect for the first time:

 mars:22:~$ ssh alienmystery 

 The authenticity of host 'alienmystery.planetmercury.net' can't be established. 

 RSA key fingerprint is 58:f1:d0:f7:db:86:81:76:60:e2:7c:dd:d9:ff:f1:4e. 

 Are you sure you want to continue connecting (yes/no)? 

Danger, Will Robinson! Danger! Harken back, if you will, to Chapter 10 . Once again, you are dealing with cryptographic keys and trust. Only you can decide whether to trust the host key. Once you have done so, it is trusted for all time. Key discovery by connection is very risky. It is easily foiled by a "Man in the Middle" attack (MITM). You could be connecting to a spoofed host, where they are feeding you a key of their own creation. They will then make a connection of their own to the real host.

Just as with GPG, I prefer to ship host keys in person. In this case, however, let's throw caution to the wind and proceed:

 Are you sure you want to continue connecting (yes/no)? yes 

 Warning: Permanently added 'alienmystery.planetmercury.net,216.17.15.13' 

 (RSA) to the list of known hosts. 

 [e-mail]'s password: 

Now when we enter the password, it is encypted and sent to the far end. It is utterly impossible for a third party to eavesdrop on it.

 [e-mail]'s password: 

 Last login: Wed Jun 28 02:49:03 2000 from 209.105.15.162 

 Have a lot of fun... 

 alienmystery:~$ 

Not just the password is encrypted, however. All traffic from this point on is encrypted. No one but the two endpoints can see anything you do. No sniffer can observe your activity. Your login is secure.

Let's take a brief digression here and increase your level of paranoia . Even when your communications are fully encrypted with the kind of encryption that can defeat the resources of major governments , it is still possible to learn things about you and your communication. There is a discipline called traffic analysis. Some very fundamental facts are not hidden by SSH (or GPG for that matter). An observer can tell who is communicating. There is no way to obscure the addresses in communication and still get the messages delivered. Next, we can watch how much data moves in each direction, how many pauses occur and when, and from this we can deduce some things about what kind of communication is taking place. Over time we can build up a profile showing with whom you communicate securely and when. From this we can try to reach conclusions about who you are and what your intentions are. We might even have observed any and all of your open communications and be able to reconstruct your message with some accuracy if there are patterns to the pauses and rhythms of your typing.

Don't think for a moment that this is a mere academic exercise. As we learned to our horror on September 11, 2001, communications are essential to certain kinds of coordinated activity. Even if the parties involved had been communicating securely, the sudden increase in communications activity that must have taken place just prior to the attacks on the Pentagon and World Trade Center could have tipped us off.

This brings us to another question. Should cryptography be restricted or under government control? Sadly, the idea is appealing in light of recent horrible events. Unfortunately (or perhaps fortunately) it is already too late. The genie is out of the bottle . There is no way to take encryption away from the criminals. They already have it. We can only take it away from those who would use it for legitimate reasons.

File Transfer

File transfer is done with scp, which works just like the Linux cp command, with a bit of a filename extension:

 Syntax: 

 scp [[<username>@]<hostname>:]<path> [[<username>@]<hostname>:]<path> 

 Where: username Name of user on host 

 hostname Name of host on which path resides 

 path Directory or filename to copy, wildcards allowed 

Items in brackets are optional. An example should makes the case clear.

 [e-mail]'s password: 

 nmap-2.12-1.i386.rpm 100% ***************************** 175 KB 00:00 

 openssh-2.1.1p2-1.i3 100% ***************************** 84117 00:00 

 openssh-clients-2.1. 100% ***************************** 112 KB 00:00 

 openssh-server-2.1.1 100% ***************************** 98106 00:00 

As you can see, we copied all the RPM files from our present working directory on mars to mschwarz's present directory on the host "alienmystery." (Generally, the "." directory will be the specified user's home directory.) You can do recursive copies. You can copy to or from the remote host. All the traffic is encrypted, so no one can know what you are transferring ”very nice and very secure.

X11 Forwarding

One more feature and our introduction to SSH is complete. Once you have used the client, an .ssh directory will appear in your home directory. You can create a configuration file in there called config to set options for SSH, either for all of your connections or on a host-by-host basis. I have set one up for alienmystery:

 mars:45:~$ cat .ssh/config 

 Host alienmystery 

 ForwardX11 yes 

Note the ForwardX11 option. Watch what this does:

 mars:49:~$ ssh alienmystery 

 [e-mail]'s password: 

 Last login: Wed Jun 28 03:22:22 2000 from 209.105.15.162 

 Have a lot of fun... 

 alienmystery:~$ echo $DISPLAY 

 alienmystery:10.0 

 alienmystery:~$ xload -fg blue -bg gray & 

 [1] 2760 

 alienmystery:~$ 

Notice, I started on mars, used SSH to log in to alienmystery, and then looked at my DISPLAY environment variable. Remember how displays are usually ":0" or ":0.0"? Well, ":10" isn't an X-server really. It's ssh. The sshd program on alienmystery is "listening" to display 10. If we open any X- windows , it will grab the traffic, encrypt it, over the same link as the login session, and pass it to the X-server on the client side! Perhaps Figure 14-1 will make it clear.

Figure 14-1. Desktop showing forwarded xload.

Not only is that alienmystery xload not local, but all the X-protocol data is mixed in on the same socket as our SSH login session and fully encrypted. Someone watching our network sees one open socket between us and alienmystery, no matter how many X-windows we have open. They can't tell encrypted X-traffic from our encrypted shell session.

The SSH programs provide fully secure, encrypted network login and file transfer. We shall see even more of what SSH can do for us in the next section.