4 ms·

> you do not need to pass around authorized_keys to all hosts. But now I need to trust these random host keys, instead of a key signed by my SSH CA...

• zaphar 2y ago
  How do you "untrust" a single person's key under this scheme? You would have to visit all of the machines and remove them from the authorized keys file.
  • nixgeek 2y ago
    Not really, with an SSH CA you’re trusting the CA and not installing individual keys into authorized_keys files. Anything signed by the SSH CA will work for logins. To deal with the “untrust” issue it’s normal for operations with an SSH CA to rely on (very) short-lived certificates, meaning often issued and valid for < 24 hours (it’s configurable, I’ve seen this be as short as 30 minutes). Smallstep wrote a summary here which is pretty good — https://smallstep.com/blog/use-ssh-certificates/ https://smallstep.com/blog/use-ssh-certificates/
    • michaelt 2y ago
      > To deal with the “untrust” issue it’s normal for operations with an SSH CA to rely on (very) short-lived certificates, meaning often issued and valid for < 24 hours (it’s configurable, I’ve seen this be as short as 30 minutes). So you want a way to get rid of long-lived SSH certificates, instead authenticating users with your corporate single-sign-on system then issuing them a temporary credential? And presumably you've got some audit logs, so you know who connected to what, when and why. Perhaps a familiar command line tool, that makes temporary credential rotation easy for users? Perhaps some paperwork to hand to your SOC2 compliance auditors? I mean, this is sounding a lot like tailscale ssh, teleport, and suchlike...
    • didip 2y ago
      But even this still requires automation, something that 97% of population don't want to do.