Is man-in-the-middle attack a security threat during SSH authentication using keys?

Question

I am no expert in network security, so pardon if this question is not very smart :). I am automating logins to some machines using ssh. I am currently avoiding host-key warnings using StrictHostKeyChecking no.
I naively understand that someone can impersonate as the server and I risk losing my password to him if that were the case. However, if I am using only public/private Key based authentication ( using PasswordAuthentication no ), can the intruder still cause harm?

So basically, with ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" :

1) Can the intruder decipher my private key?

2) Are there any other security threats?

regards,

JP

Solution 1

1. No. Or atleast... not directly. Since you never send your private key, the key will be safe. That doesn't mean that the person that is executing the MITM attack can't execute commands and/or read the output you're getting.

2. Yes, there are other risks. If the person executing the MITM attack forwards the data to the correct server than it might be possible to use your private key to execute commands on the machine you were trying to access.

Solution 2

Actually, public-key authentication method prevents MITM attack. As far as I can tell, it is a coincidence, not by design. While full-blown MITM attack is not possible, the attacker still can impersonate the server: receive commands and data sent by the client and return arbitrary responses to the client. So it might be not a good idea to disable server host key checking after all.

Below is the explanation why full-blown MITM attack cannot be executed when public-key authentication is used. My blog post http://www.gremwell.com/ssh-mitm-public-key-authentication contains some more details.

During MITM attack, the attacker inserts themselves in between the client and the server and establishes two separate SSH connections. Each connection will have its own set of encryption keys and session id.

To authenticate using public-key method, the client uses the private key to sign a bunch of data (including the session id) and sends the signature to the server. The server is expected to validate the signature and to reject the authentication attempt if the signature is invalid. As explained above, the server and the client will have completely different idea about what session id is supposed to be. It means there is no way for the server to accept the signature generated by the client under MITM attack.

As mentioned above, the session ids are guaranteed to be different for client-MITM and MITM-server connections. They are calculated from on the shared secret negotiated with Diffie-Hellman, separately or each connection. It means the attacker cannot arrange two sessions to have the same session ids.

Comments

[Harvey Kwok]

Just wonder why you you would like to avoid host-key warnings? Normally, it is prompted only once and it's only at the first time you logon that server if you don't change the host key. Is it really that annoying? To avoid the trouble of distributing host key to a lot of different client machines, you can use Kerberos authentication in SSH. Then, SSH can be configured to use NULL host key algorithm. It is possible because Kerberos authentication will do mutual authentication, which can assure the server identity.

[Bruno]

Interesting. This is similar to using client certificates with SSL/TLS: there's a Certificate Verify message at the end of the handshake, signing the whole handshake so far. The server and the client wouldn't have the same handshake data with a MITM.

[Jaap Eldering]

This answer seems incorrect, see also the detailed answer with references by abb.

[Wolph]

@eldering: I have updated the answer to clarify the answer but I don't see what is/was incorrect about the answer. Can you explain what would be wrong?