Two ways I increase the security of SSH personal keys

March 3, 2012

It's time for me to toss some pennies into the pond of advice about good ways to use SSH securely and conveniently. However, I first need to point to my general remarks about SSH personal keys; the following things I do are a tradeoff. They work for me but they may not be right for you.

Here are two things that I do with SSH personal keys (aka SSH identities) that I don't think are always done. Both of them are useful for increasing security.

First, I have a different SSH identity for each machine that I run SSH from. This means one key for my home machine, another key for my office workstation, a third key on my office laptop, and so on. I never reuse the same identity on different machines, even if it would be convenient and I consider the machines equivalently secure (and give the machines the same access permissions for my other accounts).

(The semi-exception to this is that my account on our login and compute servers has a SSH identity for itself. Because my home directory is NFS mounted on all of them, the identity is shared across all of them.)

Second and importantly I use the from="..." feature in .ssh/authorized_key to restrict what sources a particular identity will be accepted from. Each identity is restricted to the known, likely, or plausible origin IP(s) for the machine that it's associated with. For my main keys (on my home and office machines), this is a very small list (both machines have static IPs). The laptop key is restricted to the plausible wired and wireless connections that I use it with. Doing this drastically limits the damage of key disclosure, to the point where I could practically publish the secret key for one of my core identities here on the blog without it doing you any good (and not because the machines it works on are firewalled from the Internet, either).

(Since our systems accept password authentication over ssh, I have a fallback if I really need it.)

There are many keys that can have their sources limited this way, even if the limits are relatively broad. In many cases there's simply no need to accept a key from everywhere, and not infrequently you can be very restrictive. Excellent candidates for this are all of the keys that you use to allow automated access for scripts, backups, and similar things.

(We have a number of identities that we use to allow access this way, some of them to fairly dangerous accounts and systems. All of them have strong origin restrictions. Occasionally this is inconvenient, such as when we have to remember to add a new system to the origin restriction, but in general it makes us happier.)

Written on 03 March 2012.
« A trick for dealing with irregular multi-word lines in shell scripts
Some stuff on Python 2.7.x support periods »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Mar 3 00:10:15 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.