21–30 of 137 posts
In our dev/stg environment we reinstall half our machines every morning (largely to test our machine setup automation), and SSH host certificates make that so much nicer than having to persist host keys or remove/replace them in known_hosts. Highly recommended.
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
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?
Is that yet another problem that I need to solve with syncthing?
All those articles about SSH certificates fall short of explaining how the revocation list can/should be published. Is that yet another problem that I need to solve with syncthing? https://man.openbsd.org/ssh-keygen.1#KEY_REVOCATION_LISTS
Earlier quoted context omitted.
TOFU is convenient, but not necessary. Choosing to use TOFU is a distinct choice from the choice of using the keys generated by SSH, instead of using certificates. If you do not want to use TOFU, for extra security, you just have to pair the computers by copying between them the corresponding public keys through a secure channel, e.g. by using a USB memory. Using certificates does not add any simplification or any ex…
Are you pairing computers by copying certificates to visit this site?
You can also address TOFU to some extent using SSHFP DNS records. Openssh supports checking the DNSSEC signature in the client, in theory, but it's a configure option and I'm not sure if distros build with it.
On top of that you would need something to secure DNS. Like DNSSEC or at the very least use DNS with TLS or DNS over HTTP. None of these are typically enabled by default.
Additionally, as I mentioned, openssh itself has support for validating the DNSSEC signature even if your local resolver doesn't. I actually don't think it can use the standard resolver for SSHFP records at all, but I'm not sure.
Earlier quoted context omitted.
TOFU is convenient, but not necessary. Choosing to use TOFU is a distinct choice from the choice of using the keys generated by SSH, instead of using certificates. If you do not want to use TOFU, for extra security, you just have to pair the computers by copying between them the corresponding public keys through a secure channel, e.g. by using a USB memory. Using certificates does not add any simplification or any ex…
Are you pairing computers by copying certificates to visit this site?
With the other, I'm logging into a server for the first time (and I could simply deploy the same trusted host key to all my ssh servers via an autoscaling configuration or whatever). I think it's debatable if TOFU is worse or better than your (granted clever) metaphor.
(to those who'd recommend userify, yes - great for the client login issue and definitely increases security, but to parent's point, TOFU is still needed unless you want to distribute host pubkeys)
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
Earlier quoted context omitted.
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?
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.
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.