Ssh does client authentication after handshake. The server is required to sign the handshake result with its private key, so you won't get past handshake if you are a server that claims to have a public key that you don't know the private key for.

E: see RFC 4253, sections 8 and 10, and RFC 4252 for corroboration

Huh, I had erroneously thought the exploit string was sent earlier in the connection, before the handshaking completed (note the "handshake failed" error in xzbot on successful exploit, and also the fact that no logging is done).

But you're right: we've verified the hostkey by the time we send the special certificate. So there's no way to effectively replay this without access to the server keys. My original comment is incorrect.

I'm actually surprised there's no logging at INFO or higher after this succeeds, given that openssh typically logs preauth connection closes. But I guess the crutch is that we never log connection opens and we only really log failures in handshaking, and it's not like the backdoor is going to go out of its way to log the fact that it opened itself...

The whole point of asymmetric-key is that a middleman can't do that. Even if you relayed the entire handshake, all traffic after that is just line noise to you unless you have the transmitter's private key. You can't read it or mangle it (well, you can mangle it, but the receiving party will know it was mangled in transit). The exploit string on the wire for that transmission won't work in the context of any other transmission sequence.

Yeah I had mistakenly thought the exploit string was transmitted during key exchange (read too quickly on "pre-auth"), which is incorrect; see sibling comment. I'm unfortunately past the edit window now.

I suppose the original attacker could give really fancy exploit strings that verify the eventual payload strongly enough to prevent someone replaying the attack from accomplishing much.