12

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

D.W.
  • 98,420
  • 30
  • 267
  • 572
Paperghost
  • 123
  • 1
  • 1
  • 5
  • 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 [tag:ssl] tag to see if there's anything that matches what you are looking for? – D.W. Nov 05 '12 at 06:27
  • I am specifically asking about MITM attacks and the best way to remove/minimised the threat – Paperghost Nov 05 '12 at 06:58

3 Answers3

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.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 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 Jul 31 '19 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

Charles Boyd
  • 188
  • 5
  • 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' Nov 05 '12 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 Jan 22 '15 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' Jan 22 '15 at 20:35
  • 3
    @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 Aug 23 '16 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.

John Collins
  • 11
  • 1
  • 1
    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](https://security.stackexchange.com/questions/63288/what-are-the-security-issues-of-a-mitm-on-an-ssh-session-with-rsa-keypair). – michau Jul 31 '19 at 20:04