CurlyShavings

Please note that no warranty is being made here. Even if you follow these suggestions, there's no guarantee that crackers won't flood your network, your systems won't go down and your hair won't turn green. As they say, "Your mileage may vary". Follow at your own risk.

Typing in passwords to jump from one *nix box to another can be a real drag. Even more so when you're on a trusted network segment and you're using SSH (more information here) to get from one hardened server to another. So I decided to do something about it on my own network. Here are the assumptions and requirements.

• all hosts are on a trusted segment (start/local and end/remote)
• all hosts are hardened to one's particular level of satisfaction
• all hosts are using roughly the same level/version/flavor of SSH
• the asymmetric algorithm to be used is the Rivest Shamir Adelman (RSA)
• user keys must be a minimum of 1024 bits
• the start/local system is the local system that the user is typing on and starting from
• the client is sitting on the start/local system
• the end/remote system is the remote system that the user wants to end up
• you've used ssh before on both local and remote systems

How it works

The basic idea is that SSH allows for a public/private key exchange. The local system generates a public/private key pair and the public key is distributed to the remote server(s). It is important to remember that the private key needs (must!) remain private.

When the client (running on the local system) connects to the remote system, it tells the remote system its public key. If this public key is known to the remote system, then some encryption and decryption happens between the two systems to validate that the client does indeed possess the correct private key. (Please see RFC 4252, Section 7 for a full description of the Public Key Authentication Method.) If this checks out, the remote system grants the access without requiring a password.

Please note that this is not the place to defend public/private key encryption. If you have concerns about it, go do some homework until you're satisfied.

What to type

On the local system's home directory,

     ssh-keygen -t rsa -b 1024 -f .ssh/id_rsa

If asked for a passphrase, leave blank. The -t rsa specifies our RSA requirement and the -b 1024 specifies our key length requirement.

Now, in the .ssh directory, you should find two new files: id_rsa and id_rsa.pub. These are the private key and public key (respectively). Copy the public key to the remote machine.

     scp .ssh/id_rsa.pub USERNAME@REMOTE:~/.ssh/id_rsa.pub

Until your public key is in the right location, you'll still need to provide your password.

     ssh USERNAME@REMOTE
     cd .ssh

Now check to see if the file authorized_keys already exists. Older versions of SSH might have (or even require authorized_keys2 rather than authorized_keys. If, when we're done, things don't work, play around with these two possibilities.

Now add the public key to the list of authorized public keys.

     touch authorized_keys
     cat id_rsa.pub >> authorized_keys
     chmod 640 authorized_keys
     rm id_rsa.pub

These last few steps add your new public key to the list of authorized keys. They're written to allow for this file already existing with one or more keys in it. Now exit and then log back in again. If everything was done correctly, you shouldn't be prompted for a password.

Updates

If you're already using a public key, you can "simply" start at copying to the remote server.

Update 20110623: If you'd like to use multiple keys, I found this page to be very valuable.