6 ms·
I wish revocation was covered as well. The article mentions this issue in SSH: > Keys are trusted permanently, so mistakes are fail-open. But you can make the
by Cpoll 5y ago
I wish revocation was covered as well. The article mentions this issue in SSH:
> Keys are trusted permanently, so mistakes are fail-open.
But you can make the same mistake using certificates, by issuing a certificate with a large expiration date. AFAIR you _can_ revoke valid certs, but that involves making changes to every box running ssh, much like when revoking a public key.
- blueflow 5y agoYou can distribute a key revocation list along with your regular configuration management. The key revocation list can be generated and maintained via ssh-keygen. I used to have a central location with an revocation list. All servers had a cronjob fetching it.
- camtarn 5y agoAnd that's pretty much the exact same infrastructure you'd need for distributing authorized_keys. Instant revocation seems to be a giant hole in this article's argument which isn't addressed at all. If you fire somebody partway through the work day, end-of-day cert expiry is not good enough to prevent compromises.