18

At my university, we are learning how to use SSH for server administration.

We learned that SSH is secure, but there are some tools that allow man-in-the-middle attacks on SSH.

How can such tools intercept SSH when it is encrypted? I have tried Wireshark but was not able to read the data. Wireshark is only able to read the plain text parts of the SSH protocols.

How does a man-in-the-middle attack on SSH work?

The mitm tool (https://github.com/ssh-mitm/ssh-mitm) allows a second shell to connect to the same SSH session. I have tried it and was able to work in both shells.

Are both sessions the same, or how else can this work? I thought that the encryption should protect me from such an attack.

Reading the docs (https://docs.ssh-mitm.at) does not provide more info on how such an attack works. The docs only explain how to use the tool.

This is the reason why I'm asking the question.

  • Can anyone explain in depth how such an attack works?
  • How is it possible that the same SSH session can be used from 2 different clients?
Improve this question
10
  • 25
    Do you know how Man-in-the-Middle attacks work in general?
    – user163495
    Jun 7, 2021 at 9:51
  • 8
    OP, see en.wikipedia.org/wiki/Man-in-the-middle_attack, and read through the example. Note that there is no notion of 'the same SSH session being used from two different clients'. Note that the attacker replaces Bob's key with her own, and sends this to Alice. This is consistent with what Steffen Ullrich explains in his answer below, i.e. that it requires Alice to be fooled into thinking that the attacker's key is really Bob's.
    – mti2935
    Jun 7, 2021 at 20:05
  • 3
    Why do you think SSH is secure to begin with? (Please don't just spell out the abbreviation). What does Secure mean to you? DIRTY SECRET: it's not much more secure than telnet. particularly on the first connection. sssshhhhhhh don't tell anyone or we'll all freak out.
    – Billy left SE for Codidact
    Jun 8, 2021 at 5:41
  • 15
    @BillyC. "it's not much more secure than telnet" - [citation needed]. If you use it sensibly (i.e. take basic precautions and follow best practices) then, setting aside external vulnerabilities, it is orders of magnitude more secure than telnet. If you believe otherwise then you should post an answer, backing up your claim with explanations and sources.
    – Jon Bentley
    Jun 8, 2021 at 9:40
  • 5
    @JonBentley: The SSH protocol looks sound to me, but I'm not so sure about SSH culture. I'd love to do an experiment to see what percentage of SSH users click through the "key fingerprint changed" warning without any extra checking. My guess is that it would be disturbingly high.
    – President James K. Polk
    Jun 8, 2021 at 21:45

3 Answers 3

Reset to default
55

The basic point of a MITM attack against SSH or SSL/TLS is that the connection is no longer end-to-end encrypted, i.e. from client to server. Instead there is an encrypted connection between client and attacker and a different encrypted connection between attacker and server. Since encryption is terminated by the attacker this way, the attacker has access to the full decrypted traffic:

Secure: [Client]  <---------- End-to-End Encrypted ----------------> [Server]
MITM:   [Client]  <-- Encrypted#1 --> [Attacker] <-- Encrypted#2 --> [Server]

Note that this only works if the client does not check the cryptographic identity of the server (server key) and the server does not check the cryptographic identity of the client (client key, which is optional). If any of these are checked an MITM attack is impossible since the attacker cannot impersonate the server or client without having access to their secret key.

Improve this answer
5
  • 20
    +1, excellent answer, as usual. OP, this is why SSH clients pin the server's public key after connecting for the first time. If an attacker tries to MITM the connection on a subsequent connection attempt by the client, the client's SSH will detect that the public key that it is seeing for the server is different than it was before, and warn the user that there may be an MITM attack underway. This works well for mitigating MITM attacks, except on the first connection to the server (because the client does not yet have the server's public key pinned). Hence the name, Trust on First Use (TOFU).
    – mti2935
    Jun 7, 2021 at 13:46
  • 6
    It is worth noting, that this kind of MITM does not fully work when using keys to authenticate. The attacker can still terminate the ssh session, but it can't forward the authentication to the real destination, because key authentication binds the proof of key possession to the ssh session so it's not reusable in the new proxying session. One of the reasons that key authentication is more secure. The attacker still can try to present you with something that looks believable enough to reveal other secrets though.
    – textshell
    Jun 8, 2021 at 19:11
  • 1
    @textshell: Yes, this is exactly what I've tried to say with (to cite myself): "Note that this only works if the client does not check the cryptographic identity of the server (server key) and the server does not check the cryptographic identity of the client (client key, which is optional). If any of these are checked an MITM attack is impossible since the attacker cannot impersonate the server or client without having access to their secret key."
    – Steffen Ullrich
    Jun 8, 2021 at 19:43
  • Deploy PK auth; the MITM goes away. The session is rekeyed using the PK data that cannot be forged.
    – Joshua
    Jun 9, 2021 at 2:43
  • @mti2935 interestingly, when you want to set up SSH to some popular services (e.g. Azure DevOps, just an example), they will publish in bold the server key fingerprint along with the URL to connect, so that you will check the first time you git fetch. It's up to the average programmer to type yes
    – usr-local-ΕΨΗΕΛΩΝ
    Jun 9, 2021 at 21:03
23

Because you're telling it the connection is secure

When you connect to an SSH server for the first time, you get this message:

The authenticity of host '<host> (<IP Address>)' can't be established.
<algorithm> key fingerprint is <hash>.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

When you type yes, you're told: Warning: Permanently added '<host>' (<algorithm>) to the list of known hosts. Here, you've marked this connection as secure, and that you trust that you're connecting to the actual machine. When you reconnect, if the server presents the same key, no warnings are shown. If you were to connect to a MITM server the first time, you would get this same message—there's no magic way for your computer to detect if any given SSH server is who you think it is or not. If you didn't spend the time to manually check the machine's fingerprint on a separate channel, you would blindly trust it and be none the wiser.

However, if you were to reconnect to a server and someone intercepted your connection, you would get this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the <algorithm> key sent by the remote host is
<hash>.
Please contact your system administrator.
Add correct host key in /home/<username>/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/<username>/.ssh/known_hosts:<line number>
Host key for <host> has changed and you have requested strict checking.
Host key verification failed.

Here, you can see quite explicitly that it's warning you about this exact attack—it explicitly says "man-in-the-middle attack" on the 3rd text line, and doesn't allow you to connect.

The big picture is that encrypted communications don't matter if you never verify that the person you're talking with is who you think they are. SSH even makes you explicitly tell it that you are sure. To verify it, you should run ssh-keyscan <host> on a trusted computer—for example, one plugged directly into it, or even better, ssh-keyscan localhost on the target machine itself. Then, either type fingerprint at the prompt and paste in its output, or verify it manually and only then type yes.

Improve this answer
6

As far as I can tell from the description of ssh-mitm, the answer is that it isn't a man-in-the-middle: it's a proxy. The client knows that it's talking to the proxy, not to the server. The client connects to the proxy, and when it connects, it verifies the identity of the proxy. When the proxy receives an incoming connection, it opens a connection to the actual server, and relays data back and forth. There is no attack since the client chose to talk to the proxy.

Improve this answer
2
  • 1
    Seems like just semantics here, a MiTM is a proxy, but a proxy is not necessarily a MiTM.
    – President James K. Polk
    Jun 8, 2021 at 21:43
  • 4
    A proxy IS a MiTM, just not a MiTM attack.
    – AbraCadaver
    Jun 9, 2021 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.