As far as I know, SSH2 first does a key exchange based on the server host key an

Question

As far as I know, SSH2 first does a key exchange based on the server host key and brings up transport authentication and encryption derived from this kex. The real authentication (password or public key) is done over this secure transport.

If you set the cipher to 'none', you wouldn't want to allow password authentication because then the password would be sent in plaintext. But what about public key authentication?

I believe pubkey auth works by the server sending a nonce to the client, the client signing it with its private key, and the server verifying the signature. How is the overall system weakened if this exchange happens in the clear?

I can think of at least:

known-plaintext (passively capture (nonce, Dk(nonce)) and try to derive k)

chosen-ciphertext (intercept and replace the nonce, capture Dk(chosen))

Is RSA (specifically, the way it's used by the raw SSH public key authentication) vulnerable to either of these?

Explanation / Answer

It is critical to combine both the key exchange and the secure channel, otherwise someone can mount a man-in-the-middle attack.

The way we prevent a man-in-the-middle attack is to do a key exchange, to exchange a session key that both endpoints know but no one else (including the man-in-the-middle) can know, and then authenticate both endpoints. You seem to suggest that we remove the encryption, remove the secure channel, don't bother negotiating a session key. If we did that, then the protocol would become vulnerable to man-in-the-middle attacks (active attacks), because nothing binds the signature/authentication phase to the rest of the stuff sent over the SSH channel.

Related Questions

Navigate

• Browse (All)
• Browse A
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.