6.4 Secure Shell (SSH)

6.4 Secure Shell (SSH)

The secure shell (SSH) is now the de facto standard for remote logins to other machines. It replaces old, insecure programs like telnet and rlogin. In addition to being a good example of a stand-alone server (for the purposes of this book, at least), SSH has these features:

  • Encrypts your password and all other session data, protecting you from snoopers.

  • Tunnels other network connections, including those from X Window System clients. Tunneling is the process of packaging and transporting a network connection using another network connection. The advantages of using SSH to tunnel X Window System connections are that SSH sets up the display environment for you and encrypts the X data inside the tunnel.

  • Has clients for almost every operating system.

  • Uses keys for host authentication.

OpenSSH (http://www.openssh.com/) is a popular free SSH implementation for Unix. The OpenSSH client is ssh and the server is sshd. OpenSSH uses public key cryptography for authentication and less complex ciphers for its session data. SSH does not come without its disadvantages; in particular, you need the remote host's public key, and you do not necessarily get it in a secure way (however, you can check it manually if you think you're being spoofed). If you would like to know how cryptography works, get your hands on Applied Cryptography [Schneier].

There are two main SSH protocol versions: 1 and 2. OpenSSH supports both, with version 2 being the default.

6.4.1 Installing OpenSSH

You can install a precompiled binary version of OpenSSH, such as an .rpm file in a Red Hat distribution, or you can get the "portable" source code from the OpenSSH Web site to install from source. If you install from source code, you need a version of the SSL (Secure Socket Layer) library, preferably OpenSSL.

In either case, you need to know your OpenSSH configuration directory — it's usually /etc or /usr/local/etc. If you install from source code, you can override the default configuration directory by using the --sysconfdir=dir parameter to configure (see Chapter 9 for more information on compiling software from source code).

6.4.2 The SSHD Server

To run sshd, you need a configuration file and host keys in the configuration directory. The configuration filename is sshd_config. It's easy to confuse this filename with the client's ssh_config setup file, so look out. You shouldn't need to change anything in sshd_config, but it never hurts to check.

The file consists of keyword-value pairs, as shown in this fragment:

Port 22
#Protocol 2,1
#ListenAddress ::
HostKey /usr/local/etc/ssh_host_key
HostKey /usr/local/etc/ssh_host_rsa_key
HostKey /usr/local/etc/ssh_host_dsa_key

Lines beginning with # are comments. Many comments in your sshd_config may indicate default values. The sshd_config(5) manual page contains descriptions of all possible values, but these are the most important:

  • HostKey file Uses file as a host key (host keys are described shortly).

  • SyslogFacility name Logs messages with syslog facility name.

  • LogLevel level Logs messages with syslog level level.

  • PermitRootLogin value Permits the superuser to log in with SSH if value is set to yes; set value to no if you do not want to allow this.

  • X11Forwarding value Enables X Window System client tunneling if value is set to yes.

  • XAuthLocation path Provides a path for xauth; X11 tunneling does not work without xauth. If xauth isn't in /usr/X11R6/bin, set path to the full path-name for xauth.

Host Keys

OpenSSH has three different host key sets: one for protocol version 1, and two for protocol 2. Each set has a public key (with a .pub file extension) and a private key (with no extension). Do not let anyone see your private key, even on your own system. If someone gets your host's private key, SSH provides no protection against password snooping. SSH version 1 has RSA keys only, and SSH version 2 has RSA and DSA keys. RSA and DSA are public key cryptography algorithms. SSH version 2 provides both because there are always debates over which one is better.

The key filenames are as follows:

Table 6-1: OpenSSH Key Files


Private RSA key (version 2)


Public RSA key (version 2)


Private DSA key (version 2)


Public DSA key (version 2)


Private RSA key (version 1)


Public RSA key (version 1)

Normally, you do not need to build the keys, because the OpenSSH installation program should do this for you. However, this isn't always a given, and you may need to know how to create keys if you plan to use programs like ssh-agent.

To create SSH protocol version 2 keys, use the ssh-keygen program that comes with OpenSSH:

ssh-keygen -t rsa -N '' -f ssh_host_rsa_key
ssh-keygen -t dsa -N '' -f ssh_host_dsa_key

For the version 1 keys, use this command:

ssh-keygen -t rsa1 -N '' -f ssh_host_key

The SSH server (and clients) also use another key file, ssh_known_hosts, which contains public keys from other hosts. If you intend to use host-based authentication, the server's ssh_known_hosts file must contain the host keys of all trusted clients.

Starting the SSH Server

Running sshd as root starts the server. You may put this in an init.d script to start at boot time. There is also a way to start sshd from inetd, but this is usually not a good idea, because the server occasionally needs to generate key files, and this process can take a long time.

sshd writes its PID to /var/run/sshd.pid, so you can terminate the server at any time with this command:

kill `cat /var/run/sshd.pid`

6.4.3 The SSH Client

To log in to a remote host, run this command:

ssh remote_username@host

You may omit remote_username@ if your local username is the same as on host. You can also run pipelines to and from an ssh command.

The SSH client configuration file is ssh_config, and it should be in the same place as your sshd_config file. As with the server configuration file, the client configuration file has key-value pairs, but you should not need to change anything in there.

The most frequent problem with using SSH clients occurs when an SSH version 1 public key in your local ssh_known_hosts or .ssh/known_hosts file does not match the key on the remote host. Bad keys cause errors or warnings like this:

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:12
RSA host key for host has changed and you have requested
strict checking.
Host key verification failed.

This usually just means that the remote host's administrator changed the keys, but it never hurts to check with the administrator if you don't know. In any case, look at this line of the preceding message:

Offending key in /home/user/.ssh/known_hosts:12

This tells you exactly where the bad key is: line 12 of a user's known_hosts file. If you do not suspect foul play, just remove the offending line or replace it with the correct public key.

SSH File Transfer Clients

OpenSSH comes with replacement programs for rcp and ftp called scp and sftp.

You can use scp to transfer files from a remote machine to your machine, the other way around, or from one host to another. It works much like the cp command. Here are some examples:

scp user@host:file .
scp file user@host:dir
scp user1@host1:file user2@host2:dir

sftp works much like the command-line ftp client, with get and put commands. The remote host must have a sftp-server program, but this shouldn't be a problem if the remote host also uses OpenSSH.

SSH Clients for Non-Unix Platforms

There are SSH clients for all popular operating systems. The index at the OpenSSH Web page (http://www.openssh.com/) gives a full list, but you may wonder which one to choose for Windows or the Mac. PuTTY is a good Windows client that includes a secure file-copy program. MacSSH works well for Mac OS 9. Mac OS X is based on Unix and includes OpenSSH.