Howto: Single Purpose SSH Keys
You have a job (such as a backup, or perhaps you're paranoid about SNMP and wrote your own status checker using ssh) that a remote machine needs to run automatically, but you don't fully trust the machine to be secure (or the operator to be honest). The idea of giving a complete shell - especially one with sudo access to do your backup job - and key over to an untrusted entity just doesn't leave you sleeping well at night.
Single purpose SSH keys are designed for exactly this behaviour. I'll bet you weren't aware you can modify a normal SSH key to enforce a rudimentary access policy on the shell using nothing more than ssh did you? It's a piece of cake:
-
We're going to create a regular DSA key as usual. If you have a different crypto mechanism in mind, just swap it out here, it's all the same stuff:
ssh-keygen -t dsa -f ~/.ssh/uptimeIf you want to secure access for a remote machine-run job, you'll need to use a blank passphrase (that means just hit return, if you're not really familiar with keygen), but if you want a remote user who's very limited, you'll probably still want a passphrase.
-
Now, we edit the public portion (.ssh/uptime.pub) of the key (the part that you will keep on the server), and add the following at the beginning of the line:
command="hostname && uptime",no-port-forwarding,no-X11-forwarding,no-agent-forwarding...right before the
ssh-dsspart (make sure there's a space, and don't put a final comma!) and then save the public key file. Ensure the entire thing is on one line, or you'll probably break the entire file and render all keys useless. -
Append the public file to the server's
.ssh/authorized_keys2file, and if necessary securely transport the private key to all clients that need it. You can append the file like this if you wish:cat ~/.ssh/uptime.pub >> ~/.ssh/authorized_keys2-or-
cat tempfile | ssh somehost 'sh -c "cat - >> ~/.ssh/authorized_keys2"' - Now you're done with the setup!
Using your keys with (Open)SSH
The ssh client will allow you to specify a key to use when you use the -i parameter:
ssh -i ~/.ssh/uptime somehost
I personally don't recommend adding it to your id_dsa file unless this account is strictly an account for that one purpose.
Using with putty
- Using these keys with putty is a piece of cake, but you have to make a few changes. Firstly, you may need to generate the keys with PuTTYgen (there are instructions on this elsewhere if you can't figure it out) and upload the private portion of the key either before or after editing it. Then, append it to your
authorized_keys2file. - Next, create a new session in putty. Specify the hostname, the username (under Connection; Data) and the private key to use for authentication (under Connection; SSH; Auth).
- Finally, if you use the example stated above, you'll need to set the "close window on exit" option to "never" (found on the first page with the hostname option). Save the session if you like, it'll be over quick.
- Hit connect, and with any luck, your hostname and uptime (or other job) should appear in putty!
Ideas for sort-of-secure backups
If it were me setting up an off-site backup over SSH, I would have the majority of the backup logic on the host, having it say, making an encrypted backup of all the files and then creating an ISO-9660 image out of the whole mess, and piping that over the SSH.
Since you'd be encrypting the data going over the wire anyway, you might want to select a more light-weight crypto mechanism to save wear-and-tear on the machine (but you could "nice" the backup process to make it run in idle-time). If you keep the keys for whatever encryption mechanism you use elsewhere (not on either the backup machine or the host), then the backup machine if compromised will never see any actual data.
There are probably holes in this theory, I'm sure. I just thought I'd throw it in as food for thought at the tail end of this article.
Update: September 2007
"betabug" writes to bring to our attention that ssh server administrators have even more control over single use access, via the ForceCommand directive. Check out the manual for more information.