Reading the first paragraph it's not entirely clear to me if the authors actually understand public key cryptography or SSH public key auth. (I suspect they do, but they certainly don't make that clear, maybe because FUD is how you push a product.)
> If your organization uses SSH public keys, it’s entirely possible you have already mislaid one. There is a file sitting in a backup or on a former employee’s computer which grants the holder access to your infrastructure.
Public keys are public... You mean mislaid a secret key right? And even if an attacker gets ahold of a secret key file, it's still protected by a passphrase (unless of course you use an empty passphrase)...
> Should that happen, how would you respond and revoke the lost SSH key?
By removing that public key from authorized_keys.
Edit: To be fair, I missed this qualifier:
> If someone is able to compromise a team member’s laptop, they could use keys on the device that lack password protection to reach sensitive destinations.
Okay, not using a passphrase is a bad idea, but that doesn't mean "public keys are not enough for SSH security", right?
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.
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.
> 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?
You're right, the wording is poor, but the general premise that SSH public/private key auth is a security weakness is valid.
Administrators cannot validate that SSH private certs are properly protected with a strong passphrase. Also 2-factor for SSH is rare. With enough employees, chances are high that someone gets lazy and generates a cert without a passphrase.
I suppose a company/organization-mandated ssh-keygen wrapper would solve that problem. But hard to validate unless you demand access to secret keys, yeah.
> Should that happen, how would you respond and revoke the lost SSH key? Do you have an accounting of the keys which have been generated? Do you rotate SSH keys? How do you manage that across an entire organization so consumed with serving customers that security has to be effortless to be adopted?
The problem presented above and the solution they offer seem like miles apart.
The number of ssh keys is likely finite in an organization. It shouldn't be hard to keep track on those.
Instead, you're supposed to integrate a complex process?
Encrypt your data, add a passphrase to the key, have admins keep record.
Diaclosure: I work at Cloydflare. Administering 1 machine easy. 10 machines with 100 users a bit more effort. 1000 machines and 10,000 users. Hard. That's on top of integrating with your LDAP source of truth.
No, it's not. I've written multiple key management and push systems over the last 15 years. It's a 50 line Perl script, if that, and that's with groups and server roles.
Scales perfectly fine with hundreds of servers and tens of users, but that's just with a flat text config file, keys separated in their own dir, and no parallelization.
I've done LDAP auth and querying before, I don't see this being all that hard.
No real mention of key passphrases, except that a team member might forget to use one.
It seems to me that the title is not really true for individual users or small teams - modern OpenSSH passphrases are good enough to protect against theft.
As an alternative solution to the SSH key security concerns raised here, I use a Yubikey as a smart card for my SSH access. This way, even if my laptop is compromised, an attacker has to physically steal my Yubikey (and know the PIN on it).
Exposed private keys are are problem. But there are several open source solutions for this. I recommend keymaster (https://github.com/Symantec/keymaster) as it is designed with madatory 2FA and a user flow that does not require you to leave the CLI. (I am one of the contributors)
20 comments
[ 0.18 ms ] story [ 73.3 ms ] threadYou might be able to save money on Cloudflare by literally just mailing all your keys to the NSA every week.
- When provisioning keys, ensure that team members put a unique, strong pass phrase on the file
- Set up two-factor verification via the google Authenticator PAM module
> If your organization uses SSH public keys, it’s entirely possible you have already mislaid one. There is a file sitting in a backup or on a former employee’s computer which grants the holder access to your infrastructure.
Public keys are public... You mean mislaid a secret key right? And even if an attacker gets ahold of a secret key file, it's still protected by a passphrase (unless of course you use an empty passphrase)...
> Should that happen, how would you respond and revoke the lost SSH key?
By removing that public key from authorized_keys.
Edit: To be fair, I missed this qualifier:
> If someone is able to compromise a team member’s laptop, they could use keys on the device that lack password protection to reach sensitive destinations.
Okay, not using a passphrase is a bad idea, but that doesn't mean "public keys are not enough for SSH security", right?
With direct key-file access, bruce-force is very fast so it will depend on the passkey length.
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.
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.
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?
Administrators cannot validate that SSH private certs are properly protected with a strong passphrase. Also 2-factor for SSH is rare. With enough employees, chances are high that someone gets lazy and generates a cert without a passphrase.
The problem presented above and the solution they offer seem like miles apart.
The number of ssh keys is likely finite in an organization. It shouldn't be hard to keep track on those.
Instead, you're supposed to integrate a complex process?
Encrypt your data, add a passphrase to the key, have admins keep record.
Does CF have little faith in admins?
Scales perfectly fine with hundreds of servers and tens of users, but that's just with a flat text config file, keys separated in their own dir, and no parallelization.
I've done LDAP auth and querying before, I don't see this being all that hard.
It seems to me that the title is not really true for individual users or small teams - modern OpenSSH passphrases are good enough to protect against theft.
If interested, I followed this guide to set it up: https://github.com/drduh/YubiKey-Guide/blob/master/README.md