SSH
From Software By Jeff
Using SSH has all kinds of benefits. You can tunnel through firewalls to do all manner of helpful things. (Of course, we don't approve of malicious things.)
When you're on your local machine, and you want to get to a remote machine, and you type ssh user@hostname.domain.ext it can be annoying to get prompted for a password, especially if it's a host you use a lot.
SSH has easy self-authentication using encrypted keys. This isn't a discussion of SSH encryption, PGP, or anything like that. It's just a step-by-step on how to get your server set up to accept your client's connection without a password.
This can also help when using RSH commands as they piggy-back on SSH and with this authentication you can do rcp filename user@host.domain.ext:/path/file and the password-less authentication will protect you from the annoyance of the password.
| Table of contents |
Assumption
First, we assume you're using some native SSH client and a common SSH server. The program and directory names may be different for you, depending on your specific client and server. Generally this works for Mac, LINUX, Solaris, BSD, and Cygwin with little modification. Windows with programs like PuTTY or other command-line SSH might work differently, and that won't be addressed on this first pass.
Additionally, we assume you're authorized on the machine you're trying to do this to. Once you get this set up, you can use the same client key no matter which client; we don't suggest this approach, and we'll note why when we get to that bit. You will need to SSH into the server as part of the process, so this is a safe assumption.
If you can SSH using ssh user@hostname.domain.ext at a command prompt, with your remote username, to the correct host (not the fictitous one), our assumptions will be pretty well met.
Client Setup
In your favorite shell window, enter the command ssh-keygen -t rsa -C user@localhost.domain.ext using your local username and fully-qualified system name.
Technically, the -C comment is not required, and will default to your username@hostname. We recommend using the -C with the fully-qualified domain name as some systems don't provide the full domain name with the hostname. This can be a bother if you move to multiple locations and end up with the same computer name; for example, the default setup of Ubuntu tries to name the system ubuntu--which can be a bother if you do this at home and at the office and don't think about accessing a third machine with this method.
While the comment doesn't technically need to be different for each client from which you'll use, it does help when it comes time to clean up the server and disallow the access from that client.
The ssh-keygen program will prompt you for a file location; typically the location it suggests is the one that SSH will use when it looks for your side of the key-pair. If you have other reasons for moving the directory, do so, but usually the default will suffice.
The next thing ssh-keygen does is prompt you for a passphrase. This is where things get tricky. You can provide a passphrase, but then every time you use the key you'll have to provide it to allow SSH to decrypt the key. Not much different than providing a password. It's a little more convenient, however, than trying to keep all of your passwords synchronized; if you have different passwords on different systems, you can generate keys with the same passphrase, therein reducing what you have to remember.
Since this is a discussion of how to use SSH without a password, don't use a passphrase.
Confirm your passphrase (or lack of one), and ssh-keygen will create two files for you. In your ~/.ssh directory you'll find something like id_rsa and id_rsa.pub have been created. They are the two key-pairs necessary to authenticate you using the SSH authentication.
That's it for the client side requirements. Leave the ~/.ssh/id_rsa file alone. Depending on how you want to propogate the id_rsa.pub key you might want to put it in other locations; copy that file, don't move it. If you lose the file you'll have to recreate and redistribute your keys.
Server Configuration
The ~/.ssh/id_rsa.pub key is a simple one-line file of gibberish. Here's one generated for the article (and trimmed for further obscurity and readability):
ssh-rsa AAAAB3...1yAuy4gC28...nhYH...3t/tqGPqS+...xhPuVOZ8= user@host
Whee!
This one line of text needs to end up on the server in your ~/.ssh/authorized_keys file.
Use whatever method you find comfortable for moving files and text between systems, and whatever editor you like. Here's a quickie three step way to do it in one command window.
cat ~/.ssh/id_rsa.pub Select and copy into your system's buffer the whole line (on most X systems, highlighting it can be enough--KDE and Gnome allow you to right-click and copy, like Windows and Mac do).
ssh user@host Login to your remote system.
vim ~/.ssh/authorized_keys Edit the file on the remote system, paste the line to a new line in the file (X allows middle-click--for the others, right-click and paste), saving the file when you're done.
Make sure that the pasted line is the same that you copied, and that you didn't paste something else from your clipboard. Also make sure the line is actually one line in the resulting file, or the key won't be recognized by the server.
That's it. Test it by disconnecting and issuing the ssh user@host again. You should bypass the prompt for a password.
Alternative Method
The id_rsa.pub file is safe to move around. If you put the file in a convenient to retreive location (i.e., served by a web server, or on a system supporting remote copy), you can prepare a server without the cutting and pasting.
Something like this would work, too:
cd ~ Do NOT go to the .ssh directory!
wget http://keystoreserver/~username/id_rsa.pub Get the remotely hosted key. Also rcp user@remoteclient:/home/.ssh/id_rsa.pub . works, if the system's exposed (many firewalls stop rcp).
cat id_rsa.pub >> ~/.ssh/authorized_keys Add the line to the correct file.
rm id_rsa.pub Stay tidy...
This is an excellent way of configuring a server as an afterthought. You've already logged into the server, probably for the too-many-th time in one sitting, and think to do it. Rather than log out, copy the text, and log back in to edit, just do the bits above, and the next time you connect you'll be password-free.
Removing authentication
When you're done using a system, it's a good idea to remove the keys that allow passwordless authentication. Once you've established the authentication, it doesn't matter what the password becomes on the remote system; the keys provide a way around that authentication.
On the server, simply find the appropriate line in the ~/.ssh/authorized_keys file and remove it. From that moment forward, that system will require a password again. This is a must-do!
On the client, simply remove or recreate the ~/.ssh/id_rsa file. Note that this only works for that system.
Security Gotcha
As mentioned, you can use the same key-pair for multiple systems; people do it 'cause they're too lazy to generate keys for different systems.
You'll note that the id_rsa file is protected so that only the user that created it can access it; keep it that way. Don't share this file! If someone were to get your id_rsa file, they would be able to connect to your servers, as you, without knowing your password.
The idea is to copy the information in the id_rsa.pub to multiple servers, not move the id_rsa to other systems. This does work, but it is poor management.
Make sure to remove the key-pair line from the authorized_keys when you're done with the server, and it will render all copies of the id_rsa file useless.
SSH Differences
If you use SSH2 on your server or client, the file you need to modify on the server might be ~/.ssh/authorized_keys2 or even the ~/.ssh directory might be ~/.ssh2 depending on the installation of SSH on the system.
Conclusion
That's about it. Using the simple steps of ssh-keygen and a little text file editing you can seamlessly move from machine to machine.
Now set up an alias (if you use Bash) like alias hostname='ssh user@hostname.domain.ext' and you'll be able to do it in one word! Of course, don't use hostname but instead the name of the server to which you connect...hostname is already useful...