I have often advised people to use an SSH tunnel to secure their browsing on open WIFIs or in other insecure situations.
I was recently asked by a friend how secure a SSH tunnel is after I had suggested SSH tunneling. I stumbled a bit and reiterated "its secure".

Even though he was satisfied with this answer it bugged me a bit that I couldn't fully answer.
So the question goes out to you guys:

"How secure is an SSH tunnel?"

  • 1
    Short comment; Providing a SSH tunnel is used, the security of that connection is only as good as its endpoints. Meaning that if someone/something has lowlevel access to OS or network, it is possible to hook into the carrier and read the content of the tunnel.
    – Mogget
    Oct 1, 2015 at 13:00

3 Answers 3


I'd just like to quote a little from Wikipedia here:

Even if a symmetric cipher is currently unbreakable by exploiting structural weaknesses in its algorithm, it is possible to run through the entire space of keys in what is known as a brute force attack. Since longer symmetric keys require exponentially more work to brute force search, a sufficiently long symmetric key makes this line of attack impractical.

With a key of length n bits, there are 2n possible keys. This number grows very rapidly as n increases. Moore's law suggests that computing power doubles roughly every 18 to 24 months, but even this doubling effect leaves the larger symmetric key lengths currently considered acceptably well out of reach. The large number of operations (2128) required to try all possible 128-bit keys is widely considered to be out of reach for conventional digital computing techniques for the foreseeable future. However, alternative forms of computing technology are anticipated which may have superior processing power than classical computers. If a suitably sized quantum computer capable of running Grover's algorithm reliably becomes available, it would reduce a 128-bit key down to 64-bit security, roughly a DES equivalent. This is one of the reasons why AES supports a 256-bit key length. See the discussion on the relationship between key lengths and quantum computing attacks at the bottom of this page for more information.

So a 128 bit key would have 340,282,366,920,938,463,463,374,607,431,768,211,456 possible permutations. Imagine going through all those. Even a powerful desktop computer can only try a few per second.

So although it's theoretically possible to brute-force decrypt an SSH stream, by the time the key has been decrypted by the most powerful computer imaginable two things would have happened:

  1. The key would have been changed by SSH
  2. We would all have died and the sun exploded and destroyed the earth.
  • 13
    +1 In just 12 seconds I learned that I and everyone I know is going to die and the sun is going to explode.
    – MetaGuru
    Jan 15, 2013 at 14:04
  • 1
    @ioSamurai Meh... no, the sun will not explode, it is far more complex than that.
    – Cilan
    Dec 19, 2014 at 3:53
  • 1
    You say that you'd have to go through 340 ... (the huge number) but that's assuming it's the last key you try which is the good one, doesn't it? I assume the probability that the key is in the first billion is at least somewhat lower
    – Ced
    Jun 1, 2016 at 5:11
  • 1
    The probability that the key is in the first billion is right around 1 in 2^98. Still a huge number.
    – Elkvis
    Jul 5, 2016 at 13:33
  • 4
    Pandas.... I think...?
    – Majenko
    Aug 25, 2017 at 21:05

<disclaimer: not an expert on cryptography>

SSHv2 uses mostly the same algorithms as TLS/SSL:

  • DH, recently ECDH or RSA for key exchange;
  • RSA, DSA or ECDSA for server authentication (and very often, client authentication).
  • AES for symmetric encryption (the entire data stream is encrypted using a randomly-generated key).

All of them are widely used and proven secure for everyday use.

However, in any protocol, security depends on knowing that you are communicating with the right server. In the case of SSH (standard configuration), the first time you connect to the server you have to verify its fingerprint. (Don't just confirm it without actually checking, as many people do.) The next time, the server's key will be checked against a cached copy to prevent man-in-the-middle attacks – but only if the right key was cached in the first place.

(In comparison, TLS/SSL handles the above by using X.509 certificates issued by well-known authorities which are trusted to not sign bogus certificates.)


The real problem of SSH security is certificates. A lot of companies will give out secure keys for SSH connections, and it is not the first time the databases containing these keys get hacked. So the best solution to be secure is to generate your own key-pair, but that is a hassle, and that is whay we rely on these companies... Until they get hacked and we don;t have to check 340,282,366,920,938,463,463,374,607,431,768,211,456 keys but only the onces in the database..

  • 2
    Generating a keypair for SSH is hardly a hassle: you click a button or type a command, and wait a few seconds. I've never heard of anyone using a third-party SSH key-generator service. You should never rely on someone else to generate a private key for you.
    – Wyzard
    Feb 19, 2016 at 23:06
  • Wasn't there a big thing a couple of years ago where some company had used the same keys on ALL their servers, the keys were all available for download on one of the servers, and the initial key used was that of an employee whou hadn't worked for the company for about 10yrs so noone knew his key was used let alone still active. Aug 5, 2017 at 10:02

You must log in to answer this question.

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