3 ms·

Just so you know, in case you don't, you can use certificates for SSH these days. Not X.509, but certificates nonetheless in that they bind a set of names or IP

Just so you know, in case you don't, you can use certificates for SSH these days. Not X.509, but certificates nonetheless in that they bind a set of names or IP addresses to a public key and signed by a CA you trust, which, for your machines, will be a CA you control. Now I can deploy as many new machines as I like and I only have to sign their host keys for all of my SSH clients across my machines to trust that new machine before I first use it. If this is new information; I have left example instructions at https://paste.debian.net/plainh/6b332023 https://paste.debian.net/plainh/6b332023

dspillett 10y ago
I'm aware of certificate support for SSH, though getting out clients to use something other than what they "have always done" is somewhat painful. It isn't just browser choices and desktop OSs in which they are firmly stuck a decade and a half behind... Certificate for SSH isn't something that the OP is going to like though, as he is trying to use SSH as part of a rational for doing away with certificates for HTTPS...
- aaronmdjones 10y ago
  Right, but the old clients that don't support Host Certificates will just keep using the Host Keys that they always have, and prior confirmation or TOFU or whatnot. It can be of great benefit to the new clients at the same time, though -- because you need to put the hostkey and the certificate side-by-side on the sshd. Clients that have a CA known_hosts(5) entry for a given name (or a mask that matches the name they're connecting to) will prefer host certificates over host keys and attempt to verify them that way if the server presents one, but if that fails they'll still fall back to regular host key validation (unless you explicitly set the HostKeyAlgorithms directive to eliminate non-certificate-based ones). It's the best of all worlds, in my opinion.

dspillett 10y ago

I'm aware of certificate support for SSH, though getting out clients to use something other than what they "have always done" is somewhat painful. It isn't just browser choices and desktop OSs in which they are firmly stuck a decade and a half behind... Certificate for SSH isn't something that the OP is going to like though, as he is trying to use SSH as part of a rational for doing away with certificates for HTTPS...

aaronmdjones 10y ago
Right, but the old clients that don't support Host Certificates will just keep using the Host Keys that they always have, and prior confirmation or TOFU or whatnot. It can be of great benefit to the new clients at the same time, though -- because you need to put the hostkey and the certificate side-by-side on the sshd. Clients that have a CA known_hosts(5) entry for a given name (or a mask that matches the name they're connecting to) will prefer host certificates over host keys and attempt to verify them that way if the server presents one, but if that fails they'll still fall back to regular host key validation (unless you explicitly set the HostKeyAlgorithms directive to eliminate non-certificate-based ones). It's the best of all worlds, in my opinion.