Does public key auth in SSH prevent most MITM attacks?

Question

I found this article that claims asymmetric crypto signature of DH-obtained key prevents MITM:

http://www.gremwell.com/ssh-mitm-public-key-authentication

Key idea:

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.

Assumptions:

• M sits in the middle of communication, intercepting all communication between A and B

• M somehow tricked A into thinking that he's B and also tricked B into thinking he's A (re fingerprints etc).

• However, M has not managed to penetrate either A's machine nor B's machine, leaving A's public key at A's account on B machine intact

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.

=> while M can fake DH exchanges to A and 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.

Questions:

1. is this reasoning correct? if not, where are the mistakes?

2. is session ID creation the "weakest link" in this chain? That is, if M could 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 M would have "genuine" session ID signed by A and so B would think that auth signature is OK?

I realize this is near impossible in practice, but is it completely theoretically impossible?

Answer 1

1.Yes it is correct. There are 2 possible ways:

A) Alice blindly accepts the new fingerprint from the attacker mallory. Alice and Mallory could connect and authenticate each other. Problem here for Mallory is, that he couldn't sign the session id, exchanged with Bob. Because Mallory doesn't own Alice's private key. And also Mallory couldn't redirect the signed session id from Alice to Bob, because the session id would be, with high probability, different.

B) When Alice doesn't blindy accept the new fingerprint, Mallory could send the public key and thereof the fingerprint from Bob. Problem here would be that Mallory couldn't authenticate to Alice, because Mallory didn't own the private key from Bob.

NOTICE: In Case A), when Alice also accept a password authentication, mallory would configure his server to authenticate the client with password authentication and so mallory would get the username and password.

---

2.Yes, theoretically it would be possible. See in A), why should Alice not accept the right signed ID from Bob? She would accept :) And also Alice would accept the right signed id from Bob. Mallory needs only to show Alice the Public Key from Bob on connection build up.

Answer 2

Here's where this fails. You assume:

M somehow tricked A into thinking that he's B and also tricked B into thinking he's A (re fingerprints etc).

Fingerprints are something that cannot be duplicated. A fingerprint (otherwise known as an HMAC) is a hash of the secret key. The secret key is never transmitted, but calculated independently by both the client and the server using the preshsared master key.

In PKI, the private and public key are useful because a) the private key cannot be derived from the public key and b) the public key can be used to encrypt data that can be decrypted with the servers private key, and vice versa.

Therefore, without knowing the servers private key, you can never perform a useful MITM attack on an SSH session. Plus, most times SSH will simply resume a session rather than negotiate a new one. This involves sending the session ID in plain text, but resuming encryption with the pre-determined cypher suite, which is unknown to the attacker, or [M], in this scenario.