4 ms·

I like the `StrictHostKeyChecking accept-new` setting. Accept new host key without prompting the usual `Are you sure you want to continue connecting (yes/no/[f

I like the `StrictHostKeyChecking accept-new` setting. Accept new host key without prompting the usual `Are you sure you want to continue connecting (yes/no/[fingerprint])?` (great when scripting on 100+ servers). Still reject known hosts mismatch (so shity Wifi can't inject their ads). Everything can be setting up again by just removing `~/.ssh/known_hosts` (instead of that GitHub messy blog post about curling and seding output to `~/.ssh/known_hosts`).

zamnos 4y ago
Ew, no. The point that mjg59 points out, just not super explicitly and using many more words, is that the confirmation step wouldn't be necessary, if only all of our tooling were just a little bit better. Instead of ssh $ip_address and getting that prompt, instead, you'd do ssh $hostname, where hostname can be generated and contain numbers, and then the same mechanism that checks SSL certificates then also checks if the host's key actually matches what the rest of the system (the configured CAs) is saying it should be. If it does, great! No need to ask the user "Are you sure you want to continue connecting (yes/no/[fingerprint])", with fingerprint being the one thing to check out of band, but few people are really that fastidious. Competent Security/IT departments are able to get this to work going from corp managed endpoints (laptops) going to corp managed servers. It's just that the rest of the world hasn't caught up yet.
- Operyl 4y ago
  SSH certificates (host and client) were the best thing I could have ever implemented at my job, it has significantly improved a _ton_ of internal pain points.
- est31 4y ago
  > and then the same mechanism that checks SSL certificates then also checks if the host's key actually matches what the rest of the system (the configured CAs) is saying it should be. That's not what mjg59 is suggesting, to establish a trust chain to system shipped CAs. In fact that wouldn't be so easy anways because SSH certificates aren't X.509 compatible at all but use their completely homegrown specification. They explicitly say "please do not do this" about this idea. mjg59 suggests to make the TOFU approach on the client trust certificates if a certificate is provided. That's a way narrower suggestion: > OpenSSH has no way to do TOFU for CAs, just the keys themselves. This means there's no way to do a git clone ssh://git@github.com/whatever and get a prompt asking you to trust Github's CA. Instead, you need to add a @cert-authority github.com (key) line to your known_hosts file by hand, and since approximately nobody's going to do that there's only marginal benefit in going to the effort to implement this infrastructure. The most important thing we can do to improve the security of the SSH ecosystem is to make it easier to use certificates, and that means improving the behaviour of the clients.
  - mjg59 4y ago
    To be clear, I'm not suggesting trusting the certificate itself - I'm suggesting trusting the signing CA from the certificate, and so also trusting any future certificates for the same host signed by the same CA
    - est31 4y ago
      I stand corrected. Thanks for pointing out the difference, I was using the terms "CA" and "certificate" interchangeably because in X.509 world CAs also have certificates of their own but it seems that OpenSSH only deals with CA keys, that is, certificates are always leaf certificates, and CAs consist of their keys only. > "Chained" certificates, where the signature key type is a certificate type itself are NOT supported. https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.certkeys?annotate=HEAD https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.certkeys...

zamnos 4y ago

Ew, no. The point that mjg59 points out, just not super explicitly and using many more words, is that the confirmation step wouldn't be necessary, if only all of our tooling were just a little bit better. Instead of ssh $ip_address and getting that prompt, instead, you'd do ssh $hostname, where hostname can be generated and contain numbers, and then the same mechanism that checks SSL certificates then also checks if the host's key actually matches what the rest of the system (the configured CAs) is saying it should be. If it does, great! No need to ask the user "Are you sure you want to continue connecting (yes/no/[fingerprint])", with fingerprint being the one thing to check out of band, but few people are really that fastidious. Competent Security/IT departments are able to get this to work going from corp managed endpoints (laptops) going to corp managed servers. It's just that the rest of the world hasn't caught up yet.

Operyl 4y ago
SSH certificates (host and client) were the best thing I could have ever implemented at my job, it has significantly improved a _ton_ of internal pain points.
est31 4y ago
> and then the same mechanism that checks SSL certificates then also checks if the host's key actually matches what the rest of the system (the configured CAs) is saying it should be. That's not what mjg59 is suggesting, to establish a trust chain to system shipped CAs. In fact that wouldn't be so easy anways because SSH certificates aren't X.509 compatible at all but use their completely homegrown specification. They explicitly say "please do not do this" about this idea. mjg59 suggests to make the TOFU approach on the client trust certificates if a certificate is provided. That's a way narrower suggestion: > OpenSSH has no way to do TOFU for CAs, just the keys themselves. This means there's no way to do a git clone ssh://git@github.com/whatever and get a prompt asking you to trust Github's CA. Instead, you need to add a @cert-authority github.com (key) line to your known_hosts file by hand, and since approximately nobody's going to do that there's only marginal benefit in going to the effort to implement this infrastructure. The most important thing we can do to improve the security of the SSH ecosystem is to make it easier to use certificates, and that means improving the behaviour of the clients.
- mjg59 4y ago
  To be clear, I'm not suggesting trusting the certificate itself - I'm suggesting trusting the signing CA from the certificate, and so also trusting any future certificates for the same host signed by the same CA
  - est31 4y ago
    I stand corrected. Thanks for pointing out the difference, I was using the terms "CA" and "certificate" interchangeably because in X.509 world CAs also have certificates of their own but it seems that OpenSSH only deals with CA keys, that is, certificates are always leaf certificates, and CAs consist of their keys only. > "Chained" certificates, where the signature key type is a certificate type itself are NOT supported. https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.certkeys?annotate=HEAD https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.certkeys...