3 ms·

> invalidate old ones This one is non-trivial in SSH land (unless you go with a CA approach, of course). Lots of authorized_keys files strewn about everywhere.

• dinosaurdynasty 4y ago
  If you distribute a key revocation list to your servers, it will override anything in anyone's authorized_keys file (on that server of course). Even with a CA approach (unless the expirations are sufficiently short) you will need to do something like this.
  • Quekid5 4y ago
    Yes, but if you're distributing revocation lists you might as well distribute new authorized_keys files? Or wait, maybe I'm misremembering... does sshd support querying remote revocation lists? If so, point conceded. You still have to have to worry about the scenario of DoS or similar preventing it from fetching new lists. (I don't trust revocation beyond as being a QoI thing.) I do favor the CA approach with e.g. 24hr expiry just because it's 'fail safely by default'. Of course one should ideally use much more frequent renewal, but OpenSSH has its limits wrt. that. (Kerberos seems saner in terms of results, just not in practice because it is/was so obnoxious to set up.)
    • dinosaurdynasty 4y ago
      > does sshd support querying remote revocation lists? It doesn't AFAIK but it's not too hard to write a cronjob that `curl`s a secure endpoint occasionally (or `scp` or whatever).
      • Quekid5 4y ago
        That would be a Fail Open type solution which isn't exactly great where security is concerned.