SSH tunnel (port forwarding) slow down a lot the thesql queries

linux-networkingport-forwardingsshtunnelvagrant

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:127.0.0.1:3306 sshuser@192.168.10.10

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.

Best Answer

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.

Related Topic