Securely authenticate SSH hosts
I have successfully used both OpenSSH Certificates and SSHFP to authenticate hosts when connecting to servers using SSH. But I fail to find a way to require the combination of these. Is there a way to tell the OpenSSH client to require both?
I understand that this might seem overkill but if you think this is the case you can treat this as a purely academic exercise.
This isn't really an answer because I have no idea how to make the openssh CLI client do that, short of modifying the c code.
Academically, it's an interesting question whether you actually gain anything by mixing protection models like that; both are methods of authenticating that you are in fact talking to the server that you think you are.
ssh fingerprints say "I have no idea which server I'm talking to, but it's the same server as last time". Security assumption: you were talking to the correct server the first time.
Whereas certificates say "According to the CA, I'm talking to server.domain.com". Security assumption: the CA is honest.
Let's break this down into cases to see if you gain anything by combining them:
Case 1: You trust the fingerprint. Maybe, for example, you called the admin and they read you the fingerprint over the phone. Great, you have full confidence in the identity of the server using the fingerprint alone, the certificate gains you nothing.
Case 2: You trust the CA. They are honest and would not issue a cert for server.domain.com to anyone except the rightful owner. Great, you have full confidence in the identity of the server using the certificate alone, the fingerprint gains you nothing.
Case 3: You trust the CA and the fingerprint. Pick one, either will be watertight by itself.
Case 4: You don't trust the fingerprint or the CA. On first-time connect you were shown a cert from a CA that you don't trust and a fingerprint that you have no way to verify out-of-band. Well, you really can't authenticate this server at all, can you?
Generally speaking, certificates from a publicly trusted CA are a stronger auth method than fingerprints -- unless you are verifying fingerprints out of band, in which case the certificates gain you nothing.
I suppose there's a Case 5: the CA was trustworthy at the time of your first connection to the server, but the CA started misbehaving later. That's basically equivalent to not trusting the CA at all because if you assume that they could become compromised in the future (with no public announcement), then what proof do you have that they are not already compromised? Trusting CAs kinda has to be an all-or-nothing thing. I'm going to argue that if you check fingerprints out of band, then this reduces to Case 1, and if you don't then it reduces to Case 4. Still nothing gained by combining methods.
