5 ms·

You have to draw a line somewhere, otherwise we might as well say "don't run SSH at all". If worrying about a private key leaking is that much of a threat, ins

You have to draw a line somewhere, otherwise we might as well say "don't run SSH at all". If worrying about a private key leaking is that much of a threat, institute key rotation policies and have people generate a new key pair every month and push the public key where it needs to go and remove the old public key a month after that. Agents allow multiple keys, making this easy to handle on the client side, and if you don't have a way to track and push keys to servers, you should. The one month overlap should be plenty of time for people to get a new key generated even allowing for vacations and most extended absences, and it's not that hard to fix if someone misses the deadline.

foota 7y ago
I'm not really convinced that key rotation is an effective mitigation. Sure, it helps with some classes of threats, but if you're worried about the ones it does protect from you should imo be worried about the others as well. Like, it mostly protects against an attacker trying to get access from an old machine, but doesn't protect from a device with no disk encryption or weak disk encryption (likewise with key passphrase) being stolen outright within the month's window, or an old key being found within a month.
- kbenson 7y ago
  > but doesn't protect from a device with no disk encryption or weak disk encryption (likewise with key passphrase) being stolen outright within the month's window, or an old key being found within a month. Well, it also doesn't protect against the key being exposed within that month and used immediately. That's what makes it a mitigation and not a protection. But against the example class of threats that were presented ("There is a file sitting in a backup or on a former employee’s computer which grants the holder access to your infrastructure.") which seems to indicate leaking of private keys over long periods (and the long period is what makes it non-obvious it's leaking), I think it works quite well. The alternative is to move to a centralized authentication system, but that's got its own set of problems which makes it more of a trade-off than an extra set of practices which mitigates the problems inherent with the current choice. For example, there almost always needs to be a way into the server without network access for network related problems. You're now have the same problems inherent with managing local logins on servers (albeit a much smaller set of logins, maybe one), but maybe it isn't through SSH public keys, and is much harder to change. Will that get rotated? Will that password get changed after someone leaves if it was shared with them?

foota 7y ago

I'm not really convinced that key rotation is an effective mitigation. Sure, it helps with some classes of threats, but if you're worried about the ones it does protect from you should imo be worried about the others as well. Like, it mostly protects against an attacker trying to get access from an old machine, but doesn't protect from a device with no disk encryption or weak disk encryption (likewise with key passphrase) being stolen outright within the month's window, or an old key being found within a month.

kbenson 7y ago
> but doesn't protect from a device with no disk encryption or weak disk encryption (likewise with key passphrase) being stolen outright within the month's window, or an old key being found within a month. Well, it also doesn't protect against the key being exposed within that month and used immediately. That's what makes it a mitigation and not a protection. But against the example class of threats that were presented ("There is a file sitting in a backup or on a former employee’s computer which grants the holder access to your infrastructure.") which seems to indicate leaking of private keys over long periods (and the long period is what makes it non-obvious it's leaking), I think it works quite well. The alternative is to move to a centralized authentication system, but that's got its own set of problems which makes it more of a trade-off than an extra set of practices which mitigates the problems inherent with the current choice. For example, there almost always needs to be a way into the server without network access for network related problems. You're now have the same problems inherent with managing local logins on servers (albeit a much smaller set of logins, maybe one), but maybe it isn't through SSH public keys, and is much harder to change. Will that get rotated? Will that password get changed after someone leaves if it was shared with them?