Comment by oefrha | Hacker News Reader

Comment by oefrha | Hacker News Reader

Parent Full thread

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.

> 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.

As always, weakass passwords are not much better than no passwords. Should be common sense by now. Enforce a policy against that.

How do you enforce it?

Reply on news.ycombinator.com