I’m starting out simple. No, really. I can’t imagine that anyone who does system administration isn’t already using ssh to replace r[shcplogin], telnet, ftp, and to secure a whole host of other protocols using tunneling, but when I talk to other geeks (or shoulder surf as they work), I’ve noticed that a lot of them don’t seem to realize the flexibility that comes from using keys to log in to ssh. So here’s a quick rundown of the benefits (to me):
- I don’t have to type my password in 5000 times a day, as I hop from machine to machine. My laptop and my desktop both have one key on them, and all of my core servers have another key for my account, and between these two, I mostly only enter my password to unlock the desktop or laptop.
- For systems with equivalent security levels, I can put an ssh key on the root account of one (or all) of the systems, and allow it to log in to all the others via scripts/cron/etc without human interaction. When I say equivalent security levels, allow me to explain: I do this mostly on systems which don’t store differing levels of important data, which share the same physical access, and for which I have a reason to have them communicate. For example: a teaching lab with a small compute cluster ~ the head node has root access to all of the compute nodes.
- With less worries about security, relatively unprivileged service accounts can share a common ssh key to automate routine communication between systems — I use subversion to distribute a variety of data, and allowing an svn account to do svn+ssh:// pulls from a cron job is very useful. Liekwise, my webservers all have shared keys for the www account, so they can push and pull data directly. If I gave www sudo access to apachectl, then they could also restart each other’s httpd processes as needed, but so far I haven’t found much use for that.
- So what if you ARE worried about security, and you have less trusted systems that you want to have access to more trusted ones? Passphrases can help to secure ssh keys, and a great deal of scripting is still possible. Essentially, keys can be encrypted with a passphrase, and unless that phrase is entered, the key is useless. So the key can be stored in an insecure area — hell, with a good enough passphrase it can be lost — and the key’s access will remain secure at least until someone cracks the passphrase. How do you automate this? With ssh-agent and ssh-add, a pair of utilities that allows a computer to store your ssh key’s passphrase as long as your unix session is active. So as an example, I have a backup script that runs for about 5 days at the beginning of every month (lots o’ data, not so much bandwidth). In the script, I first check to make sure I’m running within screen, then I load ssh-agent, and use ssh-add to ask for the passphrase. This all happens right at the top of the script. Hours pass as the backups are taken, and then days go by between file transfers, but the files are copied securely and automatically, without me having to be there for the entire process. Most importantly, no one who doesn’t have the passphrase can do anything harmful with the script, and as soon as the copies are done, the passphrase is wiped from memory.
So, on each one of those points, I really felt a need to put a footnote or two, mostly about security. Basically, though, it boils down to this: unless you’re using an one time password system or some sort of hardware security module, you have to trust root on the computer you’re using. For that matter, you generally have to trust root a little bit even in those cases. SSH keys can improve security a lot, but they aren’t completely unbreakable. The computer you’re using could have a keylogger installed to capture your passphrase, and it’s pretty trivial for root to grab your ssh key. In short: don’t try to do system administration from untrusted systems. Period. I trust my laptop, I trust my desktop, and I trust most of my servers most of the time, but that’s about it. If I’m away from work and away from my computers, I prefer to make a phone call and walk a coworker through a task rather than doing it myself from, say, a kiosk. Another option is to use a bootable live-cd, which I’ve done on rare occasions in the past. Okay, maybe I’ve convinced you that ssh keys are useful tools in the right circumstances; so how do you get started?
- First, on your trusted client system, use ssh-keygen to create a key encypt it with a passphrase. Do the passphrase thing — if you find it to be onerous, you can always take it off later, and you don’t have to redeploy the key. If you REALLY don’t want a passphrase, just leave it blank. This will create two files, by default ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub. The first of these is the private key; the file that is encrypted with the passphrase, and the one that should be safeguarded.
- The other file is the public key, which should be appended to the ~/.ssh/authorized_keys file on any system you want to connect to. If you don’t already have any ssh keys, you can just rename or copy the file. Otherwise, each key is stored on one (very long) line in the file, and typically has a text field at the end signifying where the key was created to help with identification. For the most part, I leverage our shared home directory structure at work to make sure keys are distrubuted, but in cases where accounts have local home directories, I make other arrangements. For occasional one-off systems, I copy the keys using sftp with (gasp) password authentication. For other situations, I incorporate key management into the rest of my automation. So, for the teaching lab cluster I mentioned above, I distrubute the keys using puppet, another one of my system configuration tools, which uses its own PKI setup to keep everything on the up-and-up.
- If you’re using a passphrase and want to store it, load up ssh-agent. This is a slightly odd utilty because it’s designed to run from a variety of environments (X, terminal, etc). Read the docs on the best way to load it for your situation, but from a terminal, “eval `ssh-agent`” will usually do the trick. You should see a single line of output that resembles “Agent pid #####” if you did it corretly. If you see three or four lines of output, you probably did something wrong — note the backticks above!
- Finally, run ssh-add which will prompt you for your passphrase. Once you enter it correctly, your key will allow you to log in without prompting to systems which have your public key installed.
- When you’re done, “ssh-agent -k” will kill the session.
