SSH tunnel (port forwarding) slow down a lot my mysql queries

Question

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 [email protected]

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.

Solution 1

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.

Solution 2

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.

Comments

[Nathan C]

Don't bother encrypting the traffic. If an attacker can see your internal network traffic, you have much more to worry about.

[Nicolas BADIA]

I'm not encrypting my local setup for security, only for testing.

[Nicolas BADIA]

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.

[Nicolas BADIA]

Thanks for the suggestion, I guess I will try to avoid SSH for this then...

[jpc]

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.

[rineez]

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.

[ThoriumBR]

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.

[jmng]

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

[Tomáš]

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.