Protect Your Data with OpenSSH

Linux has always offered lots of tools that make it easy to work remotely over a network. However, many of those tools were highly insecure. OpenSSH changes that and keeps your communications secure.

SSH Shield

Once upon a time, the Unix powers that be said “let there be networks,” and there were networks. And they saw the networks, and they thought that they were good. Until the first time someone eavesdropped on a remote login session, hijacked the remote user’s name and password, and then used that information to break into the system later that night.

And so it was in the early days of Unix networking, when all we had were the simple tools for remote connectivity: telnet and its cousins rlogin, rsh, rcp, and ftp, all of which sent your information over the transom as clear text — that is, unencrypted and unprotected.

Sending information as clear text isn’t a problem if you are working on a trusted network (such as a LAN) that is not connected to the Internet. However, that’s a fairly rare circumstance these days. Most Linux and Unix systems are either connected directly to the Internet or live on a LAN that is connected to the Internet. If you have machines that are connected to the Internet either directly or indirectly, you need to take certain steps in order to protect yourself. Not taking these steps can open you up to some serious security risks.

One way to minimize your security risk is to replace insecure network tools like ftp, telnet, and rlogin with secure network connectivity tools. And when it comes to secure connectivity tools on Linux or any other Unix-like system, OpenSSH is the way to go.

Introducing OpenSSH

OpenSSH is an Open Source and Free Software implementation of the Secure Shell (SSH) protocols. So what is SSH? SSH is a program written by Tatu Ylönen that was designed to replace the traditional insecure “r” commands — rlogin, rsh, and rcp (and also telnet, which obviously doesn’t start with an “r”, but is insecure nonetheless). Originally, SSH was free software.

Unfortunately, after version 1.2.12 of SSH, the software was released under a restrictive license that forbade commercial use or porting to certain operating systems. This created a problem for projects that needed a free SSH. Including a non-free version of SSH wasn’t an option. Including an older version with known bugs and security issues wasn’t really an option either.

The OpenBSD team (one of the groups that maintains a variant of Berkeley Unix) decided to start with the last free version of SSH and build their own. The first versions they created were designed specifically for OpenBSD, but there was such a great demand for an Open version of SSH for other Open Source OSes, that the OpenBSD team started a portable branch of OpenSSH that can also be built on AIX, HP/UX, IRIX, Linux, FreeBSD, NetBSD, and Solaris.

OpenSSH is not just one program, but a collection of tools that includes ssh, scp, ssh-keygen, ssh-agent, ssh-add, and sshd. Sshd is the daemon (or server process) that allows a system to accept secure connections. OpenSSH versions 2 and later support two protocols — both the older SSH1 protocol and the newer SSH2. This allows OpenSSH to create connections to and from clients that support either one or both protocols.

Why Use OpenSSH

As we’ve said, it’s a bad idea to use telnet and the “r” commands over any insecure network. Secure communications protocols such as those provided by OpenSSH can protect you, your data, and possibly your business. Any time you connect to remote computers and transfer data over the Internet, you should be using a secure communications protocol. Publically-held companies have an obligation to their shareholders to take every step necessary to secure their computers and data. Many companies — both public and private — have strict policies forbidding the use of ftp, telnet, rlogin, rsh, rcp, and other insecure connectivity tools. If you work in any of these environments and you use open source software, you should be using OpenSSH.

Although many implementations of SSH are available, OpenSSH is the only version that is open source, is available for Linux and other Unices, and that implements both the SSH1 and SSH2 protocols. This means that it can interoperate with ssh clients and servers that still use the older SSH1 protocol as well as those using the newer SSH2 protocol. OpenSSH provides all of the functionality of commercial SSH implementations without any of the licensing fees — a much better value proposition. Finally, for the extremely security conscious, OpenSSH’s source code is readily available to anyone who wishes to conduct a full security audit of the codebase.

Still, even with all these advantages, SSH can only do so much. If your computer is compromised in some fashion, then SSH can be subverted by the intruder. Unfortunately, once someone has access to your computer, it does not really matter how secure you attempt to be in communicating with the outside world. However, OpenSSH does make it a lot more difficult for any would-be intruder to get a hold of the usernames and passwords needed to gain access to your systems. At no time does OpenSSH transmit any information, including username and passwords, as clear text — not even prior to authenticating the user who is logging in.

Some people may be concerned that their network connections are not very fast, and the additional overhead of running secure protocols like OpenSSH may slow things down even more. Not to worry. In addition to encryption, OpenSSH compresses information prior to transmission, which helps to improve performance of connections, particularly on dial-up connections (or any other slow network connection).

The OpenSSH Architecture

You might be wondering exactly what OpenSSH does and how it does it. Though most of the architecture of OpenSSH is transparent to the end user, it’s still nice to know what’s going on behind the scenes.

As you may have gathered, the design of OpenSSH is based on a client/server architecture. That is to say, a user who wishes to connect to a remote server will execute the ssh command (the client) on his local computer, which connects to a remote computer’s ssh daemon (the server). It isn’t necessary for both computers to be running OpenSSH so long as the client or server supports either the SSH1 or SSH2 protocol. If you’re a system administrator with Linux boxes for servers and Windows or MacOS boxes on your network, you can use OpenSSH on your server and other ssh implementations for clients on the Windows and Mac machines. Conversely, you can run OpenSSH on your computer as the ssh client and connect to servers running other implementations of the ssh daemon.

As mentioned earlier, OpenSSH supports both the SSH1 and SSH2 protocols. These two protocols are not compatible. Many other SSH implementations support one or the other, but not both. The goal of the OpenSSH team has been to support both protocols.

SSH2 is a complete rewrite of the SSH1 protocol that improves security and performance. There are a few other important differences between the two protocols — one of the main differences is that SSH2 avoids patented cryptography algorithms. The SSH1 protocol used the RSA (Rivest-Shamir-Adleman) algorithm for both encryption and authentication. RSA was a patented algorithm until September 21 of this year, when the patent expired. SSH2 uses the non-patented Digital Signature Algorithm (DSA). Both of these algorithms (RSA and DSA) are used for the purpose of generating “keys” that allow messages to be encrypted on one side and decrypted on the other. SSH1 uses a host and server key to provide authentication, while SSH2 uses only a host key. For more on keys, see the Key-Based Cryptography sidebar at right.

Because SSH1 is the older of the two protocols, there are still more clients and servers that support SSH1 at this time. However, SSH1 is also more vulnerable to security issues, and SSH2 is quickly closing the gap.

The architecture of SSH2 is comprised of three layers — the transport layer, the user authentication layer, and the connection layer.

The transport layer is a low-level protocol that usually runs over TCP/IP. This layer is responsible for data encryption, host authentication, and maintaining the integrity of the data flow by including a message authentication code (MAC) in each data packet. Host authentication performs a very important function — insuring that the computer you are talking to actually is who it says it is (and not an imposter just trying to steal user names and passwords). This paves the way for user authentication, which is the next layer in the SSH2 architecture.

The user authentication layer assumes that the transport layer is providing data integrity and encryption. After the transport layer is established, the client sends a string to the server indicating that it is ready to authenticate a user on the server. In other words, the user authentication layer is responsible for actually logging a user into the remote computer and requesting to use the services available on that computer. The server verifies that the host key sent to it really belongs to the client computer named in the user authentication request. The server then verifies that the user named in the user authentication is allowed to log into the server in the first place.

Finally, there is SSH2′s connection layer. This layer depends on the two layers beneath it — the user authentication layer and the transport layer — to provide security and user authentication. The connection layer is used to open “channels” for pseudo terminals, X11 forwarding, and port forwarding. Multiple “channels” can be opened through one ssh connection. This functionality allows you to run an application such as an xterm and have that application communicate securely with the server.

If you are interested in learning more about all of this, the SSH2 protocol is specified in a number of Internet Drafts put forward by the IETF (Internet Engineering Task Force) SECSH working group. See Further Resources, pg. 61, for Web links to more information.




Installing OpenSSH

Before attempting to install OpenSSH, you should be aware that it depends on two other packages that you may or may not already have installed on your system; OpenSSL and zlib. The source code for OpenSSL can be found at http:// www.openssl.org/, and zlib source can be found at ftp://ftp.freesoftware.com/pub/infozip/zlib/zlib.html. RPMs (both binary and source RPMs) for many distributions can be found at RPMFind — http://www.rpmfind.net/. If you do a search for openssh, openssl, and zlib you should be able to find fairly current RPMs for Red Hat, Linux-Mandrake, SuSE, and other distributions that use RPM.

To install OpenSSH from RPM, download the latest binary RPMs of OpenSSH, OpenSSL, and zlib. Then log in as root and install the zlib RPM first, followed by the OpenSSL RPM, and then the OpenSSH RPM.


rpm -i zlib-1.1.3-12-i386.rpm
rpm -i openssl-0.9.5a-14-i386.rpm
rpm -i openssh-2.1.1p4-1-i386.rpm

The actual file names may differ — just be sure to get the appropriate RPM for your distribution. If you try to install the files in a different order, RPM will probably complain about missing dependencies.

To build OpenSSH from source, download the zlib, OpenSSL and OpenSSH source files and copy them to your /tmp directory (or whatever directory you use for working with source code.) Then untar and ungzip the files using the tar -zxvf command.


tar -zxvf zlib.tar.gz
tar -zxvf openssl-0.9.6.tar.gz
tar -zxvf openssh-2.2.0p1.tar.gz

Note that the version numbers of the OpenSSL and OpenSSH files may be different by the time you read this article. However the OpenSSL archive file should have a “p” in the version number to indicate that it is the “portable” version of the OpenSSL source code. If you download an archive without a “p” in the version number, you’ve probably grabbed the OpenBSD release, which is fine if you’re running OpenBSD but probably won’t compile under Linux or other Unices.You should then have three directories created under the /tmp directory:


zlib-1.1.3/
openssl-0.9.6/
openssh-2.2.0p1/

As root, cd into each new directory and run the following commands:


./configure
make
make install

Be sure to compile them in this order — zlib, openssl, openssh. Otherwise they will fail to compile properly. Once you’ve installed all three packages, run the command:


ssh -V

If you’ve successfully installed OpenSSH, you should see the following message:


bash-2.04$ ssh -V
SSH Version OpenSSH_2.2.0p1, protocol versions 1.5/2.0.
Compiled with SSL (0x0090600f).

(The version number of OpenSSH may differ, but it should look pretty much like that.)

Using OpenSSH

Now that we’ve looked at how the protocols work, let’s take a look at how to use the OpenSSH tools themselves. The first program we’ll look at is ssh. Ssh replaces telnet and rsh, and allows the user to log in securely to a remote computer. The ssh program connects and logs into a specified hostname and allows the user to execute commands on the remote machine.

The syntax for ssh is simple — just type ssh followed by the hostname you wish to connect to. You need to have an account on the remote computer to log in, of course. If your username on the remote machine is different from the one on the local machine, you can specify it on the command line by using the -l option like this:


ssh -l zonker remotehost

The hostname (remotehost) can be the name of the computer, or a domain name if it is not on the local network.

The scp program is used to copy files to remote computers; it replaces rcp, and, to some extent, ftp. Note that the OpenBSD team is working on an sftp program that will allow secure FTP, and it’s expected in the next major release.

To copy files using scp, use the following syntax:


scp filenameuser@remotehost:remotedirectory

The remote directory can be any directory for which the user has write permission.

The ssh-keygen command is used to generate an RSA or DSA authentication key. The command generates an authentication key and places it in the directory .ssh/ under the user’s home directory. To generate a key for use with the SSH1 protocols, use the following command:


ssh-keygen -b bits

The key must be a minimum of 512 bits, and the default is 1024 bits. Anything above 1024 bits is not considered any more secure, but does tend to slow things down due to the increased processing time necessary for handling longer keys. By default, ssh-keygen generates an RSA key. To create a DSA key instead, use the following syntax:


ssh-keygen -d

RSA keys generated by ssh-keygen are named identity and placed under the .ssh/ directory in the user’s home directory. If a DSA key is generated it will be named id_dsa and placed in the same location. To change the filename of the generated key, use the -f flag followed by a different filename, like this:


ssh-keygen -f newkeyname

Private keys must be held for authentication by a corresponding public key, and that is the role that the ssh-agent program fills. The ssh-agent program should be started whenever you begin an interactive session (either an X-session or regular login session). ssh-agent can be used to effect automatic authentication when logging in via ssh. The program uses the .ssh/identity file for the private key by default. To specify a different private key, use the ssh-add program. The ssh-agent program can hold any number of keys, thus allowing a user to have several identities. Using ssh-add is simple. To add a key, run the command:


ssh-add filename

If you want to delete an identity from your ssh-agent, run the command:


ssh-add -d filename

Running ssh-add-D removes all identities from the agent.

The last program, the ssh daemon (sshd), is sometimes started at runtime, usually from one of the /etc/rc* configuration files. Although sshd can be started by init, this is not the default behavior of most systems due to the restrictions of the SSH1 protocol — namely that SSH1 requires generation of a host key, which can cause delays. After starting up, sshd first reads its configuration files (see the sshd man page for all of the relevant files) and then begins listening for connections.

Pretty Suite

While this is far from an exhaustive look at OpenSSH, hopefully it has convinced you to start using secure communication tools if you are not already doing so. It would behoove any system administrator (or end user) to replace any insecure connectivity tools with the OpenSSH suite.

If you do implement the OpenSSH tools, be sure to check the OpenSSH project’s Web site periodically for updates, bugfixes, and new features. Remember, when it comes to security, you can never be too paranoid…




Further Resources


This article is a quick introduction to the OpenSSH suite of tools, but it is by no means exhaustive. You may want to check out some of these sites and books for more in-depth information.

The OpenSSH Homepage:


The OpenSSH project homepage contains more information about the project, its goals and history, and pointers to source code. You can also join OpenSSH mailing lists or read the mailing list archives. http://www.openssh.org/

The OpenSSL Project:


OpenSSH depends on the OpenSSL libraries to work. Find out more about the OpenSSL project and its uses beyond the OpenSSH tools. http://www.openssl.org/

The OpenBSD Project:


The OpenBSD Project produces a portable and secure Unix-like operating system based on BSD4.4. The OpenBSD system emphasizes security and integrated cryptography, and offers binary emulation for programs written for Solaris, Linux, HP-UX, SunOS and FreeBSD. You can find OpenBSD and their cute blowfish mascot at: http://www.openbsd.org/

zlib:


The zlib library used by OpenSSH is a data-compression library that is free and unencumbered by patents or legal restrictions. To find out more about zlib, or to get the latest version, visit the zlib homepage. ftp://ftp.freesoftware.com/pub/infozip/zlib/zlib.html

The SSH FAQ


Have a general question about the SSH protocols? Visit the SSH FAQ. http://www.onsight.com/faq/ssh/ssh-faq.html

The Secure Shell Working Group


The Secure Shell Working Group is an Internet Engineering Task Force working group focused on updating and standardizing the SSH protocol. You can get the latest Internet-Drafts of the SSH protocols and subscribe to their mailing list at this site: http://www.ietf.org/html.charters/secsh-charter.html




Key-Based Cryptography

In the world of cryptography, a key is a computer-generated numeric value that cryptographic algorithms (such as RSA and DSA) use for the purpose of encrypting or decrypting data. The key can be of various lengths, with longer keys providing more secure encryption. (You may have heard people referring to 512-bit or 1024-bit encryption — well, they were talking about the length of the key.)

Secure protocols such as SSH use these keys to authenticate users and hosts. (Authentication is the act of insuring that a given host or user is who they say they are, and not an imposter.) There are two types of keys — private and public. There are also two different methods for using those keys to authenticate users and hosts — private key cryptography and public key cryptography.

Private key cryptography (sometimes called symmetric cryptography, because one key of a given length is used to both encrypt and decrypt messages) was the first popular key-based cryptographic method. It involved generating an encryption key and then sharing that key only with people that you trust. Having access to your private key allowed those people to encrypt messages they were sending to you and decrypt messages or data you sent them. The problem with this was that if someone got hold of your private key (which obviously had to be passed around a bit if anyone was going to be able to encrypt or decrypt messages to or from you), or if you lost your private key, anyone who gained access to that key could then read all of your transmissions.

Public key encryption (also sometimes called asymmetric cryptography, because keys of different lengths are used to encrypt and decrypt messages) approaches the problem from a different angle. With public key cryptography, there are two keys in use — a private key that only you use, and a public key that anyone can have access to. The private and public keys are both generated at the same time, using the same algorithm. With this system, if someone wants to send you a message, they encrypt the message by using your public key, and then only you are able to decrypt it with your private key (or vice-versa if you send a message to another person). Private keys are never exchanged or sent over the network. This also makes it possible to identify yourself by signing your e-mail with a digital certificate or signature that can only be decrypted with your public key.

OpenSSH, and other implementations of ssh, use public key encryption to authenticate users and hosts. However, SSH is not the only protocol that operates on these principals. If you’ve ever seen an e-mail or posting that included a public key block, now you know what it is — someone is posting a digital signature that you can use to send that person a message. They (and only they) will be able to decrypt the message with the private key that was generated with the public key they made available to everyone. Likewise, if they’ve sent you a message they encrypted with their private key, you can use their public key to decrypt their message, and be assured that the message came from them and not an imposter.



Joe “Zonker” Brockmeier is a freelance writer and regular contributor to Linux Magazine. He can be reached at zonker@linux-mall.com.

Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62