Secure Shell: Protecting data in transit

If you're a network or systems administrator, one of your top considerations for any computer should be security. In this Daily Drill Down, Vincent Danen explains how to install and use Secure Shell (SSH) in order to guard against vulnerability and to protect your day-to-day network data.

If you’re a network or systems administrator, one of your top considerations for any computer should be security—whether it's local security or network security. Since Linux is a networked operating system by design, chances are that the computer is being used in a network environment as a simple firewall or as a server providing such services as HTTP, FTP, and Telnet.

Why Secure Shell?
Often, it’s convenient to administer remotely, and Linux supports remote administration. With such programs as Telnet and rlogin, an administrator staying at home can work on and configure a remote Linux machine at the office across the Internet. With more and more companies choosing Linux as a server, as a component of their Internet sites, or even as their gateway to the Internet, remote administration happens all the time.

Linux is very secure. With a little bit of work and through the use of firewalls, IP masquerading, and TCP Wrappers (which prevent unwanted guests from launching services), you can make a computer that runs Linux virtually invulnerable to any attacks across the Internet. Unfortunately, the same cannot be said about the Internet itself.

Most protocols transmit data in clear-text format, which means that there is no encryption or "scrambling" of the network data. Anyone who’s curious can "listen" to your network traffic as it goes from point A (let's say the system administrator at home) to point C (the server at work). Because of the nature of the Internet, without a direct dial-in connection to your server, your network traffic will probably be routed through point B (a host out in the internet) or even multiple point Bs. It’s possible that you’ll have a few, or even a few dozen, hops between your system and the one you're trying to reach. To find out how many hops exist between you and any given destination, give the program traceroute a try (which is usually located in /usr/sbin). It will tell you how many hops and how long of a delay between hosts it will take to reach your final destination.

Keep in mind that, if there are a dozen hops to the machine you’re trying to reach, there are also a dozen points of interception. Anyone with a packet sniffer or other network-monitoring tool can see and intercept your network data. If this is the case, not only can they view your network data, but they can maintain a local copy of it, view it later, and possibly glean passwords from it. If you think that you are protected just because you require a password for access, think again. Once this type of interception occurs and someone has obtained a user password to your system, your entire system could become compromised. As regular users, they may not get very far, but once they have access to your system, there are a number of holes they may exploit, like programs that are suid or sgid other users (like root). They may even make attempts to learn the root password of the system. Once an unwanted guest has access to your system, you should view your entire system as compromised. What if they installed a packet sniffer or keyboard monitor on your system? The root password could then be obtained quite easily.

But by then, it's too late. You can plug the hole and change the user's password, but the exposure has already occurred. Your system is compromised. The best way to deal with this situation is to prevent it from happening in the first place. Clear transmission is fundamentally a bad idea, and it should be avoided like the plague. Conscientious system or network administrators should avoid it even on local networks. The Internet is not the only place that harbors curious individuals.

Just what does Secure Shell do?
To guard against vulnerability and to protect your day-to-day network data, I highly recommend installing and using Secure Shell (SSH). SSH is a client/server suite of programs that encrypts data prior to sending it and that unencrypts data once it is received. Every packet in transit, whether across a local LAN or from point A to point C in the above illustration, is encrypted and safe from packet sniffers and other network monitors that may pose a security risk to similar programs. SSH is a suitable alternative for programs like Telnet, rlogin, rsh, rcp, and rdist. SSH was designed to provide strong authentication and secure communication over insecure networks (as noted in the Secure Shell RFC).

Secure Shell supports a number of encryption algorithms, such as:
  • BlowFish: A 64-bit encryption scheme developed by Bruce Schneier
  • Triple DES: The Data Encryption Standard, which was developed in 1974 by IBM and is used by the U.S. government for encrypting nonclassified data
  • IDEA: The International Data Encryption Algorithm, a powerful block-cipher encryption algorithm that operates with a 128-bit key, which makes it far more secure than Triple DES
  • RSA: The Rivest-Shamir-Adelman algorithm, a widely used public-key/private-key cryptographic system

SSH's multi-algorithm support is quite extensive and user-definable. If you feel more comfortable using IDEA than using RSA, you can use IDEA quite easily without changing how SSH works.

Besides providing encryption for network data, SSH can also be used to protect against IP Spoofing, which occurs when a remote host sends out packets that pretend to come from another (trusted) host. It can protect against IP Source Routing, which involves a host pretending that an IP packet comes from another (trusted) host. It protects against DNS Spoofing (when an attacker forges name server records). It prevents manipulation of data by people in control of intermediate systems (the hosts through which IP packets "hop"). And finally, it can also protect against attacks based on listening to X authentication data and spoofed connections to an X11 server.

Despite all of this functionality, using SSH for remote connections does not require an enormous learning curve. Using it is quite similar to using simple Telnet. Authentication and session encryption are completely transparent, and there is no apparent slowdown of information in transit beyond perhaps the seconds when the session authenticates.

How does it work?
SSH is a suite of programs designed to secure connections between two computers, one as client and one as server. To accomplish this task, it comes with a number of programs, including the client program, ssh. The client program is very much like a Telnet client in every respect, and it allows you to perform any console-based commands on the server. The server itself, sshd, listens on TCP Port 22, and when it receives a connection request from a valid SSH client, it starts a new session. There is also a copy program called scp. Secure Copy provides a secure means to copy files from one machine to another, much like the rcp program. Since SSH is based on keys to authenticate between client and server, it includes some key management programs like ssh-add, which will register new keys for the ssh-agent program. This program is used to perform RSA-style authentication over networks when you’re using SSH. In other words, it allows remote hosts to access and store your RSA private key. Finally there is ssh-keygen, which is the key generator for SSH. It generates an RSA key that is used by sshagent to authenticate both locally and remotely.

As you can see, SSH can offer a complete replacement for insecure programs like Telnet and rlogin. In its most basic form, SSH provides a method to secure remote logins and in-transit data and provides a way to protect files and documents transmitted from one machine to another. SSH is, however, quite versatile and can be used for more than that task alone. SSH can be used as an effective "tunneling" mechanism and can secure far more than just remote logins and file transfers. The only catch is that, because SSH is client/server-based, both the remote host and the local machine must use SSH. SSH for Linux is a freely available program. You can obtain the binary programs from ZEDZ or the source code itself from the SSH home page.

The benefits to compiling your own version of SSH are the various options that you can set during compilation and that you can customize to secure your network further. A number of the compilation options can be set in the configuration files if you choose to go with a binary distribution.

An important configuration option that can be specified only at compilation is whether or not SSH will use TCP Wrappers. There are two different schools of thought on this issue, but it boils down to how your system is configured and how you want to customize things. SSH can be independent from the rest of your system in terms of which hosts are allowed to connect, or it can use TCP Wrapper support, which enables SSH to allow and disallow connections based on the hosts defined in /etc/hosts.allow (specified authorized hosts) and /etc/hosts.deny (specified unauthorized hosts). TCP Wrappers is an excellent security tool that works similar to a firewall. The two configuration files are used to select services and to authorize or “unauthorize” specific hosts or domains from using those services. SSH can use this tool, or it can use its own form of allow/deny authorization (when compiled without TCP Wrappers support).

What are the specifics?
Once you’ve decided which method you're going to use (source or binary) and you have installed SSH, the suite of programs will become available to you. To any systems administrator, I recommend disabling all running Telnet servers completely. This disabling can be done by commenting out the Telnet field in /etc/inetd.conf so that the Inetd super-daemon will never open a Telnet session when an incoming request on TCP Port 23 is received. By the same token, you should also disable the rlogin and rsh suite of programs (rshd, rlogind, rexecd, and rexd). The system will not be secure until all of these programs are disabled or, preferably, removed completely.

You can then decide whether sshd will be a persistent service (started on its own and continually running) or whether Inetd will start it upon request. If you want Inetd to start the SSH daemon when required, add the following to your /etc/inetd.conf (if you have TCP Wrapper support enabled):
ssh stream tcp nowait root /usr/sbin/tcpd sshd -i

or if you have TCP Wrapper support disabled:
ssh stream tcp nowait root /usr/bin/sshd sshd -i

There is little real benefit to running sshd from Inetd. The SSH daemon does not take much memory or CPU when idle, so there is no need to worry about wasted resources if it is not used very often. The side effect to using Inetd, however, is that SSH must generate a server key prior to responding to the client, and this action can take a few seconds because it has to generate the key immediately before it can authenticate a session. Consequently, the session initiation will take a few seconds longer than necessary. Normally, sshd keeps a generated RSA key in memory so that it can respond to client requests immediately. The RSA key is usually re-generated hourly (which can be changed in the configuration), and it is never written to the disk—so as to preserve the key's integrity. Because of this added security, running the daemon stand-alone is recommended.

There are a number of other options that can be used by the SSH daemon on the command-line. These options include the number of bits to use in the server key (by default, it's 768 bits), how often sshd regenerates the server key (by default, it's once an hour), alternate ports to listen to (by default, it's TCP Port 22), and more. The configuration file for the daemon, /etc/sshd_config, permits more options to control how the daemon operates.

The SSH client program, ssh, also has a number of command-line options, as well as its own configuration file, /etc/ssh_config. Some of the options on the command line allow you to select which cipher (encryption method) to use, which user to log in as (if not the current user), and so forth. It will connect to the remote SSH server and initiate an interactive Telnet-like session. In fact, it is so transparent that, beyond the login, you will think that you’re sitting in front of the server itself.

The Secure Copy program should be used whenever you need to transfer one file to another. It is not an interactive copying program, like FTP, but it’s very similar to the cp program that’s used locally. It allows you to select which cipher you want to use on the command line, but it uses a unique syntax to copy files. The syntax is:
scp user@host1:[/path/filename] user@host2:[/path/filename]

or it can be abbreviated to
scp [/path/filename] user@host2:[/path/filename]

SSH can also be used as a tunneling program to create rough Virtual Private Networks or to allow remote users to access a remote X11 server securely. Beyond that, however, the uses for SSH are virtually endless because of its built-in tunneling and forwarding capabilities. It can be used to provide secure RPC sessions, which are useful in securing NIS services. It can be used to run encrypted PPP sessions on top of a standard SSH session. It can also be used to communicate with outside entities from behind a firewall, because of its TCP forwarding options. It can be used to provide encrypted access to POP3 servers so that, by tunneling it via SSH, you can securely download e-mail that would otherwise be transferred in clear-text (unless the server supports APOP or a similarly encrypted POP3 protocol and only if your client program supports the same protocols).

To Linux and beyond
For the Linux user, Secure Shell is an excellent suite of programs. Unfortunately, in the real world, not everyone uses Linux. So, does this fact limit SSH's usefulness at all? Definitely not! Within a heterogeneous network, or even for the administrator who uses Linux as a server at work and runs Windows at home, there are SSH clients for other platforms, as well. You can obtain various commercial SSH client implementations (called F-Secure SSH) for Windows and Macintosh systems from DataFellows. However, commercial alternatives have an associated cost. If you want free alternatives, you can take a look at some of the programs listed below.

For Windows, Tera Term Pro is useful. It is a popular Telnet client for Windows, but it doesn't come with SSH support natively. Robert O'Callahan, however, wrote an excellent SSH extension for Tera Term Pro that makes the Telnet client fully SSH-compliant. TTSSH (the SSH extension) can be obtained from the TTSSH home site. There are also two ports of SSH (command-line) to Windows from the SSH site and from Gordon Chaffee. There is yet another SSH client for Windows in the works, and it’s called Free FiSSH. It is not currently available to the public but should be soon. You can find more information on the official FiSSH site.

For Macintosh, there is Nifty Telnet, which supports SSH natively and can be obtained from Jonas Walden.

For OS/2, there is a port of SSH available. This port looks a little dated; however, it may still work as a client against the current release of SSH.

For those who use Java, there is also a Java-based SSH client called MindTerm that can run stand-alone or within a Web browser. It would be useful for operating systems that come without a direct version of SSH but that use Java.

It should be apparent that SSH is not only a useful solution to many security issues, but almost a necessary one. SSH has been quite popular for many UNIX and Linux system administrators for years, and the ever-increasing number of clients for other operating systems proves that the usefulness of SSH is not limited to UNIX and Linux alone. Unfortunately, there are no free servers for many operating systems, so anyone who plans on using SSH needs to do so with a UNIX or Linux server. That is yet another reason for using a stable and free platform, like Linux, in a networking environment.

Vincent Danen, a native Canadian in Edmonton, Alberta, has been computing since the age of 10, and he has been using Linux for nearly two years. Prior to that, he used OS/2 exclusively for approximately four years. Vincent is a firm believer in the philosophy behind the Linux "revolution,” and he attempts to contribute the Linux cause in as many ways as possible—from his Freezer Burn Web site to building and submitting custom RPMs for the Linux Mandrake project. Vincent also has obtained his Linux Administrator certification from Brainbench . He hopes to tackle the RHCE once it can be taken in Canada.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.


Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.