I read somewhere that when using key based login instead of a password based login, it is not possible for a Man-in-the-Middle attack to happen.

This question is not about what is being more secure: key based login or password based login.
Instead I am interested in knowing:

  1. the steps taking place during a key based login,
  2. why it is not susceptible to MiTM attacks.

3 Answers 3


First, a man in the middle attack can neither happen with key based nor with password based authentication if the client properly authenticates the server.

A man in the middle attack is possible if a password is used only if the client ignores the warning that the server fingerprint has changed. In this case the client would unknowingly create a connection to the attacker, which as the endpoint of the connection can read the plain password as entered by the user and then can forward the data to the original server.

If instead a key pair is used for authentication then the client does not provide the private key but only provides the proof that it owns the private key to the public key known by the server by signing some message. The message to be signed contains the session identifier of the connection which itself is a result of the key exchange and thus different for the connection between client and attacker and attacker and server. This means that the ownership proof given by the client to the attacker cannot be reused by the attacker as an ownership proof to the server and thus authentication against the server will fail.

Note that this is very similar to client certificate based authentication in TLS. Therefore see also Does mutual authentication have any impact on MiTM possibilities?.

  • Ullrich, don't think SSH enforces authentication, may be u are messed between SSL/TSL and SSH.
    – joven
    Commented Feb 21, 2018 at 15:55
  • 6
    @joveny: if you try to connect the first time to a server you get its fingerprint and should verify it against the expected value. If you connect later again it will warn you if the fingerprint has been changed. This is authentication actually and is very similar to what you experience when using self-signed certificates in TLS. Commented Feb 21, 2018 at 15:59
  • @joveny when talking about ssh, the default implementation of the protocol is assumed. I know of no ssh clients that do not make use of explicit TOFU and then authenticate subsequent requests based on that.
    – Tobi Nary
    Commented Feb 21, 2018 at 16:03

When you are using private/public key authentication and agent forwarding, a full ssh mitm attack is still possible. Agent forwarding is a security issue and should not be used.

In cases, when agent forwarding is not used, a full ssh mitm attack is not possible, but an attacker can redirect the traffic to another server and log your input. When you are using sudo and enter your password in such a session, the attacker has your password.

If password authentication is not disabled on your server, the attacker can connect to your server and redirect the current session to the new server.

If you want to try mitm attacks to learn more about them, there are some open source mitm proxy servers: https://github.com/ssh-mitm/ssh-mitm (I'm the author of this tool)

Private/public key authentication does not protect you against mitm attacks. It only makes it harder for the attacker to gain access to your server.

The most important is to verify the server fingerprint!


It's large topic. Here I intend to share some details w/o too much that are not needed and a good reference.

Man-in-the-Middle is not thwarted by user authentication but by server authentication. Before the user is authenticated, the server is.

That is done via Diffie-Hellman to come up with a shared secret K and a hash, the session identifier H. A man in the middle would need to do a DH exchange between the Client and themself and themself and the Server. Both of those outputs will be guaranteed to be different.

The server signs the session identifier H with it's private key. The client verifies it with the server's public key. Keep in mind it's trust on first use so it's open to MITM until the public key is associated to the specific server (i.e known_hosts in openssh/etc).

The RFC has more details.


  • +1. Resonable and simple explanation. But, DH (Diffie-Hellman algo) itself is susceptible to MiTM attack. So can "Both of those outputs will be guaranteed to be different." be true during MiTM. Can you add any more info over DH and MiTM.
    – samshers
    Commented May 4, 2019 at 16:26
  • @samshers - thanks - added a few bits.
    – james6125
    Commented May 25, 2019 at 0:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .