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, $D_k(nonce)$) and try to derive k)
- chosen-ciphertext (intercept and replace the nonce, capture $D_k(chosen)$)
Is RSA (specifically, the way it's used by the raw SSH public key authentication) vulnerable to either of these?
Edit: my original formulation was incorrect: RSA signs by decryption, not encryption. Which points to an attack on textbook RSA: How does a chosen plaintext attack on RSA work? but NOT on the RSA used in practice in SSH and SSL. PKCS#1 padding protects against this attack.