Some SSH implementations rely on other software packages; these must be obtained and installed first. The precise requirements sometimes depend on the configuration options chosen: e.g., support for hardware authentication devices (smartcards) might require special libraries.

Source code for open source SSH implementations can be downloaded from each project’s web site, and often a large number of mirror sites. Sources for commercial products are sometimes provided on the distribution media, or are available on vendors’ password-protected web sites.

Sources should be distributed with a signature file that guarantees the distribution is genuine and has not been modified. [1.6.2] The precise steps used to verify the signature depend on how the source file was signed.

Always check the signature before installing sources. Otherwise, you can be fooled by a hacked version created by an untrusted third party. If you blindly install a source without checking the signature, you can seriously compromise your system’s security.

Source distributions are almost invariably packaged in compressed tar format.^[37] Filenames ending in .tar.gz (or sometimes .tgz) are compressed using gzip, and can be extracted using a command like:

    $ tar xzvf openssh-3.9p1.tar.gz

If your version of tar does not support the z option for running gunzip automatically, try:

    $ gunzip < openssh-3.9p1.tar.gz | tar xvf -

gzip (and gunzip) can be obtained, if you don’t already have them, from http://www.gzip.org/.

Similarly, filenames ending in .tar.bz2 are compressed using bzip2, and can be extracted using a command like:

    $ tar xjvf openssh-3.9p1.tar.bz2

If your version of tar does not support the j option for running bunzip2 automatically, try:

    $ bunzip2 < openssh-3.9p1.tar.bz2 | tar xvf -

bzip2 (and bunzip2) can be obtained from http://sources.redhat.com/bzip2.

In all cases, the result is a new subdirectory containing all files in the distribution. The name of the source directory is usually the same as the tar file, e.g., openssh-3.9p1.

To list the contents of the tar file, without extracting, use the t option instead of x; for example:

    $ tar tzvf openssh-3.9p1.tar.gz

Most SSH implementations have dozens of configuration options you can set at compile time. It’s a good idea to carefully consider each one, instead of blindly accepting the defaults. In fact, the flexibility provided by this compile-time configuration process is a primary motivation for installing from source distributions.

Compile-time configuration is performed by running a script named configure that is usually found in the top-level source directory.^[38] Roughly speaking, the configure script accomplishes two tasks:

We’ll discuss only the second task, since it’s SSH-specific, and cover only the configuration options that are directly related to SSH or security. For example, we won’t cover options that relate to the compiler (e.g., whether warnings should be printed or suppressed) or operating system (e.g., whether particular Unix library functions should be used). To see the full set of configure options, use the command:

    $ configure --help

Also, read the installation documentation, which is often found in files named README and INSTALL in the source directory.

The behavior of SSH servers can be controlled at three levels. The first is compile-time configuration as discussed in this chapter. In addition, serverwide configuration (Chapter 5) controls global settings for a running SSH server, and per-account configuration (Chapter 8) controls settings for each user account accepting SSH connections. Figure 4-1 illustrates where compile-time configuration fits into the whole spectrum. We’ll remind you of this picture each time we introduce a new type of configuration.

Compile-time configuration affects both the SSH server and client programs. Changing the configuration requires recompiling and reinstalling, which is neither easy nor convenient, so for most aspects of server and client operation, it’s more appropriate to edit configuration files after installation. Nevertheless, there are some good reasons to use compile-time configuration:

The configure script accepts command-line flags, each beginning with a double dash (--), to control its actions. Flags are of two types:

Flags beginning with --with or --enable may optionally be followed by an equals sign and a string value, such as:

    --with-etcdir=/usr/local/etc
    --enable-X11-forwarding=no

Various string values are used, but the most common are yes and no. For a given package P, the flags --with- P and --with- P = yes are equivalent. The following table illustrates the relationship:

This next table shows the relationships for a given feature F :

In the sections that follow, we show many examples of configure with different command-line flags. Most examples demonstrate only one flag at a time, but keep in mind that other flags might be present on the command line. The proper way to run configure is just once, before compilation, with all desired flags on the same command line.

The configure script uses directory information from its own location to embed pathnames into the Makefiles, header files, etc., that it creates. Relying on the PATH environment variable to find the configure script is therefore a bad practice. If you choose to compile within the source directory, specify the current directory explicitly when you run configure:

    $ ./configure ...options...

Alternately, you can compile in a different directory, which is convenient if the source directory is used for multiple platforms. To do this, create a separate, empty build directory, and run configure there, specifying the source directory for the configure pathname:

    $ mkdir -p /elsewhere/build/ssh
    $ cd /elsewhere/build/ssh
    $ /somewhere/src/ssh/configure ...

In our examples, we’ll omit the directory components from the configure pathname, but remember that they should be included when you run the script.

This is simple—just type:

    $ make

Compiling can take a while, depending on the speed of your system.

The make command should be run in the same directory where the configure script ran.

You need root privileges to install files in system directories, which is the usual location:

    $ su
    Password: ********
    # make install