7 ms·

Every couple of months someone re-discovers SSH certificates, and blogs about them. I'm guilty of it too. My blog post from 15 years ago is nowhere near as goo

Every couple of months someone re-discovers SSH certificates, and blogs about them. I'm guilty of it too. My blog post from 15 years ago is nowhere near as good as OP's post, but if I though me of 15 years ago lived up to my standards of today, I'd be really disappointed: https://blog.habets.se/2011/07/OpenSSH-certificates.html https://blog.habets.se/2011/07/OpenSSH-certificates.html

kaoD 7mo 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 7mo 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 7mo ago
  [deleted]
- thomashabets2 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
      And what about the CA?
      - cyberax 7mo 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.
- anyfoo 7mo 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 7mo 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 7mo ago
      remote unlock is also useful when you're not gaming so that feels like the wrong aspect to focus on
    - anyfoo 7mo 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 7mo 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 7mo ago
    Upgrade to a better one in initramfs?
  - AceJohnny2 7mo ago
- dizhn 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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.
papyDoctor 7mo ago
Another useful feature of SSH certificates is that you can sign a user’s public key to grant them access to a remote machine for a limited time and as a specific remote user.
- TZubiri 7mo ago
  The capacity to grant access as a specific remote user is present without certs as well right? The typical authorized_keys file lives under a user directory and grants access only to that user.
  - blueflow 7mo ago
    The main advantage of certificates is that you are able to do that from the CA without touching the target machine.
    - lokar 7mo ago
      Exactly. This is really useful in larger organizations where you may want more complex rules on access. For example, you can easily build "break glass" or 2nd party approved access on demand. You can put whatever logic you need in a CA front-end. You can also make all the certs short-lived (and only store them in ram).
      - TZubiri 7mo ago
        The way I've been doing that is with Shamir Secret Sharing and encrypting keys until glass-breaking is necessary.
        lokar 7mo ago
        generating tons of keys? or just broad keys? What I've done is generate a cert for the host(s) the user needs, for the time-span they need (subject to authorization logic).
    - pphysch 7mo ago
Stefan-H 7mo ago
I think the scary reality is most people conflate "keys" and "certificates". I have worked with security engineers that I need to remind that we do not use SSH certs, but rather key auth, and they have to think it through to make it click.
- tracker1 7mo ago
  I'm consistently amazed how many developers and security professionals don't have a clear understanding how PPK even works conceptually. Things like deploying dev keys to various production environments, instead of generating/registering them within said environment. One of the worst recent security examples... You can't get this data over HTTPS from $OtherAgency, it's "not secure" ... then their suggestion is a "secure" read-only account to the other agency's SQL server (which uses the same TLS 1.3 as HTTPS). This is from person in charge of digital security for a government org.
  - tolciho 7mo ago
    Or when the security team at some other company emails you their private key.
    - tracker1 6mo ago
      LOL, yeah.. had that happen quite a few times... Also, re-using the ssh server key for the client connecting to the sftp server.
  - laserlight 7mo ago
    > Things like deploying dev keys to various production environments, instead of generating/registering them within said environment. I can see this happening when a developer is authorized to generate, but not to register. So, they just reuse an already-registered one.
    - tracker1 6mo ago
      In the example, it wasn't even that complex... I have used patterns to register allowed signer keys based on environment variables that an application runs under, initializing at startup... so "register" just meant assigning the correct values for 2-4 environment variables per public signer allowed... and removing the dev signer. (JWT based auth)
V-eHGsd_ 7mo ago
oh man, I referred back to your blog post when I wrote the ssh certificate authority for $job ... ~10 years ago. Thank for writing it!
functional_dev 7mo ago
maybe it keeps getting rediscovered, becaues a good tooling around it is still missing?

kaoD 7mo 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 7mo 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 7mo ago
[deleted]
thomashabets2 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
    And what about the CA?
    - cyberax 7mo 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.
anyfoo 7mo 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 7mo 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 7mo ago
    remote unlock is also useful when you're not gaming so that feels like the wrong aspect to focus on
  - anyfoo 7mo 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 7mo 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 7mo ago
  Upgrade to a better one in initramfs?
- AceJohnny2 7mo ago
dizhn 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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.

papyDoctor 7mo ago

Another useful feature of SSH certificates is that you can sign a user’s public key to grant them access to a remote machine for a limited time and as a specific remote user.

TZubiri 7mo ago
The capacity to grant access as a specific remote user is present without certs as well right? The typical authorized_keys file lives under a user directory and grants access only to that user.
- blueflow 7mo ago
  The main advantage of certificates is that you are able to do that from the CA without touching the target machine.
  - lokar 7mo ago
    Exactly. This is really useful in larger organizations where you may want more complex rules on access. For example, you can easily build "break glass" or 2nd party approved access on demand. You can put whatever logic you need in a CA front-end. You can also make all the certs short-lived (and only store them in ram).
    - TZubiri 7mo ago
      The way I've been doing that is with Shamir Secret Sharing and encrypting keys until glass-breaking is necessary.
      - lokar 7mo ago
        generating tons of keys? or just broad keys? What I've done is generate a cert for the host(s) the user needs, for the time-span they need (subject to authorization logic).
  - pphysch 7mo ago

Stefan-H 7mo ago

I think the scary reality is most people conflate "keys" and "certificates". I have worked with security engineers that I need to remind that we do not use SSH certs, but rather key auth, and they have to think it through to make it click.

tracker1 7mo ago
I'm consistently amazed how many developers and security professionals don't have a clear understanding how PPK even works conceptually. Things like deploying dev keys to various production environments, instead of generating/registering them within said environment. One of the worst recent security examples... You can't get this data over HTTPS from $OtherAgency, it's "not secure" ... then their suggestion is a "secure" read-only account to the other agency's SQL server (which uses the same TLS 1.3 as HTTPS). This is from person in charge of digital security for a government org.
- tolciho 7mo ago
  Or when the security team at some other company emails you their private key.
  - tracker1 6mo ago
    LOL, yeah.. had that happen quite a few times... Also, re-using the ssh server key for the client connecting to the sftp server.
- laserlight 7mo ago
  > Things like deploying dev keys to various production environments, instead of generating/registering them within said environment. I can see this happening when a developer is authorized to generate, but not to register. So, they just reuse an already-registered one.
  - tracker1 6mo ago
    In the example, it wasn't even that complex... I have used patterns to register allowed signer keys based on environment variables that an application runs under, initializing at startup... so "register" just meant assigning the correct values for 2-4 environment variables per public signer allowed... and removing the dev signer. (JWT based auth)

V-eHGsd_ 7mo ago

oh man, I referred back to your blog post when I wrote the ssh certificate authority for $job ... ~10 years ago. Thank for writing it!

functional_dev 7mo ago

maybe it keeps getting rediscovered, becaues a good tooling around it is still missing?