12

How do you improve the security of your ssh session against a man-in-the-middle attack?

Improve this question
2
  • 2
    This question is pretty vague and open-ended. Are you asking specifically about MITM attacks or about good security practices more generally? Have you glanced through questions with the ssl tag to see if there's anything that matches what you are looking for?
    – D.W.
    Commented Nov 5, 2012 at 6:27
  • I am specifically asking about MITM attacks and the best way to remove/minimised the threat
    – Paperghost
    Commented Nov 5, 2012 at 6:58

3 Answers 3

Reset to default
9

Make sure you pay attention to the warnings about changes to the server's public key. If you get a warning like this, say "no" and check the public key fingerprint through out-of-band means; don't say "yes" unless you have verified the public key fingerprint somehow.

If you never connect to new hosts, you can set

StrictHostKeyChecking yes

in your ~/.ssh/config configuration file (or in /etc/ssh/ssh_config). However this may be annoying if you frequently connect to new machines.

Read the section VERIFYING HOST KEYS of the ssh man page.

Read How do RSA fingerprints protect from MITM attacks? on this site.

Use a SSH private key, not a password, to authenticate.

If you are in control of your own infrastructure, you can look into setting up ssh certificates for both hosts and users. This allows the ssh client to verify the identity of the ssh server. This may be the best solution against man-in-the-middle attacks, as it eliminates the need for users to check fingerprints carefully. Realistically, many users probably won't bother to check, so ssh certificates may be a more usable and more reliable defense.

Improve this answer
1
  • 2
    "unless you have verified the public key fingerprint somehow". This "somehow" is the key. What are the actual practical ways of handling the scenario of ssh suddenly telling the user that the server's key has changed? Or is it the case that nobody really cares about MITM attacks, and everybody simply adds the new key without doing any verification?
    – michau
    Commented Jul 31, 2019 at 19:22
5

Always authenticate with public keys (better yet, turn off password authentication entirely in /etc/ssh/sshd_config), this should thwart any MITM attack against OpenSSH.

Here is a short explanation that goes into more detail: http://www.gremwell.com/ssh-mitm-public-key-authentication

Improve this answer
4
  • 2
    No, the choice of user authentication methods is not important. It is both necessary and sufficient for the client to authenticate the server. Turing off password authentication can be a good idea but the threat is not a MITM against the SSH connection but a leak of the password through another channel (shoulder surfing, use of the password in an insecure protocol, …).
    – Gilles 'SO- stop being evil'
    Commented Nov 5, 2012 at 13:01
  • @Gilles : If you are connecting via ssh, using a key (not typing in username and password), can a MITM acquire what is necessary to become an invisible intermediary between you and a ssh server?
    – Lonnie Best
    Commented Jan 22, 2015 at 20:24
  • 1
    @LonnieBest Yes if the client doesn't already know the server's key, no if the client already does. This holds whether the client authenticates with a key or with a password or any other method. If the MITM happens and is not detected, then with a password, the attacker can initiate new connections to the server, which I think can't happen with the key. However the MITM can also infect the server with malware (e.g. add a key to the authorized_keys file), which is more detectable than grabbing the password but bad anyway.
    – Gilles 'SO- stop being evil'
    Commented Jan 22, 2015 at 20:35
  • 4
    @Gilles did you read the link posted by Charles? It looks like public-key authentication actually protects against a MitM attack by including the session-identifier in the signature, which is different between client–MitM and MitM–server. (Though it does not protect against an attacker just pretending to be the real server).
    – Paŭlo Ebermann
    Commented Aug 23, 2016 at 14:28
1

In a MITM typically the attacker is pretending to be the real server. The attacker isn't going to pass along the real server's public key because it doesn't have the corresponding private key; therefore the assumption "We assume that MITM attacker has already managed to circumvent the server host key validation and tricked the peers into establishing the connection" means that the client has established an SSH connection terminated at the attacker. The attacker in turn is establishing a connection to the real server and presenting its own public key.

The session ID thing is a complete red herring because the attacker simply won't pass that along; it will establish one legitimate client connection and terminate the client's connection, and proxy input/output between the two connections.

Improve this answer
1
  • 3
    How is the MITM attacker going to authenticate with the real server when it doesn't have the user's private key? As far as I understand, in the case of public key authentication, the only thing an MITM attacker can do is to pretend to be to be the real server without being able to connect to the real server, which means it will be very hard for such an attacker to reproduce a shell session with the real server. My understanding is confirmed here.
    – michau
    Commented Jul 31, 2019 at 20:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .