In the Linux world, the most popular secure login protocol is the Secure Shell (SSH). This protocol uses encryption technology to digitally "scramble" transmissions so that any data that might be intercepted on compromised routers or via packets sniffers can't be descrambled and used, at least not with any technology that's readily available in 2002. (In theory, a fast enough computer could break SSH's encryption, but computers capable of doing this either do not exist or are very rare.)
In 2002, SSH servers are becoming more common, although they're not yet universal. Like other login servers, basic SSH configuration is fairly painless, but there are both startup options and configuration files you may need to adjust to get the system working in precisely the way you want. Understanding something of how SSH operates may help you plan your SSH setup to best effect.
Available SSH Software
There are two major SSH packages for Linux: the original commercial SSH (http://www.ssh.com/products/ssh/), which is produced by a company called SSH, and an open source reimplementation (http://www.openssh.org). Many Linux distributions now ship with the latter, but you can use the former if you prefer. (If you use the original SSH, some uses may require you to purchase a license, but others allow you to use the software for free. Consult the SSH license for details.) Distributions that ship with OpenSSH include Caldera 3.1, Debian 2.2 (in the non-US package set), Mandrake 8.1, Red Hat 7.2, Slackware 7.0, and SuSE 7.3. You can obtain OpenSSH for other distributions, or the latest version if yours is older, from the OpenSSH Web site. For simplicity's sake, I use SSH to refer to any implementation of the SSH protocol, and differentiate this as necessary when referring to specific packages.
In December of 2001, version 3.1 of the original SSH was released. In the same month, OpenSSH 3.0.2 was released. These version numbers are designed to be comparable; the original SSH and OpenSSH products support roughly the same features and cryptographic technologies in their version 3.0. x products, for instance. Version 3 of the SSH protocol adds Public Key Infrastructure (PKI) support, in which digital certificates "signed" by certificate authorities verify the identity of one or both parties in a transaction; smart card support, a hardware-based system of identity checking; and various other enhancements. Because the SSH company developed the protocol, they're likely to lead the OpenSSH project slightly in features.
The original SSH and OpenSSH implementations interoperate , so you shouldn't have to be concerned with who created the clients that your server will serve, or who created a server to which you want to connect. There are occasional incompatibilities between specific versions of the packages, though, even within a single line. The protocol is designed to negotiate the maximum common level of the protocol, so an SSH version 2client can connect to a version 3 server, for example. Of course, such a connection uses the lowest common denominator level of the protocol.
Most OpenSSH packages come as several separate files. Most important are the base openssh package and the openssh-client and openssh-server packages that contain clients and servers, respectively. To use any SSH program, you must install the base package and at least one of openssh-client and openssh-server .
SSH is not yet as widespread a protocol as is Telnet, so you may need to distribute SSH client software for your users. These packages are available for many OSs. You can find links to free implementations of SSH for many OSs at http://www.freessh.org. Many commercial terminal programs for OSs like Windows and MacOS include SSH support, as well. The main problem in using SSH is not in locating the SSH clients, but in distributing them and convincing your users to use them.
Understanding SSH Capabilities
SSH does more than most other remote login protocols, and in more ways than simply providing encryption. Two extra features of SSH deserve special attention. First, it can forward or tunnel network ports between the client and server. This means that the forwarded protocol benefits from SSH's encryption. Depending on your configuration, this may be done automatically for X, so that when you log into an SSH server from a system on which X is running, you can launch X programs without worrying about setting further options. (Chapter 14 covers these matters in more detail.) With some extra work, you can tunnel just about any other protocol you like, providing an encrypted version of that protocol. In fact, it's even possible to use the Point-to-Point Protocol (PPP) to set up a network interface that's tunneled through SSH. The result is a Virtual Private Network (VPN) that's implemented via SSH. The VPN HOWTO document (http://www.linuxdoc.org/HOWTO/VPN-HOWTO.html) covers such configurations in detail.
The second SSH feature that deserves mention is the direct implementation of non-login tools. Specifically, the SSH package comes with a program called scp , which is used for copying files from one computer to another, as follows :
scp [[ user1 @] host1: ] filename1 [[ user2 @] host2: ][ filename2 ]
This syntax is very similar to that of the rcp program, which is an r-command program that scp is intended to replace. Unlike rcp or many other file-transfer tools, such as FTP, scp transfers the files in an encrypted form and encrypts the username and password. Thus, it's a good choice for transferring files between computers over an untrusted network.
For more interactive file transfers, clients can use the sftp program, which works much like the more conventional text-mode ftp program, but uses SSH encryption to protect passwords and the contents of data being transferred. Some GUI FTP clients, such as gFTP (http://gftp.seul.org), also include support for SSH-based transfers, so it's becoming possible for SSH to replace both a Telnet and an FTP server from a functional point of view.
The standard SSH server program ( sshd ) handles both the SSH text-mode login client ( ssh on Linux) and transfers initiated through scp or sftp . This server also handles port forwarding as implemented via ssh . All this traffic passes through the standard SSH port, 22.
Setting SSH Startup Options
Whatever implementation of the protocol you use, the SSH server is traditionally started from a SysV startup script, as described in Chapter 4. Although the server can be run from a super server, older versions of the program imposed a delay when so started because they had to perform some CPU- intensive operations. Modern versions of sshd , run on modern hardware, typically impose very short delays when run from a super server, so if you prefer, you can reconfigure your sshd to run in this waybut be aware you must add the -i argument to the sshd launch command, as described shortly.
The SSH server program, sshd , accepts a number of arguments that can modify its behavior. In OpenSSH 3.0.2, these arguments include:
There are additional options for sshd , most of which relate to setting details of how encryption is to be handled. Consult the sshd man page if you need information on these options.
Before you run sshd for the first time, you need to generate some encryption key files. These files contain the keys used by SSH's algorithms to identify itself and encrypt data. Most SSH distributions include code to check for and, if necessary, generate these keys in their SysV startup scripts for the server. If your system doesn't do this, try using the following commands:
# ssh-keygen -q -t rsa1 -f /etc/ssh/ssh_host_key -C '' -N '' # ssh-keygen -q -t rsa -f /etc/ssh/ssh_host_rsa_key -C '' -N '' # ssh-keygen -q -t dsa -f /etc/ssh/ssh_host_dsa_key -C '' -N ''
Each of these commands generates two keys: a private key used only on the server, and a public key that's given to clients so that they may send encrypted data to the server. The latter is placed in a file whose name is based on the name of the former, but with .pub appended. You can check for the existence of these six files ( ssh_host_key , ssh_host_key.pub , ssh_host_rsa_key , ssh_host_rsa_key.pub , ssh_host_dsa_key , and ssh_host_ dsa_key.pub , all normally in /etc/ssh ) to see if they exist before running these commands. If you overwrite existing keys, it's possible that clients that have already been configured to trust the server with the old keys will need to be reconfigured, so don't replace these keys unnecessarily.
Adjusting the sshd_config File
The sshd server is controlled through a file called sshd_config , which normally resides in /etc/ssh . (The ssh client program uses a configuration file called ssh_config in the same location; don't confuse the two.) This file consists of options and values, each pair on a line by itself, thus:
As with many configuration files, comment lines begin with pound signs ( # ). Some of the options mirror options you can set at startup time via command-line arguments. Others are unique to the configuration file. A default configuration works well enough for many systems, but you may want to review your configuration file, especially for certain security- related options like PermitRootLogin . The most important sshd_config options include the following:
There are many additional SSH configuration options you can set. Some of these relate to alternative authentication methods , others fine-tune options described here, and still others set miscellaneous features. Many default sshd_config files include these options, so you can peruse your file to see how your system is configured. You can also consult the sshd man page for information on these options.
SSH Authentication Options
When an SSH client and server communicate, they encrypt all communications using a variety of encryption methods. In brief, the two servers agree on a temporary encryption method that they use to exchange public keys, which are long numbers that can be used in encryption algorithms to encrypt transmissions intended for each other. Each side also retains for its own use a private key, which it uses to decrypt data received from the other computer. The systems use this technique to encrypt the exchange of another type of key, known as a secret key, that's used for another encryption method. This secret key encryption method, which uses a single key, is faster than the public/private key method used to exchange the secret key. The public/private key method exists to protect the secret key from discovery. SSH also uses a public/private key pair as one of several possible methods of authenticationconfirming that users are who they claim to be, and not malicious interlopers.
Understanding SSH Authentication
From a user's point of view, there are several different methods that SSH may use to authenticate users. The exact details of these methods differ from SSH version 1 to SSH version 2, but the systems attempt to use each of several authentication methods in turn . Specifically:
The server stores its keys in /etc/ssh ; they're used for all users. SSH clients receive public keys from specific servers, so that the client may verify the server's identity at a later date. These keys are stored in a user's ~/.ssh directory, so they're maintained individually for each user. The first time you connect to a server using ssh , the program notifies you that it's adding a new key to the file. (With some configurations, you may be asked to authorize this action.) If the key for the server changes, ssh displays a very noticeable warning message, like this:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
The message goes on to provide further details, and will not connect to the server. If the change was legitimate , you can force a connection by removing the server's entry from your ~/.ssh/known_hosts or ~/.ssh/ known_hosts2 file, depending upon whether you're using SSH protocol version 1 or version 2.
Unlike telnetd , sshd doesn't normally use the /bin/login program to handle logins. Instead, sshd performs this task itself. (The UseLogin option in sshd_config causes sshd to use login , though.) In some sense, therefore, sshd alone is like the combination of telnetd and login . It's this combination that allows sshd to perform public key authentication; only by bypassing login will such alternative authentication methods work.
Generating Keys to Automate Logins or Improve Security
Individual users may also generate keys to uniquely identify themselves . These are stored in the ~/.ssh directory on the client. You can transfer the public key stored here to your ~/.ssh directory on the server to bypass the need to enter a password, which is the normal method of authentication with a default configuration of SSH. Alternatively, this method may be used to increase security by requiring a pass phrase, which in conjunction with the public key itself may make it more difficult for an outsider to break into your account. To use this public key authentication for either purpose, follow these steps:
From this point on, you should be able to connect from the client to the server using version 2 of the SSH protocols. If you didn't use a pass phrase, you'll be able to log in without using a password or a pass phrase, but if you entered a pass phrase when creating your keys, you'll need to enter it when logging in. You can force the SSH client to use version 2 with the -2 option, thus:
$ ssh -2 server
You can follow a similar procedure to enable SSH protocol version 1's RSA authentication. You'll need to implement the following changes to the procedure:
Both of these procedures assume that the server is configured to accept public key (aka RSA) authentication. As described earlier, these options are enabled via the RSAAuthentication (version 1) and PubkeyAuthentication (version 2) configuration options in /etc/ssh/sshd_config .
It should be emphasized that you don't need to enable public key authentication. With a default configuration, using SSH without this option works just fine. Using public key authentication either obviates the need for entering a password, relying upon the integrity of a key file instead, or improves security by requiring both a key file and a pass phrase to gain entry to the system.
Another option for SSH authentication is to use a tool called ssh-agent along with associated utilities. This program manages SSH keys so that you only need to enter an SSH pass phrase once per local session. To use it, follow these steps:
At this point, you should be able to reach your SSH server system by using the SSH client as usual, but you won't be asked to enter a password or pass phrase. The ssh-agent tool works by holding keys in memory and setting environment variables that allow the SSH client to locate ssh-agent to retrieve those keys. Only programs run as children of ssh-agent gain access to its keys, though, which is why this procedure has ssh-agent start a new Bash shell; the shell and all its children, including ssh when it's launched from Bash, can manipulate or retrieve these keys.
For a single connection, this approach can actually complicate matters, because you need to run ssh-agent and use ssh-add to add keys before you can launch ssh , and you'll still have to enter your pass phrase once. If you routinely use SSH to log into several computers using the same key, or if you routinely log in and out of the same system, however, this procedure can save time, because you'll only have to enter your pass phrase once. Furthermore, there are some ways you can streamline the procedure:
Once you've set up ssh-agent and entered a key, you can view the keys you've entered by typing ssh-add -l , or you can delete the keys by typing ssh-add -d . The latter command configures the system so that you must re-enter the keys (or enter a password or key in the normal way for SSH) if you try to use SSH again.
One of the advantages of ssh-agent is that you need not type the key multiple times if you connect to multiple SSH servers. You must copy the public key to each server, as described in Steps 3 through 6 in "Generating Keys to Automate Logins or Improve Security," whereupon you can use the same private key loaded in ssh-agent to connect to each system. If you prefer to use different keys for different systems, you can do so, but you'll need to store them in separate files and type their associated pass phrases when you load each one. If you try to connect to a system on which you've not stored your public key, you'll need to enter a password, just as if you weren't using ssh-agent .