3 ms·

You will have to manage your SSH CA certificates instead of your keys. The workflows SSH CA's are extremely janky and insecure. With some creative use of `Aut

You will have to manage your SSH CA certificates instead of your keys. The workflows SSH CA's are extremely janky and insecure. With some creative use of `AuthorizedKeysCommand` you can make SSH key rotation painless and secure. With SSH certificates you have to go back to the "keys to the kingdom" antipattern and just hope for the best.

jamiesonbecker 6mo ago
Exactly. We'd had discussions about building https://Userify.com https://Userify.com (plug!) around SSH certificates, but elected to go with keys instead, because Userify delivers most of the good things around certificates without the jank and insecurity. It's not that certificates themselves are insecure themselves, it's that the workflows (as the parent points out) are awful. We might still add some automation around that (and I think I saw some competitor tooling out there if you're committed to that path) but I personally feel like it's an answer to the wrong question.
cyberax 6mo ago
> With SSH certificates you have to go back to the "keys to the kingdom" antipattern and just hope for the best. Whut? This is literally the opposite. With CA certs you can create short-lived certificates, so you can easily grant access to a system for a short time.
- namibj 6mo ago
  And what about the CA?
  - cyberax 6mo ago
    It's no different compared to regular SSH private keys. You need to protect it from compromise. However, it provides you an additional layer of protection, because it does not need to be on the critical path for every SSH connection. My CA is a Nitrokey HSM, for example. I issue myself temporary certs that are valid only for 6 hours for ephemeral private keys.
    - otabdeveloper4 6mo ago
      Yes it is different. SSH CA keys are harder to secure and attackers have a much bigger incentive to steal them.
  - _bernd 6mo ago
    You can also configure multiple CA for client auth, and on the client side multiple ca to verify host keys.
GandalfHN 6mo ago
[flagged]

jamiesonbecker 6mo ago

Exactly. We'd had discussions about building https://Userify.com https://Userify.com (plug!) around SSH certificates, but elected to go with keys instead, because Userify delivers most of the good things around certificates without the jank and insecurity. It's not that certificates themselves are insecure themselves, it's that the workflows (as the parent points out) are awful. We might still add some automation around that (and I think I saw some competitor tooling out there if you're committed to that path) but I personally feel like it's an answer to the wrong question.

cyberax 6mo ago

> With SSH certificates you have to go back to the "keys to the kingdom" antipattern and just hope for the best. Whut? This is literally the opposite. With CA certs you can create short-lived certificates, so you can easily grant access to a system for a short time.

namibj 6mo ago
And what about the CA?
- cyberax 6mo ago
  It's no different compared to regular SSH private keys. You need to protect it from compromise. However, it provides you an additional layer of protection, because it does not need to be on the critical path for every SSH connection. My CA is a Nitrokey HSM, for example. I issue myself temporary certs that are valid only for 6 hours for ephemeral private keys.
  - otabdeveloper4 6mo ago
    Yes it is different. SSH CA keys are harder to secure and attackers have a much bigger incentive to steal them.
- _bernd 6mo ago
  You can also configure multiple CA for client auth, and on the client side multiple ca to verify host keys.

GandalfHN 6mo ago

[flagged]