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.
I wonder if injecting the ssh hostkey via user-data is a meaningful way to solve these problems as well? [...]
It could, though at the expense of the private part of the hostkey existing (even temporarily) somewhere other than the server instance itself. If it's generated on the instance and only the public component of the pair is disclosed, then there's less debate as to whether it's possibly been leaked. But for a lot of risk models this is likely fine yes (after all, it's not like the end user can 100% trust the provider's storage backend, staff, whatever, so at some point you have to decide what amount of risk is acceptable and move on). -- Jeremy Stanley