|
| ▲ | anyfoo 4 hours ago | parent | next [-] |
| A big problem I have with ssh carts is that they are not universally supported. For me, there is always some device or daemon (for example tinyssh in the initramfs of my gaming pc so that I can unlock it remotely) that only works with “plain old ssh keys”. And if I have to distribute and sync my keys onto a few hosts anyway, it takes away the benefits. |
| |
| ▲ | namibj a minute ago | parent | next [-] | | Upgrade to a better one in initramfs? | |
| ▲ | TZubiri 2 hours ago | parent | prev [-] | | Might actually be a positive instead of a negative. Gaming use-cases should have not any effect on security policies, these should be as separate as possible, different auth mechanisms for your gaming stuff and your professional stuff ensures nothing gets mixed. |
|
|
| ▲ | thomashabets2 5 hours ago | parent | prev | next [-] |
| If your use case is such that you are frustrated about managing keys, host or user keys, then yes it does sound like SSH certs would help you. E.g. when you have many users, servers, or high enough cartesian product of the two. In environment where they don't cause frustration they're not worth it. Not really more to it than that, from my point of view. |
|
| ▲ | dizhn 3 hours ago | parent | prev | next [-] |
| I am keeping an eye on the new (and alpha) Authentik agent which will allow idp based ssh logins. There's also SSSD already supported but it requires glibc (due to needing NSS) meaning it's not available on Alpine. |
| |
|
| ▲ | ibotty 5 hours ago | parent | prev | next [-] |
| Yes. Caveat: It might not really be worth it if all your infrastructure is managed by these newfangled infrastructure-as-code-things that are quick to roll out (OpenShift/OKD, Talos, etc.) and you have only one repo to change SSH keys (single cluster or single repo for all clusters). There are some serious security benefits for larger organizations but it does not sound as if you are part of one. |
|
| ▲ | 5 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | cyberax an hour ago | parent | prev | next [-] |
| It depends on what you want to do. CA certs are easy to manage, you just put the CA key instead of the SSH public key in authorized_keys. They also provide a way to get hardware-backed security without messing with SSH agent forwarding and crappy USB security devices. You can use an HSM to issue a temporary certificate for your (possibly temporary) public key and use it as normal. The certificate can be valid for just 1 hour, enough to not worry about it leaking. |
|
| ▲ | otabdeveloper4 4 hours ago | parent | prev [-] |
| 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 3 hours ago | parent | next [-] | | Exactly. We'd had discussions about building 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 an hour ago | parent | prev [-] | | > 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. |
|
