Hacker News Reader

Comment by daneel_w | Hacker News Reader

So the solution to the problem brought up by the author - having to regularly deploy a new authorized_keys file to servers - is to instead regularly deploy a new revocation document to servers. I don't see how this is any different or a solution to the primary problem discussed. It just adds the additional effort of having to sign and revoke certificates.

We use a cronjob to regularly fetch, verify and deploy updated authorized_keys on servers.

View on HN

The primary difference is that you can have short-lived certificates, but ssh-keys are eternal. If you fail to remove one, it sticks around and may come back to bite you if compromised at a later point. Certificates expire, after which they’re useless to an attacker.

One of nice options in recent versions of OpenSSH is the "expiry-time" key option you can put in authorized_keys. There are also other options handy to restrict the usage of the key, for example you can limit the key to be used only as a jump host. One can combine them so the users on the jump host will not be able to execute any command and even not able to edit authorizd_keys file and remove the "expiry-time" option.

I think that you’re overreacting a tiny bit. One area that the OPs solution allows is rapid onboarding, quick/automatable generation for machine to machine roles and the ability to actually do some RBAC(if that matters to you). To make their system fail safe, they do the exact same thing you are except only making sure to synchronize the block-list.

I don’t know about you, but at least at my org, waiting for tens of thousands of machines to sync an authorized keys file when doing a ton of onboarding or a very very selective off-boarding... I’d rather minimize the amount of machines I touch and doing that via an authorized_keys push via ansible is untenable at scale or volume.

I'm just taking the article's main point at face value. Certificates help with enabling access quickly (fast onboarding) but revocation needs every server to be informed about the change, since OpenSSH doesn't do OCSP.

If a single file change is untenable at scale or volume, how does your organization manage version deployments, or even something small like an emergency reconfiguration, without collapsing or having to cope until "patch tuesday"? What you describe sounds untenable to me.

I came to the exact same conclusion as you.

I can see this working nicely in relaxed companies that are comfortable waiting for the signed keys to expire (but those companies probably also won't like the inconvenience of expiring keys).

With that said, there is an advantage, in that a revoked key will eventually expire even if the cronjob breaks.

Reply on news.ycombinator.com