Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know SSH is secure as long as you're not suffering a MITM attack, but I want to know if there's a way to make SSH 100% secure even under such circumstances, discover you're being sniffed and disconnecting before any sensitive information is disclosed, or at least making it not impossible, but "more tough" for the attacker to actually read/write actual data (maybe there's a way of garbling the data so it doesn't make sense or something?).

I think you got what I want.

For example, if you refuse to connect in case the fingerprint isn't the one you expected, do MITM still work?

I'll try to update this question if ideas pop in my mind.

share|improve this question
You can defeat MitM attacks by pre-sharing keys. – CarlF Apr 20 '11 at 20:29
Yeah, I think that should work. – n2liquid Apr 22 '11 at 18:47
up vote 5 down vote accepted

discover you're being sniffed

This is exactly what SSH protects against. As long as you carefully verify the host key, it doesn't matter if someone is reading your traffic: it's all encrypted.

disconnecting before any sensitive information is disclosed

Again, standard SSH will be fine. Host key checking is one of the first things done when establishing a SSH connection; if you cancel it, the connection is closed immediately without transmitting any authentication data.

For example, if you refuse to connect in case the fingerprint isn't the one you expected, do MITM still work?

The attacker will not receive any "private" SSH data, if that's what you mean. See above – checking of host key is one of the first things done. Nothing else is sent until the server is verified.

maybe there's a way of garbling the data so it doesn't make sense or something?

It's called "encryption", and it happens to be a core part of SSH. :) The attacker will not be able to read anything unless you accept their hostkey instead of the real one. Similarly, encryption along with integrity check (using HMAC) makes it impossible to insert packets.

I'll admit that I'm not a cryptographer or anything. But IMHO, if you carefully check the host key fingerprint, then SSHv2 is as secure as it gets.

  • If it weren't secure, it would have been fixed/replaced/upgraded. This has happened once: SSH v1 was replaced by SSH v2.

  • This means that you must disable SSH v1 in both the server and client.

    SSH version 1 is very insecure, and even though most clients are configured to use SSHv2 first, they would still fall back to v1 if a server doesn't offer v2. This introduces an opportunity for a MITM attack... although I don't remember the details, it has something to do with the attacker generating a v1 key with a very similar fingerprint.

    For OpenSSH, put Protocol 2 in your config file.

  • There's a very small possibility that one of the algorithms used by SSH is broken. But if someone manages to break RSA or DH, the world will have bigger problems to worry about than your server's security... (Besides, there are alternative algorithms.)

By the way, OpenSSH v5.8 has switched from DH and DSA to ECDH and ECDSA as its primary algorithms (for key exchange and host keys respectively).

share|improve this answer
Just to clarify one bit of your answer, the host key is presented by the server to the client before you send anything beyond the initial handshake -- i.e. no username, no password, no key, no nothing has been sent. That part you said, but what I want to clarify is this: The host key is impossible to forge without first acquiring the server's private key, which first requires gaining access to a privileged account (i.e. root) on the server. Don't use weak passwords (better yet, use keys instead of passwords) and you should be fine so long as you verify the host key. – Kromey Apr 20 '11 at 20:48
@Kromey: True, but it is possible to create different keys with very similar-looking fingerprints; see Fuzzy fingerprints project. – grawity Apr 20 '11 at 20:55
@grawity True, but "similar-looking" is not "same", and every single SSH client I know of stores the host key and compares it for an exact match only later, complaining loudly or even refusing to connect at all if even one byte is off. So long as you correctly verify that key on the initial connection, you're golden. – Kromey Apr 20 '11 at 20:59
"Exact match" includes the key algorithm and protocol version, which also have to be carefully verified. If the client has RSA key stored but server only presents DSA, some clients will only pop up a confirmation dialog. (Latest OpenSSH handles this much better.) – grawity Apr 20 '11 at 21:04
Okay, so if I receive some fingerprint different from what I expected I have nothing to do but to not connect? If it could be done, it would be part of SSH, right? – n2liquid Apr 20 '11 at 21:26

SSH is NOT fine, it's prone to the man-in-the-middle attack.

Microsoft is doing such an 'attack' on your connection if there is a Forefront TMG firewall between you and the server that you try to reach. And that includes spoofing SSH certificates.

share|improve this answer
Is it able to spoof the certificates with identical fingerprints as the original ones? – grawity Jul 11 '12 at 12:35

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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