5 ms·

I've known SSH certs for a while but never went through the effort of migrating away from keys. I'm very frustrated about manually managing my SSH keys across m

by kaoD 6mo ago

I've known SSH certs for a while but never went through the effort of migrating away from keys. I'm very frustrated about manually managing my SSH keys across my different servers and devices though. I assume you gathered a lot of thoughts over these 15 years. Should I invest in making the switch?

ibotty 6mo ago
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.
deleted 6mo ago
[deleted]
thomashabets2 6mo ago
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.
otabdeveloper4 6mo ago
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]
anyfoo 6mo ago
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.
- TZubiri 6mo ago
  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.
  - nagaiaida 6mo ago
    remote unlock is also useful when you're not gaming so that feels like the wrong aspect to focus on
  - anyfoo 6mo ago
    Hah? It being my gaming machine has nothing to do with the problem. It’s also my FPGA development machine, though it gets used less for that. It only happens to be the only Linux workstation in my home (the others are Macs or OpenBSD).
    - TZubiri 6mo ago
      If you care about security, I recommend investing into a separate computer for developing hardware and software and another for downloading games on. You can setup your security any way you like, but nothing beats an air gap in terms of security and simplicity.
- namibj 6mo ago
  Upgrade to a better one in initramfs?
- AceJohnny2 6mo ago
dizhn 6mo ago
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.
- gnufx 6mo ago
  If you mean using OIDC, in that space there's at least https://github.com/EOSC-synergy/ssh-oidc https://github.com/EOSC-synergy/ssh-oidc, https://dianagudu.github.io/mccli/ https://dianagudu.github.io/mccli/ and OpenPubkey-ssh discussed in https://news.ycombinator.com/item?id=43470906 https://news.ycombinator.com/item?id=43470906 (which might mention more). How does SSSD support help with SSH authN? I know you can now get Kerberos tickets from FreeIPA using OIDC(?), but I forget if SSSD is involved.
  - floating-io 6mo ago
    Can't really speak to the point of the guy you're replying to, but the FreeIPA implementation via SSSD does more than just Kerberos tickets. Actually, I think the Kerberos based stuff as it relates to SSH is GSSAPI as part of sshd itself and has little to do with sssd, though I could be wrong. That said... If I'm remembering things correctly (and it's been a looong while since I've played with this), FreeIPA's client configures sshd with an AuthorizedKeysCommand that executes a program that queries sssd for the list of authorized keys for a given user. Sssd then uses a plugin to query the LDAP server @ FreeIPA to get the list of keys. There's also SSHFP (I think) records in DNS if you're using FreeIPA's DNS servers. These provide the host keys for servers for your ssh client to check against. Not sure if that's integrated into ssh itself or something else -- I can't remember how it's implemented offhand -- but it's fairly nifty since you never see the TOFU prompt (or it would be if DNS was actually secure, anyway).
    - gnufx 6mo ago
      Yes, FreeIPA is Kerberos+LDAP+X.509 CA, and GSSAPI is in OpenSSH (normally with the key exchange patch). SSSD is a local mechanism, not network authentication. I mentioned authorized keys distribution mechanisms elsewhere, but I was thinking authentication (c.f. OIDC), not authorization.
cyberax 6mo ago
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.

by kaoD 6mo ago

ibotty 6mo ago

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.

deleted 6mo ago

[deleted]

thomashabets2 6mo ago

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.

otabdeveloper4 6mo ago

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]

anyfoo 6mo ago

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.

TZubiri 6mo ago
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.
- nagaiaida 6mo ago
  remote unlock is also useful when you're not gaming so that feels like the wrong aspect to focus on
- anyfoo 6mo ago
  Hah? It being my gaming machine has nothing to do with the problem. It’s also my FPGA development machine, though it gets used less for that. It only happens to be the only Linux workstation in my home (the others are Macs or OpenBSD).
  - TZubiri 6mo ago
    If you care about security, I recommend investing into a separate computer for developing hardware and software and another for downloading games on. You can setup your security any way you like, but nothing beats an air gap in terms of security and simplicity.
namibj 6mo ago
Upgrade to a better one in initramfs?
AceJohnny2 6mo ago

dizhn 6mo ago

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.

gnufx 6mo ago
If you mean using OIDC, in that space there's at least https://github.com/EOSC-synergy/ssh-oidc https://github.com/EOSC-synergy/ssh-oidc, https://dianagudu.github.io/mccli/ https://dianagudu.github.io/mccli/ and OpenPubkey-ssh discussed in https://news.ycombinator.com/item?id=43470906 https://news.ycombinator.com/item?id=43470906 (which might mention more). How does SSSD support help with SSH authN? I know you can now get Kerberos tickets from FreeIPA using OIDC(?), but I forget if SSSD is involved.
- floating-io 6mo ago
  Can't really speak to the point of the guy you're replying to, but the FreeIPA implementation via SSSD does more than just Kerberos tickets. Actually, I think the Kerberos based stuff as it relates to SSH is GSSAPI as part of sshd itself and has little to do with sssd, though I could be wrong. That said... If I'm remembering things correctly (and it's been a looong while since I've played with this), FreeIPA's client configures sshd with an AuthorizedKeysCommand that executes a program that queries sssd for the list of authorized keys for a given user. Sssd then uses a plugin to query the LDAP server @ FreeIPA to get the list of keys. There's also SSHFP (I think) records in DNS if you're using FreeIPA's DNS servers. These provide the host keys for servers for your ssh client to check against. Not sure if that's integrated into ssh itself or something else -- I can't remember how it's implemented offhand -- but it's fairly nifty since you never see the TOFU prompt (or it would be if DNS was actually secure, anyway).
  - gnufx 6mo ago
    Yes, FreeIPA is Kerberos+LDAP+X.509 CA, and GSSAPI is in OpenSSH (normally with the key exchange patch). SSSD is a local mechanism, not network authentication. I mentioned authorized keys distribution mechanisms elsewhere, but I was thinking authentication (c.f. OIDC), not authorization.

cyberax 6mo ago

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.