2 ms·

This stuff is a bit over my head. Under this scenario, if the site rotates their key, will I need to decide on my system to trust it or not ? Maybe change som

by jmclnx 4y ago

This stuff is a bit over my head. Under this scenario, if the site rotates their key, will I need to decide on my system to trust it or not ? Maybe change something on my system ? Or does the remote site use my ssh public key transparently to know it is me, and allow me in ? So I do nothing at my end ? I guess that would be OK by me. But as I noted above, I am guessing.

_cenw 4y ago
Your key is not involved here at all. You can also sign host keys and then trust the CA instead of the host key with TOFU, but as mentioned in the article, there's no way to do this without having the user fiddle with their SSH config and I'm unsure how good the tooling for distributing revocations is. Vault has a setup guide, along with the little dance a user would have to do: https://developer.hashicorp.com/vault/docs/secrets/ssh/signed-ssh-certificates#host-key-signing https://developer.hashicorp.com/vault/docs/secrets/ssh/signe...
mjg59 4y ago
Under this scenario you wouldn't need to do anything if the site rotates their key - the new key would be presented with a certificate signed with the same CA key. But no clients support doing this kind of semi-automated enrollment at the moment. You can manually add the trusted certificate to known_hosts, though.
- jmclnx 4y ago
  Great, thanks
unethical_ban 4y ago
The way I understand SSH interaction, is that every single time I login to a site or server for the first time, it is like interacting with self-signed HTTPS cert. There is no PKI, no central trust that did any kind of validation that the site is who they say they are. Considering that SSH is generally used by a small number of people per server vs. a general access mechanism (for the general internet), the need for PKI hasn't seemed as pressing. But why it isn't more prominent, I don't know.
crote 4y ago
If I understand it correctly, there would be zero change for the user. Right now, a server has a single host key. This is generated once and will remain static for the server's entire lifetime. The client has the public part of that in their authorized_keys. When a session is created, the server uses the private part to sign some stuff, and the client validates it using the already-known public key. In other words, we have the host key K, client stores K_public in known_hosts. On session creation, server does `session_signature = K_private.sign(data)` and sends (data, session_signature) to client. Client does `K_public.validate(session_signature, data)` and continues if it all matches. This usually works just fine, but you can only have a single key for a server - which is a bit of an issue if that "server" is actually an entire cluster consisting of thousands of machines. Every singly machine needs to have a copy of the single private key. as delegating this to a secure enclave is unfeasible if you get hundreds of thousands of connections per second. Not to mention that key rotation is a bit of a nightmare. With this proposal, we add a parent key, let's call it L. L_private is stored in some kind of very secure hardware enclave. Every hour/day/whatever, the server generates a new host key K, and asks the enclave to sign the new public key. The server now has K_private, and `host_signature = L_private.sign(K_public)` as generated by the enclave. The client stores L_public in their known_hosts. On session creation, server does `session_signature = K_private.sign(data)` and sends (data, session_signature, K_public, host_signature) to the client. The client finally does `L_public.validate(host_signature, K_public) && K_public.validate(session_signature, data)`. All of this happens on the server side, and the only thing needed is a relatively minor protocol upgrade. The interesting part is that a very similar mechanism already exists for the client's key, making it way easier to manage hundreds of keys across thousands of servers without going crazy by having to update authorized_keys among the entire server fleet multiple times per week.

by jmclnx 4y ago

_cenw 4y ago

Your key is not involved here at all. You can also sign host keys and then trust the CA instead of the host key with TOFU, but as mentioned in the article, there's no way to do this without having the user fiddle with their SSH config and I'm unsure how good the tooling for distributing revocations is. Vault has a setup guide, along with the little dance a user would have to do: https://developer.hashicorp.com/vault/docs/secrets/ssh/signed-ssh-certificates#host-key-signing https://developer.hashicorp.com/vault/docs/secrets/ssh/signe...

mjg59 4y ago

Under this scenario you wouldn't need to do anything if the site rotates their key - the new key would be presented with a certificate signed with the same CA key. But no clients support doing this kind of semi-automated enrollment at the moment. You can manually add the trusted certificate to known_hosts, though.

jmclnx 4y ago
Great, thanks

unethical_ban 4y ago

The way I understand SSH interaction, is that every single time I login to a site or server for the first time, it is like interacting with self-signed HTTPS cert. There is no PKI, no central trust that did any kind of validation that the site is who they say they are. Considering that SSH is generally used by a small number of people per server vs. a general access mechanism (for the general internet), the need for PKI hasn't seemed as pressing. But why it isn't more prominent, I don't know.

crote 4y ago

If I understand it correctly, there would be zero change for the user. Right now, a server has a single host key. This is generated once and will remain static for the server's entire lifetime. The client has the public part of that in their authorized_keys. When a session is created, the server uses the private part to sign some stuff, and the client validates it using the already-known public key. In other words, we have the host key K, client stores K_public in known_hosts. On session creation, server does `session_signature = K_private.sign(data)` and sends (data, session_signature) to client. Client does `K_public.validate(session_signature, data)` and continues if it all matches. This usually works just fine, but you can only have a single key for a server - which is a bit of an issue if that "server" is actually an entire cluster consisting of thousands of machines. Every singly machine needs to have a copy of the single private key. as delegating this to a secure enclave is unfeasible if you get hundreds of thousands of connections per second. Not to mention that key rotation is a bit of a nightmare. With this proposal, we add a parent key, let's call it L. L_private is stored in some kind of very secure hardware enclave. Every hour/day/whatever, the server generates a new host key K, and asks the enclave to sign the new public key. The server now has K_private, and `host_signature = L_private.sign(K_public)` as generated by the enclave. The client stores L_public in their known_hosts. On session creation, server does `session_signature = K_private.sign(data)` and sends (data, session_signature, K_public, host_signature) to the client. The client finally does `L_public.validate(host_signature, K_public) && K_public.validate(session_signature, data)`. All of this happens on the server side, and the only thing needed is a relatively minor protocol upgrade. The interesting part is that a very similar mechanism already exists for the client's key, making it way easier to manage hundreds of keys across thousands of servers without going crazy by having to update authorized_keys among the entire server fleet multiple times per week.