On Thu, Dec 12, 2024 at 10:59 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2024-12-12 10:28:30 +1100 (+1100), Michael Still wrote: [...]
This "feature" was added at the request of mordred (Monty Taylor) IIRC. He was specifically concerned about knowing that the machine that he had requested was the one he was actually connecting to. At the time I had reliability concerns because parsing the console log is actually a little hard to do reliably. [...]
Yes, this dates back to the early days of us collectively (the OpenDev Collaboratory, nee Infrastructure project team, nee CI team) trying to establish a solution to that challenge.
SPIFFE calls this problem space "identity zero" if that helps. AWS solves it these days with a thing called an "instance identity document" which is part of the instance metadata. Possession of that document proves you are a specific instance (it does however not stop other software on that instance from also proving that thing).
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-docume...
How does that work in practice? I guess you'd have to connect to the instance, temporarily accept the dubious hostkey, then read back the identity document from a shell on the instance? It doesn't necessarily get around ToFU, but does at least give a clear signal once you've tentatively accepted the key as to whether you can keep or wipe it and discard the instance/report the incident.
Oh sorry, I should have provided more detail here. SPIFFE is a specification. The reference implementation, SPIRE, solves this problem by running an agent on the instance. That agent collects the identity document on boot, and then contacts a SPIRE server to turn that into an X.509 certificate that attests to the identity of the instance. That's then used for things like the client side of a certificate exchange for mTLS. I guess in this case you'd use that X.509 certificate as the "ssh hostkey", although this isn't my field enough to understand if that sentence actually makes sense. That is, SPIFFE / SPIRE are more focused on the mTLS identity use case than the ssh identity use case. You could certainly connect to the instance and verify it had a trusted identity issued by SPIRE? As an aside, there once was an OpenStack SPIRE attestor (what the agent bit that does the identity document is called), but it appears to have bitrotted -- https://github.com/zlabjp/spire-openstack-plugin/blob/master/doc/openstack-i.... That page links to https://docs.google.com/document/d/1HkK3Q74yYiqckBMI-h9FrZdlWEkrY5R4uHbXRqSR..., which correctly notes that there is probably something cool with vTPMs that could be done in this space, although I haven't spent a lot of time thinking about it. Cheers, Michael