implications of SSH server key compromission when authenticating users against a public key Friday we had a disagreement with a colleague of mine about the implications of SSH server key compromission

The question was stated as this :


  What could a hacker do while provided with the SSH server private key
  and a MitM position specifically when the client is authenticated with a 
  public key (server configuration disallow password-based authentification)


after 20 minutes we could agree on the following facts :


Stream decryption (eg. Is SSH using temporary keys encrypted with both public keys ?)
Stream tampering (same question with HMAC keys)

Identity theft : (being able to tamper a root connexion and replace users public keys with the hacker's in the server ; user's private key is safe in his computer ... is it ?)
Identity substitution : being able to hijack the auth dialog to the compromised server and replay it in real time with an other non-compromised server auth dialog (==> hacking server A, hijaking client C connection to server A and connecting the pirate as C to the non-compromised server B)

(placeholder for any other ideas :) )


Can anyone help us to sort these out ?



Answer see @PauloEbermann answer below or this article http://www.gremwell.com/ssh-mitm-public-key-authentication
In the common configuration of SSH, the session keys (and a session ID) will be negotiated using the Diffie-Hellman key exchange, and then authenticated by the server, using its private key to sign all the exchanged data (which is then checked by the client).

The public key authentication of the client happens after that, when the actual connection is already running, and does not influence the encryption (and MAC). But the public-key authentication is a signature over multiple values, including the session identifier.

So, in effect, if the attacker has the server's key she can pretend being the server (to the client). She would have to accept the public key login, and show the client some shell or similar.

What does not work for the attacker is to connect at the same time (as a client) to the server and use the client's public key authentication to authenticate itself to the server, as the signature includes the session ID, and the session ID will be different for different Diffie-Hellman key exchanges.

Also, it seems not possible to manipulate the Diffie-Hellman key exhange in a way that one still knows the created keys, and they (as well as the session ID) are the same for both connections.

With RSA key exchange (where the client simply RSA-encrypts the some random data with a transient server key and sends it to the server, and both sides derive everything from this then shared secret (and the other stuff that was exchanged, like the public key, the offered key exchange methods and so on), a MiTM-attack (knowing the server's transient private key) is feasible - simply decrypt this message, then you know the keys used both for encryption and authentication (and the message-ID), and can read and modify all further messages.

If she only knows the server's long-term private key, this is not so simple: While she can replace the transient server key with her own one, this results in a different session ID (and session keys), and as such the public-key authentication of the client will not work anymore for her.