Currently we use ssh-keyscan at runtime to make ssh not bother us about ssh keys.
This is technically not safe, since the ssh security model inherently relies on us receiving those ssh keys from a known-good point; TOFU is considered acceptable for general use, since MITM attacks are not that common and if they occur you will find out eventually, which is why ssh-keyscan exists.
In this case, however, because our keys do not persist between runs, we don't TOFU as much as we TOEU. This is much more risky.
The downside of hardcoding the keys is that if they rotate our builds will fail until we update them. That said, assuming key rotations are uncommon enough that this isn't a real burden, it may be a worthwhile trade-off for supply chain security, especially if we start publishing our binaries.
Bonus points if servers use DNSSEC and publish an SSHFP, then we should just use that instead.
Currently we use
ssh-keyscanat runtime to make ssh not bother us about ssh keys.This is technically not safe, since the ssh security model inherently relies on us receiving those ssh keys from a known-good point; TOFU is considered acceptable for general use, since MITM attacks are not that common and if they occur you will find out eventually, which is why ssh-keyscan exists.
In this case, however, because our keys do not persist between runs, we don't TOFU as much as we TOEU. This is much more risky.
The downside of hardcoding the keys is that if they rotate our builds will fail until we update them. That said, assuming key rotations are uncommon enough that this isn't a real burden, it may be a worthwhile trade-off for supply chain security, especially if we start publishing our binaries.
Bonus points if servers use DNSSEC and publish an SSHFP, then we should just use that instead.