Building everything

The three packages have to be built in order, and we do them each in turn:

We chose the arguments to ./configure by feeling around, and we think this is the right set for our environment. These instructions have been working for us on a number of systems.

--with-ipv4-default appears to tell SSH to use only IPv4 -- "regular" internet addresses -- instead of the next-generation IPv6 addresses. We're not sure if this is required or not.

--with-md5-passwords enables the better password hashing as found in Linux, and it probably isn't required on other systems or if you only use RSA authentication.

We suspect that --with-pam might also be useful, but so far the system is working fine for us without it.

NOTE - for recent releases of OpenSSH, this is where the sshd user and group should be added to support privilege separation. See the end of this document for the details.

Install Everything - First Time

If this is a first-time installation of the Secure Shell on this system, it's safe to just do a make install in the OpsnSSH area and it will drop its files in the proper places.

But if there is a working SSH installation then it's wise to go find the key setup files and save them off to the side first. This installation also parks files in different target directories than the older one we used, so it's wise to poke around and save or delete the old stuff. We typically look in these directories:

Pay particular note to the ssh_config and sshd_config files, which define important server and client options. Save these files to the side.

It's also wise to keep an alternate method of accessing the system, such as the console or telnet, until you're really sure that you have gotten SSH installed properly. It's a drag to find (for instance) that sshd doesn't start properly on a reboot when you have no keyboard or monitor attached to the server under the desk. Been there, done that.

Once these precautions have been taken, do a make install in the SSH source directory, and it will put everything where it belongs.

Post-Install Configuration

Once SSH is installed, there are still a few configuration steps required. We're really not terribly strong with this, and in any case cannot provide a tutorial for SSH here. But we will note a few things that ought to be attended to after upgrading secure shell.

• • Insure that sshd gets launched properly at system startup. In our installation, the daemon is located in /usr/local/sbin instead of/usr/local/bin, and the /etc/rc.d/init.d/sshd script has to be modified to reflect the proper location.

    • The file we use lives in /etc/rc.d/init.d/sshd, and it contains:

• • • Once this file is in place (in /etc/rc.d/init.d/sshd), it has to be linked into the proper positions in the other runlevels so it actually: gets called. This is most easily done with the chkconfig program that manages the startup and shutdown locations in the various run levels.

• • • If you prefer to do it yourself,

Creating OpenSSH public keys

The ssh-keygen program is used to create a public key pair suitable for OpenSSH client and server use (there are other mechanisms for creating keys, we'll touch on the m later). It's possible to create both "user" and "host" keys, but since the host keys are usually created during the software installation process, we'll only touch on the user key.

There are many options for creating public key pairs, but we only care about making SSH version 2 RSA keys. This command creates the key pair, prompts for a pass phrase to encrypt the private key, and stores the two files in your ~/.ssh directory:

-b 1024 specifies the number of bits to encrypt the key, and the consensus is that 1024 is fine: larger values just slow things down without adding appreciably to security. -t rsa specifies to use RSA encryption to produce an SSH version 2 key (the default is to create a version one key - bad news). It prompts for a filename to store the keys in (usually OK to keep the default), then asks for a pass phrase twice.

Choose a good pass phrase! Your private key is not very private if the very secret id_rsa file can be compromised.

Running the command should look like this:

Now the files ~/.ssh/id_rsa.pub and ~/.ssh/id_rsa contain your public and private keys, respectively. We'll use them shortly. The public key file is one line of ASCII, and it looks like this (though it's actually all one line):

Again, there is no need to keep a public key secret.

Configuring incoming SSH public key access

When the ssh server is considering an incoming connection request via the public key mechanisms, it consults the ~/.ssh/authorized_keysfor version-2 keys (we're specifically ignoring version-1 key support).

To enable a remote user to the local OpenSSH server, simply edit the user's ~/.ssh/authorized_keys file and append the user's public key -- one line -- to the file and save it. Do make sure that the file is owned by the user and is not readable by anybody else, but there is no need to restart the OpenSSH server to make it take effect.

Then, from the remote system, connect with the ssh command and the name of the remote host.

The first time you contact any host, you'll be warned that your local SSH installation doesn't know about the remote. When you confirm that you want to connect to it with yes, the name and fingerprint of the remote host is added to the ~/.ssh/known_hosts file. Then you won't be prompted again for this host.

After confirming the host, you'll enter your passphrase to decrypt your private key. If done correctly, the SSH client and server exchange your key information, and if all is well you're granted access to the remote system.

There is no reason that a single public key can't be put in multiple user accounts on the remote system: it's possible to store your public key in both /home/steve/.ssh and /root/.ssh directories. So logged in as a regular user, we can login as root on the remote system:

Using VanDyke SecureCRT with OpenSSH

We use the fantastic telnet/serial/SSH client SecureCRT (from VanDyke Software) to connect from our Windows (ME/NT/2000) boxes to OpenSSH, and setup is straightforward.

After SecureCRT is installed on the Windows box, a pair of public/private keys must be created. From the menu, select Options:Global Options, and from this dialog box select SSH2, then click Create Identity File. Key creation is done just one time after installation. NOTE: these instructions are for SecureCRT v4.x.

Click Next in the Key Generation Wizard, then select an RSA - not DSA - key and click Next. In the next dialog box, enter your pass phrase (twice), then a comment that appears in the file. By convention this is your email address, but it can be any descriptive text that helps you identify the key. Then click Next.

In the next dialog box, select 1024 bits for the key and click Next. Then you are invited to move the mouse around: this provides important random inputs that help generate a key pair that will be hard to crack. This takes perhaps 30 seconds, and when finished you are asked to clickNext.

In the final dialog box, you're asked to save your key files somewhere. It's not as important exactly where they go as long as you remember where that place is. You will need the public key file shortly. For our example we are using C:\identity.pub.

After the key has been generated, locate the public key file and get it over to the UNIX system. Since this file is small and ASCII, it's often easiest to open it in notepad, select the whole thing, and "cut" it into the Windows notepad. Then, logged into the remote server (perhaps with telnet or via ssh using a password), and pasting it into a file. For instance:

Remember that the entry is one line, so you might need to use your favorite editor and join them together if pasting created multiple lines.

Once the file is over on the UNIX system, it has to be converted from the SecureCRT format (some kind of standard) to that used by OpenSSH. The ssh-keygen command is able to do this conversion for you:

Now your SecureCRT public key is installed, so you should be able to ssh into your UNIX box from Windows.

Post-public key configuration

Once the public key mechanisms are known to be working correctly, including testing of proper restart after reboot, we recommend some additional steps.

Disable telnetd

Even with TCP wrappers limiting the IP addresses of incoming connection, we believe that telnet is just too dangerous to leave running. So we disable telnetd in the /etc/inetd.conf file by commenting out this line

We believe that newer systems use the xinetd.conf file, but we don't have this on any of our systems: the idea ought to be similar.

Now telnet won't accept connections any longer. The brave and determined might actually remove the telnet daemon altogether. We've done this on most of our systems.

Disable PasswordAuthentication option

The only nonstandard file is sbin/generate-ssh-keys, which is a small shell script we have created: it simply creates the three key pairs that are required. Run this program one time after installation to create these keys.

Host Key Generation

The SSH daemon requires its own set of host keys, and these are created as part of the installation process. But when the binaries are copied to another machine, the keys must be generated manually. As with all keys, these are created with the ssh-keygen program, and the three sets of keys are created with:

References

This entire Tech Tip is very lame in comparison with the excellent O'Reilly book SSH, The Secure Shell: The Definitive Guide (2e), which covers everything in much more detail. Once you've gotten a handle on the basic configuration of OpenSSH, we recommend picking up this book to get to the finer points. We'll update our document as we pick them up ourselves.

Upgrading for the ZLIB problem

There has been a problem reported in the ZLIB compression library that has prompted version 1.1.4. We've installed this and found it easy to do.

• Fetch the updated ZLIB tarball: zlib-1.1.4.tar.gz from the ZLIB home page.

  • Unpack, build, and install the source:

• • Edit the OpenSSH version file. In the OpenSSH directory is a file version.h, and we want to remind ourselves that we've made this fix even though we haven't actually patched OpenSSH directly. So we tack a z to the end:

• • Rebuild OpenSSH. We first do a "make clean" to force the changes to take effect:

• • • The resulting sshd file is left in the current directory.

• • Install sshd. Doing make install updates everything, and we're not sure this is really necessary. So we just manually copy the file to the final place. Then we look for the "parent" SSH daemon (the one with the PPID of 1) and send it the hangup signal. Then restart the daemon.

Portability Notes

We've managed to build OpenSSH on several other platforms with more or less the same instructions for Linux, but a few notes might be helpful here.

SCO UNIX 5.0.6 with SCO cc

This took a while to get around some build issues, but we ultimately got it working just fine.

• zlib-1.1.4 built and installed without incident

• openssl-0.9.7 required that we edit the Configure file and find the line for "sco-cc". Remove -lresolv from this line - we didn't find this file on our system, and our attempts to build BIND9 on this platform failed due to the lack of a "long long" integer type. Then build, test, and install per instructions.

• openssh-3.5p1 fails the "configure" process because the default cc output is COFF, not ELF. So the command to set this up is./configure --with-ipv4-default CC="cc -belf". Then build and install per the usual instructions.

SCO UNIX 5.0.5 with GNU cc

This built and installed with the above instructions excepting configuring OpenSSH itself (SCO doesn't use MD5 shadow passwords).

We installed the startup file in /etc/rc2.d/S99sshd. This information built as of:

• zlib-1.1.4

• openssl-0.9.6d

• openssh-3.2.3p1

The sshd privsep user directory must be created manually with all the right permissions lest it complain about the modes.

Sun SOLARIS 2.7

This likewise built with the same procedure with the exception of the the OpenSSH configuration itself:

# cd openssh-3.2.2p1

# ./configure --with-ipv4-default --with-pam

Built with:

• zlib-1.1.4

• openssl-0.9.6d

• openssh-3.2.2p1

Privilege Separation

Starting with OpenSSH 3.3.2, the privilege separation feature was introduced. This is a security provision that goes a long way to forestall full system compromise even if a vulnerability is found. The details are covered elsewhere, and our favorite is here.

But before SSHD is installed, both a sshd user and group must be added, and it looks in the password and group files like this:

Under Red Hat Linux 7.2, these commands do the trick:

The -M parameter suppresses creation of the home directory, as this is done by the "make install" procedure for OpenSSH.

Note further that the UsePrivilegeSeparation yes option must be set in the sshd_config file - this may be the default for new installations, but upgrades don't usually touch current values. Make sure this option is set.

Related Resources

• Unixwiz.net Tech Tip: An Illustrated Guide to SSH Agent Forwarding

• Unixwiz.net Tech Tip: Secure Linux/UNIX access with PuTTY and OpenSSH

• VanDyke Software - SecureCRT