7

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

  • 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. Nov 5 '12 at 6:27
  • I am specifically asking about MITM attacks and the best way to remove/minimised the threat – Paperghost Nov 5 '12 at 6:58
6

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.

  • 1
    "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
4

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

  • 1
    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 5 '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
  • 2
    @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.

  • 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 Jul 31 '19 at 20:04

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.