Hacker News new | ask | show | jobs
by jas- 1549 days ago
Now you have a centralized single point of failure. While the ease of use is inherently obvious with the implementation, if/when it does fail you will have to fall back to public key/password auth anyways.
3 comments

Centralized single points of control are a basic goal of corpsec. They trade availability for security. The alternative model of individual SSH keys is theoretically more highly available, but has many single points of security failure.
Please enlighten me on the ‘many single points of security failure.’
Which failure mode do you mean? The CA is accessible via offline means. I can walk to it and sign me a new keypair.
What happens when the building the CA is in burns down?
The CA is in a gpg-encryped secrets store (pass) and has a password on itself, so it can be backupped like normal data to an off-site location.
Scan printed QR codes of your private key that you had backed up off-site.
Ideally, k-of-n key shards, stored in safety deposit boxes.
That's actually pretty brilliant.
Provided you keep said papers away from prying cameras in a verifiable way, that is.

For more inspiration, check out the Glacier Protocol.

https://glacierprotocol.org/

Thanks for the heads up!

I wish I'd thought about this when playing with bitcoin a few months after launch and amassing an integer value larger than zero. That wallet died with the hard drive.

The extreme version of this is using an HSM, and putting one in a safe deposit box.
Also, this doesn’t apply to most real scenarios (especially not “how I run my personal stuff” type scenarios), but is a fun one to contemplate: what happens when your customer has requirements that specify all keys (including root signing keys) to be rotated at a certain point in the future? Having a process for this is an interesting challenge.
The CA is a key, not a network service.
Sign with two or three CAs, and have sshd accept any of them.