Garrett: We need better support for SSH host certificates

Posted Mar 24, 2023 20:44 UTC (Fri) by kokkoro (guest, #139153)
Parent article: Garrett: We need better support for SSH host certificates

Most SSH hosts don't use CAs, so the demand for better CA support is low.

If you're using CAs you're probably a large organization and you would want to manage the CA trust explicitly rather than have every employee TOFU the CA.

For example, it would be pretty easy for GitHub to add a one-liner for users to add their CA to known_hosts, and that would be safer than TOFU anyway. Compared to TOFUing individual self-generated host keys, TOFUing a CA is much riskier.

Garrett: We need better support for SSH host certificates

Posted Mar 24, 2023 23:52 UTC (Fri) by anselm (subscriber, #2796) [Link]

Where I work we use step-ca, which helps automate dealing with SSH certificates (among other things). When I want to connect to a remote host using SSH for the first time in the morning, I authenticate myself with an OpenID Connect identity provider (could be Google, but in our case it's a simple Django application that talks to our LDAP directory), and, on the strength of that, step-ca issues me with an SSH client certificate that is good for 24 hours. I can use this certificate to SSH into our servers until it expires, at which point I need to re-authenticate using the OIDC IdP. Similarly, the remote servers get their host certificates from step-ca, and these are also updated quite frequently.

To bootstrap this, I need to point the system to the step-ca instance and provide that instance's “fingerprint” for authentication; my SSH client is then set up automatically. It is a convenient system that makes it unnecessary to copy public keys around and also deals with the problem that SSH public keys basically live forever.

Garrett: We need better support for SSH host certificates

Posted Mar 27, 2023 16:35 UTC (Mon) by floppus (guest, #137245) [Link]

> For example, it would be pretty easy for GitHub to add a one-liner for users to add their CA to known_hosts, and that would be safer than TOFU anyway. Compared to TOFUing individual self-generated host keys, TOFUing a CA is much riskier.

That depends what you mean by "TOFUing a CA". If that means "trusting this CA to issue certificates for any hostname", the way web browsers do, then yes, that's horribly dangerous.

If it means "trusting this CA to issue certificates for the hostname I'm currently connecting to", that doesn't seem any different from "a one-liner for users to add their CA to known_hosts". And for ssh to do that itself, on first use, would be decidedly safer than requiring users to copy and paste a command they don't understand.