The 101 Uses of OpenSSH: Part II of II

Most people who use SSH never get past its simplest two functions: encrypted remote shells and encrypted file transfers (which is as far as we got last month in this column). That's fine; there's no point in learning features you don't need. But many of you highly self-motivated readers doubtlessly stand to benefit from at least some of SSH's other 99 uses. So let's get down to the really cool features of SSH, specifically those of OpenSSH.

Note: throughout this article I'll use “SSH” to refer to Secure Shell generically, i.e., “the Secure Shell system”. Specific Secure Shell processes will be displayed in fixed-width font and in lowercase, e.g., ssh, sshd, etc. This is consistent with my other articles: if it looks like something you'd see typed at a console-prompt, it probably is.

A complete description of public-key cryptography (or “PK crypto”) simply won't fit in an article that's supposed to be about OpenSSH. If you're completely unfamiliar with PK crypto, I highly recommend the RSA Crypto FAQ (available at http://www.rsasecurity/rsalabs/faq/) or, even better, Bruce Schneier's excellent book Applied Cryptography.

For our purposes here, it's enough to say that in a public-key scheme each user has a pair of keys. Your private key is used to digitally sign things, and to decrypt things that have been sent to you. Your public key is used by your correspondents to verify things that have allegedly been signed by you and to encrypt data that they want only you to be able to decrypt.

Figure 1. Public-Key Cryptography

Along the bottom of Figure 1 we see how two users' key pairs are used to sign, encrypt, decrypt and verify a message sent from one user to the other. Note that Bob and Alice possess copies of each other's public keys but that each keeps their private key secret.

As we can see, the message's journey includes four different key actions: (1) Bob signs a message using his private key; (2) Bob encrypts it using Alice's public key (NOTE: aside from the fact that Bob has probably kept a copy of the original message, he can not decrypt this message—only Alice can); (3) Alice receives the message and decrypts it with her private key; and (4) Alice uses Bob's public key to verify that it was signed using his private key.

Compared to block ciphers such as blowfish and IDEA, in which the same key is used both for encryption and decryption, this may seem convoluted. Unlike block ciphers, for which secure key-exchanges ensure that both parties obtain the key without exposing the key to eavesdropping or other attacks, PK crypto is easier to use securely.

This is because in PK schemes two parties can send encrypted messages to each other, without first exchanging any secret data whatsoever. There is one caveat: public-key algorithms are slower and more CPU-intensive than other classes of cryptographic algorithms such as block ciphers and stream ciphers (e.g., 3DES and RC4, respectively). As it happens however, PK crypto can be used to securely generate keys that can be used in other algorithms.

In practice, therefore, PK crypto is often used for authentication (“are you really you?”) and key-negotiation (“which 3DES keys will we encrypt the rest of this session with?”) but seldom for the bulk encryption of entire sessions (data streams) or files. This is the case with SSL, and it's also the case with SSH.

Key-negotiation is one of the very first things that happens in any SSH transaction, and the thing that enables a relatively weak form of authentication (username/password combinations) to be used. How the Diffie-Hellman Key Exchange Protocol works is both beyond the scope of this article and complicated (for more information, see the Internet Draft entitled “draft-ietf-secsh-transport-07.txt”, available at http://www.ietf.org/). You need only to know that the result of this large-prime-number hoedown is a session key that both parties know but which has not actually traversed the as-yet-unencrypted connection.

This session key is used to encrypt the data fields of all subsequent packets via a “block cipher” agreed upon by both hosts (transparently but based on how each SSH process was compiled and configured). Usually one of the following is used: Triple-DES (3DES), blowfish, or IDEA. Only after session-encryption begins can authentication take place.

But before we dive into RSA/DSA authentication, let's pause for a moment and consider how key-negotiation can be transparent, given that it uses PK crypto and that private keys are usually passphrase-protected. SSH uses two different kinds of key pairs: host keys and user keys.

A host key is a special key pair that doesn't have a passphrase associated with it. Because it can be used without anybody needing to enter a passphrase first, SSH can negotiate keys and set up encrypted sessions completely transparent to users. Part of the SSH installation process is the generation of a host key (pair). The host key generated at setup time can be used by that host indefinitely, barring root compromise. And Because the host key identifies the host, not individual users, each host needs only one host key. Note that host keys are used by all computers that run SSH regardless of whether they run only the SSH client (ssh), SSH dæmon (sshd), or both.

A user key is a key associated with an individual user and is used to authenticate that user to the hosts he or she initiates connections to. Most user keys must be unlocked with the correct passphrase before being used.

User keys provide a more secure authentication mechanism than username/password authentication (even though all authentication occurs over encrypted sessions). For this reason, SSH by default always attempts PK authentication before falling back to username/password.

When you invoke SSH, SSH checks your $HOME/.ssh directory to see if you have a private key (named “id_dsa”). If you do, SSH will prompt you for the key's passphrase and will then use the private key to create a signature that will send, along with a copy of your public key, to the remote server.

The server will check to see if the public key is an allowed key (i.e., belonging to a legitimate user and therefore present in the applicable $HOME/.ssh/authorized_keys2 file). If the key is allowed and identical to the server's previously stored copy of it, the server will use it to verify that the signature was created using this key's corresponding private key. If this succeeds, the server will allow the session to proceed, possibly after also performing username/password authentication.

(Note: the above two paragraphs refer to the DSA authentication used in SSH Protocol v.2; RSA authentication is slightly more complicated but, other than using different filenames, is functionally identical from the user's perspective.)

PK authentication is more secure than username/password because a digital signature cannot be reverse-engineered or otherwise manipulated to derive the private key which generated it; neither can a public key. By sending only digital signatures and public keys over the network, we ensure that even if the session key is somehow cracked, an eavesdropper still won't be able to obtain enough information to log on illicitly.