I found this article that claims asymmetric crypto signature of DH-obtained key prevents MITM:
The value of 'signature' is a signature by the corresponding private key over the following data, in the following order:
string session identifier byte SSH_MSG_USERAUTH_REQUEST
Now the attacker has a problem, as the client and the server have different ideas about what session identifier is supposed to be. Obviously, the server will reject the signature supplied by the client and public-key authentication will fail.
I'd like to verify if my understanding of this is correct:
Let Alice (
A) be client, MITM (
M) an attacker and Bob (
B) a ssh server.
Msits in the middle of communication, intercepting all communication between
Ainto thinking that he's
Band also tricked
Binto thinking he's
A(re fingerprints etc).
Mhas not managed to penetrate either
A's machine nor
B's machine, leaving
A's public key at
A's account on
As long as above conditions hold on top of this one:
The session identifier is calculated based on (among other things) the shared secret negotiated by the peers using Diffie-Hellman algorithm.
M can fake DH exchanges to
B, those necessarily will have to be 2 different (fake) shared secrets (unless there's some way for
M to compromise that by modifying exchanged DH numbers, not by observing them).
When this shared secret is used as component of creating data to be signed (part or whole of session identifier), one thing that
M cannot fake and does not know is
A's private key that will be used for signing session ID based on (1st) faked shared secret.
So either digital signature of session ID (+other session data per description above) fails verification at
B, or session IDs will not match, effectively breaking communication.
is this reasoning correct? if not, where are the mistakes?
is session ID creation the "weakest link" in this chain? That is, if
Mcould predict it (e.g. if it's predictable one-way hash that is susceptible to statistical attack, even if DH itself isn't) and guess it somehow (very improbable, yes, but is it even theoretically impossible?), then
Mwould have "genuine" session ID signed by
Bwould think that auth signature is OK?
I realize this is near impossible in practice, but is it completely theoretically impossible?