> I'm actually surprised the ssh protocol doesn't have MITM mitigation built in. Part of the original U2f Spec was that the TLS session State could be hashed an

> I'm actually surprised the ssh protocol doesn't have MITM mitigation built in. Part of the original U2f Spec was that the TLS session State could be hashed and included as part of the client signature, effectively making MITM impossible. When you use SSH public key authentication, a hash of the key exchange (called the "session identifier") is included in the client signature, much like the U2F channel binding you describe: https://datatracker.ietf.org/doc/html/rfc4252#section-7 https://datatracker.ietf.org/doc/html/rfc4252#section-7 This provides the same amount of protection as the U2F channel binding: namely, the MitM is unable to forward the signature to the server and successfully authenticate to the server as the client. However, neither SSH nor U2F channel binding prevents the MitM from impersonating the server and hoping the client transmits something confidential. The SSH-MITM tool supports redirecting clients to a honeypot for this purpose. Additionally, if the SSH client has agent forwarding enabled, the MitM can just ask the client to sign a new signature in order to authenticate to the server. The SSH-MITM tool also supports this. Bottom line, no amount of channel binding in the authentication protocol is a substitute for correctly validating the server's identity, especially if you have SSH agent forwarding enabled.