I'm currently testing some configurations with vagrant (virtual box) to connect 2 servers (VM currently) together through an SSH tunnel. The goal being to securely connect my web app to the database.

The issue is that when I query the database through an SSH tunnel, my queries are 5 to 80 times slower than if I don't use a tunnel. Here is the command I'm using :

ssh -N -L 3306: sshuser@

From what I read, the overhead should not be that much, so I've tried a few things to speed up the transferts. I find out that if I remove the -N option, the queries are quite as fast as if I don't use a tunnel but I'm being logged in the terminal as 'sshuser' (and adding a & at the end of the command do weird things...).

So knowing that, I have a few questions :

  • Are my data still encrypted when I remove the -N option ?

  • If so, what can I do to keep the performance without being logged as 'sshuser' in the console ?

  • Are they any options I can use to make the encryption faster ?

Thanks in advance for your light.

  • Don't bother encrypting the traffic. If an attacker can see your internal network traffic, you have much more to worry about.
    – Nathan C
    Oct 17, 2014 at 16:10
  • I'm not encrypting my local setup for security, only for testing. Oct 17, 2014 at 16:24

2 Answers 2


SSH tunnel isn't really a great idea as a permanent solution. SSH is TCP based. Most things you can tunnel within SSH is TCP based (including mysql). Tunneling TCP over TCP can have performance implications. Because your system will try to handle the backoff and such on both connections at the same time.

If you want a secure permanent connection between two hosts on the same network you would almost certainly be far better off investigating what it would take to setup IPSEC. Or if IPSEC won't work for you use a VPN setup that doesn't transport over TCP.

As for the performance of your SSH tunnel I would take a look at the ciphers you are using. Some are faster than others. Maybe you can accept a faster/weaker cipher. You almost may want to verify that compression is disabled. If you are on a fast link there really isn't any value to compress, but it may be adding latency for performing the compression/decompression. If you still don't get any improvements after changing those you probably want to fire tcpdump/wireshark and see if you can see where the delays are coming from.

  • Thanks for the suggestion, I guess I will try to avoid SSH for this then... Oct 17, 2014 at 17:37
  • 3
    Normal SSH port tunneling is not TCP over TCP. The article you linked to explicitly mentions PPP over SSH which is a completely different thing.
    – jpc
    Apr 5, 2017 at 20:35
  • 1
    I'm not sure the TCP over TCP issue applies to ssh tunnels, you can read about some tests at serverfault.com/a/653748/321888
    – jmng
    Sep 27, 2018 at 0:01
  • Citing TCP over TCP article is not a really correct because the article says it in the context of PPP. In SSH tunneling there is no TCP congestion, packet numbering, retries and so on. Because all problems of the stream are already solved by TCP layer used by SSH itself. So when tunneling is used TCP connection is terminated by SSH, byte stream transferred using SSH and then relayed to another TCP. So the performance penalty is caused by 3 TCP connections instead of 1 and by encryption.
    – Tomáš
    Jan 19, 2020 at 2:28

The -N option just prevent SSH to execute a remote command, not the encryption. You tunnel will still be encrypted anyway.

If you use -N, ssh just creates the tunnel, not the shell and all environment variables on the other side. It's way faster.

I don't think that adding a SSH tunnel to your setup will increase your security, it may even drastically decrease it.

If you connect your web application direct to the database, any potential attacker will only have the credentials that your application uses. If you create a tunnel, the attacker can potentially exploit the tunnel to gain access to the database host, and compromise all data on that server.

In your setup, you have to manually start the tunnel, and will end up probably automating it, and store the credentials somehow. An attacker can find the credentials and use it to gain access to the database server.

If you database server and application server are on the same subnet, the security gain on using encrypted SSH tunnels to access the data is negligible. It would only protect you from an attacker that is already inside the network. In this case, is just a matter of time before he has access to everything.

  • 4
    Sorry, but are you saying that SSH encryption is useless ??? I can't really see how an attacker could exploit an SSH tunnel (except by brute force search which is more than unlikely). Anyway, how do you explain that removing the -N option prevent my performance loss. Oct 17, 2014 at 16:37
  • Sorry, this answer doesn't make much sense. The question is about secure connection between app server and DB. There are lots of cases where an app server may need to connect to a DB outside its own subnet. If you are saying SSH tunnels can be easily exploited than non-tunneled connections please also cite some reference.
    – rineez
    Apr 19, 2018 at 10:05
  • As I said, you will end up probably automating it, and store the credentials: You create a script to start the tunnel, and store the credentials. Later an attacker exploits the web app and gain a shell, finds the script and SSH credentials (or steals the SSH private keys). We know what happens next.
    – ThoriumBR
    Apr 19, 2018 at 12:17

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.