Return to SSH and Tunneling

SSH Introduction

One of the interesting things about the Internet is that it was not designed for security, and kind of happened almost accidentally. The early researchers, people like JCR Licklider and Vint Cerf, were mostly interested in facilitating communication between university researchers, and assumed that anyone they were in contact with was another “good guy”. It was only when the Internet started to take off in the 1980s and 1990s that anyone began to pay attention to this stuff. Technologies like Javascript and SSL were introduced by Netscape, for instance, though they have since been adopted by the whole Internet.

In the early days if you wanted to log on to a remote computer to do some work you would probably use a program called Telnet to do this. Telnet would let you log in to a remote Unix machine if you had an account on it, and once logged in you could do anything your account was authorized to do. And if you had root access it could be just about anything. I recall my first introduction to this in the in the 1990s when I was managing the web site of my university. I was given a shell account on our Red Hat server that also housed the web site, and sternly warned not to do anything to screw it up. I would Telnet into the server from my desktop to do things like chmod the CGI scripts and similar things we needed to do with web sites in those days. This worked reasonably well, but the problem with Telnet is that it was never designed to create a secure connection, and since this server had our Web site it was perforce exposed to the whole Internet. If you combine an unsecure connection with a man-in-the-middle attack, or with vulnerabilities in the Telnet program that allowed an attacker to get in, and even escalate their privileges, you can see why this became an issue.

In 1995 there was a password-sniffing attack on the network of the University of Helsinki in Finland, and this lead a researcher there, Tatu Ylönen, to create the first SSH implementation. SSH is an acronym for Secure Shell, and expresses the idea that you can securely log in and get a shell on a remote server. This was initially released as free software, but in later versions he took it proprietary. But the developers at OpenBSD decided that a free software implementation was needed, and they created OpenSSH, which is the basis for most implementations today. And while SSH was initially intended for Unix-like environments (which came to include Linux), the OpenBSD developers created a portability branch to make it available to any OS. So if you are running a Windows environment you can use SSH just as easily. If you want a little more detail on this you can consult Wikipedia.

Design Considerations

SSH was designed to do several things:

  1. Create secure and private communication between two different machines. This means that the connection must use encryption.
  2. Establish the integrity of the communications to ensure that messages have not been altered en route. Again, encryption makes this possible.
  3. Authenticate both parties to the conversation to prove their identities. Again, encryption makes this possible.

As regards authentication, SSH can be done using passwords, but that is a weaker form of authentication. If you are serious about security, you should authenticate using a key. Our old friends the public/private key pair come in at this point, and as you might imagine the outlines of how this is done are pretty similar to what we saw in both E-mail and in Certificates. This is not perfect, of course, but it reduces the chances of an attack very significantly. Note that even if you are using password authentication there is encryption and key-exchanging going on. That is necessary to accomplish the first two of the above goals.

Encryption and Tunneling

The basic idea in SSH, just as with Virtual Private Networks, is to use encryption to create secure communications between two different systems. It has become customary to refer this type of connection as a “tunnel”. This is a metaphor, and like all metaphors it both illuminates some things and obscures others. The idea of a tunnel does help to get across the security of the connection, in that if done properly the outside world cannot see what is going on. The encryption does work if you do it right, and as Bruce Schneier famously said in the wake of the Snowden revelations, you can trust the mathematics. However, the metaphor somehow implies to people that this traffic is flowing in some other place than the rest of the Internet, and that is simply untrue. All “tunnel” traffic flows through the same routers and switches as all other Internet traffic, and is made up of the same kinds of packets. If you are on a network where someone is using SSH, you can “see” the packets using wireshark or other similar software. But you would not be able to see anything in the payload of each packet other than random noise because of the encryption.

It is important to understand the mechanisms and how they work if you are going to be secure, since otherwise you might make a mistake and open yourself to an attack.

SSH Uses

Although SSH originally was developed to simply provide a secure shell session on a remote server, it has been extended in a number of interesting ways which we will look at in upcoming tutorials. For example, SSH can be used to:

  • Create tunnels
  • Forward TCP ports
  • Create X11 connections
  • Securely transfer files (SFTP)
  • Securely copy files (SCP)
  • Securely mount a remote file system (SSHFS)

Where Do You Get SSH?

SSH uses the client-server model. Generally, you are coming from a desktop and want to connect to a remote server. If the server is Unix or Linux, it should have SSH installed and properly configured if the sysadmins are any good. On Windows servers it may need to be installed, but this is not difficult. For any Windows sysadmins out there, here is an article that explains the installation on a Windows 2008 server.

As for desktop clients, again all Unix-like systems have the SSH client installed by default. This includes Unix, Linux, MacOS, all flavors of BSD. for windows users, I recommend installing PuTTY. This is free software, is distributed under the MIT license, and complies with the Debian Free Software Guidelines. There are several PuTTY applications, since they use different applets for each of the capabilities, so one is for Secure Shell, another for SFTP, and so on.

There is a useful manual site for OpenSSH and for the various applications that make up all of OpenSSH which can be found at From here you can see that the applications which make up all of OpenSSH include:

  • ssh – The basic rlogin/rsh-like client program.
  • sshd – The daemon that permits you to login.
  • ssh_config – The client configuration file.
  • sshd_config – The daemon configuration file.
  • ssh-agent – An authentication agent that can store private keys.
  • ssh-add – Tool which adds keys to in the above agent.
  • sftp – FTP-like program that works over SSH1 and SSH2 protocol.
  • scp – File copy program that acts like rcp.
  • ssh-keygen – Key generation tool.
  • sftp-server – SFTP server subsystem (started automatically by sshd).
  • ssh-keyscan – Utility for gathering public host keys from a number of hosts.
  • ssh-keysign – Helper program for hostbased authentication.

So make sure you have your software in order and we will move forward in the next tutorial.


Listen to the audio version of this post on Hacker Public Radio!

 Save as PDF