April 10, 2001, 8:15 PM —
Because Linux is a deep operating system, we often use a miniscule portion of a tool's features. I, for one, use awk primarily to isolate columns that cut can't find, though in fact awk is a full-fledged text-processing language. There's nothing wrong with that approach -- actually it's unavoidable -- but it benefits us to delve more deeply into the advantages a single program can offer.
Presumably you have already installed SSH and are using it to securely log in to remote systems. (If you aren't, please read Jay Beale's article "Stupid, Stupid Protocols: Telnet, FTP, rsh/rcp/rlogin" to see why you should -- see Resources.) However, most people simply connect via SSH, enter their passwords, and type away. They don't realize that SSH has advanced key-management features that allow them to avoid having to retype their passwords; that its port-forwarding options can secure other, normally insecure, packages; and that they can employ little tricks in SSH that would make their lives easier.
There's great confusion at present regarding SSH and the different versions of the software available. (See Resources for more information.) I recommend using the newest version of OpenSSH, 2.5.1p2. At the very least, use OpenSSH 2.3.0p1, as earlier versions had security holes. Several details that I will discuss do not apply to older versions of OpenSSH or to other implementations of the SSH protocol.
Keys to the kingdom
One major benefit of SSH, besides the obvious advantage of cryptographically secure connections, is that it allows you to log on to a server without ever having to type your password. You do have to type a password (only once -- but we'll get to that in a minute), but it doesn't have to be the password for your account on the server, and it will be the same password for every system to which you log in. That is possible through the magic of authentication via cryptographic keys.
Normally, when you log in to a system, you authenticate by entering your password for that system. Your password goes, as it is typed, to the remote system, which authenticates it against the /etc/passwd or /etc/shadow file. By contrast, SSH uses an authentication method with public-key cryptography. (If you are unfamiliar with public-key cryptography, see the link to the PGP Manual in Resources.) Essentially, it's a challenge-response mechanism: You can authenticate against a public key on the server, so when the client connects, the server encrypts a random number with the public key. If the client possesses the private key, then it can decrypt the random number and report it back to the server. That proves to the server that the person logging in has the authorized private key. The private key is further protected when you encrypt it with a password. The password you type to authenticate via public key cryptography is the password for your private key.
That sort of authentication requires you to first generate a pair of public and private keys. The ssh-keygen command does that. Because of the different versions of the SSH protocol out there, OpenSSH 2.5 and higher can generate three different types of keys: rsa1, for compatibility with SSH version 1 clients; DSA, for connecting to SSH protocol version 2 clients using the Digital Signature Algorithm; and RSA, for connecting to SSH protocol version 2 clients using the standard RSA algorithm. You can set the type of key SSH generates with the -t option. Thus to generate your rsa1 public and private key pair, you would run ssh-keygen -t rsa1. For the three key types, the keys generated are by default stored in your .ssh directory beneath your home directory. The rsa1 keys are named identity, DSA keys are named id_dsa, and protocol version 2 RSA keys are named id_rsa. Each key has a corresponding public key with a .pub extension. You want to check the permissions on the private keys and make sure that they're not world-readable; these are secrets not intended for sharing.
