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!

Update 2024-06-29:

MitM attacks on SSH do not only affect the final authentication step. For instance, the "terrapin" attack occurs before the actual authentication process. Although not directly part of public key authentication, this type of attack can undermine security features of modern clients, thereby influencing the overall authentication process by bypassing these security measures.

There is also an optional public key lookup step that sends all known public keys to the server. This information can be used by an attacker to check if the user is allowed to login or to identify more valuable targets. This information leak is documented under CVE-2016-20012 and is described in RFC-4252. While this behavior is optional according to the RFC, all current SSH clients send the public keys to the server, and there is no option to disable this.

As previously mentioned, this can be exploited to force clients to log into a malicious SSH server (OpenSSH: PuTTY: CVE-2021-36368, Dropbear: CVE-2021-36367, CVE-2021-36369).

Both vulnerabilities together allow an attacker to determine if a user is permitted to log in and whether the malicious server only accepts the same private key that would be used for signing with the target server. This can be used to spoof or phish login attempts with private keys protected by FIDO tokens. See https://www.openssh.com/agent-restrict.html

It's important to note that even if an attacker intercepts information during a MitM attack, they cannot generate a valid signature for logging into the target server, provided that a sufficient key length is used and the client does not have security vulnerabilities (CVE-2024-31497).

In conclusion, while MitM attacks on public key authentication are possible, their impact in the default configuration is relatively minor. It's crucial, however, to always verify the server's public key and avoid agent forwarding as best practices.

  • "Private/public key authentication does not protect you against mitm attacks." Reading this answer and the ssh-mitm docs, I don't see how this is true when no agent forwarding is enabled (which is the default). It would be good to expand this answer and ssh-mitm docs to clarify this - at the minimum by providing a scenario that shows how it's possible without agent forwarding. Commented Jun 28 at 13:29

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 .