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.
What do you think? Is this useful? Will you use it? Do you have any ways to make it easier or more secure?
Note: I originally posted this on another blog of mine. It’s included here as one in a series of system administration examples, tips and how-tos.
I blogged on hardening SSH @ http://andrusk.com/?p=60. Good stuff and I do use this technique on my home network. Crackers would need to get through about 4 firewalls to get to any low hanging fruit anyways.
@Justin – Thanks for the tips! Security doesn’t always have to be inversely proportionate to convenience. I think SSH is one of those tools with a high convenience/security correlation.
If you’re certain that the remote system doesn’t already have authorized keys, after you generate your public key, you can execute this command:
Of course it must already have the .ssh directory . . .