Two ways I increase the security of SSH personal keys
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.)