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.
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.
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).
> 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.
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)
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.
[+] [-] oefrha|6 years ago|reply
> 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?
[+] [-] kbenson|6 years ago|reply
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.
[+] [-] aeternum|6 years ago|reply
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.
[+] [-] tmikaeld|6 years ago|reply
With direct key-file access, bruce-force is very fast so it will depend on the passkey length.
[+] [-] stock_toaster|6 years ago|reply
[+] [-] PureParadigm|6 years ago|reply
If interested, I followed this guide to set it up: https://github.com/drduh/YubiKey-Guide/blob/master/README.md
[+] [-] gfodor|6 years ago|reply
- 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
[+] [-] manbash|6 years ago|reply
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?
[+] [-] wbl|6 years ago|reply
[+] [-] pnako|6 years ago|reply
You might be able to save money on Cloudflare by literally just mailing all your keys to the NSA every week.
[+] [-] cviecco44|6 years ago|reply
[+] [-] regecks|6 years ago|reply
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.
[+] [-] JoeCamel|6 years ago|reply
[+] [-] 29athrowaway|6 years ago|reply