{"id":526,"date":"2016-06-10T17:56:03","date_gmt":"2016-06-10T17:56:03","guid":{"rendered":"https:\/\/blog.afach.de\/?p=526"},"modified":"2016-08-22T13:53:10","modified_gmt":"2016-08-22T13:53:10","slug":"tunnel-through-https-to-your-ssh-server-the-perfect-tunnel-haproxy-tunnel","status":"publish","type":"post","link":"https:\/\/blog.afach.de\/?p=526","title":{"rendered":"Tunnel through https to your ssh server, and bypass all firewalls – The perfect tunnel! (HAProxy + socat)"},"content":{"rendered":"

Disclaimer<\/span><\/h3>\n

Perhaps there’s no way to emphasize this more, but I don’t encourage violation of corporate policy. I do this stuff for fun, as I love programming and I love automating my life and gaining more convenience and control with technology.\u00a0I’m not responsible for\u00a0any problem you might get with your boss in your job for using this against your company’s firewall, or any similar problem for that matter.<\/span><\/p>\n

Introduction<\/h2>\n

I was in a hotel in Hannover, when I tried to access my server’s ssh. My ssh client, Putty, gave this disappointing message<\/p>\n

\"PuttyConnectionRefused\"<\/a><\/p>\n

At first I got scared as I thought my server is down, but then\u00a0I visited the websites of that server, and\u00a0they were fine. After some investigation, I found that my hotel blocks any access to many ports, including port 22, i.e., ssh.\u00a0Did this mean that I won’t have access to my server during my trip? Not really!<\/p>\n

I assume you’re using a\u00a0Windows client, but in case you’re using linux, the changes you have to do are minimal, and I provide side-by-side how to do the same on a\u00a0linux client. Let me know if you have a problem with any of this.<\/p>\n

Tunneling mechanism, and problems with other methods that are already available<\/h2>\n

There are software that does something similar\u00a0for you automatically, like sslh<\/a>, but\u00a0there’s a problem there.<\/p>\n

What does sslh do?<\/h6>\n

When you install sslh on your server, you choose, for example, port 443 for it. Port 443 is normally for http-ssl (https), that’s normally taken by your webserver. So you change also your webserver’s port to some arbitrary\u00a0port, say 22443. Then, say you want to connect to that server: sslh analyzes and detects\u00a0whether the incoming network packets are ssh or http. If the packets are ssh, it forwards them to port 22. If the packets\u00a0looks like https, it forwards them to the\u00a0dummy port you chose, which is 22443 as we assumed.<\/p>\n

What’s the problem with sslh, and similar programs?<\/h6>\n

It all depends on how sophisticated the firewall you’re fighting is. Some firewalls are mediocre, and they just blindly open port 443, and you can do\u00a0your sslh trick there and everything\u00a0will work fine. But smart\u00a0firewalls are not that dull; they analyze your packets and then judge whether you’re allowed to be connected. Hence, a smart firewall will detect that you’re\u00a0trying to tunnel ssh, and will stop you!<\/p>\n

How do we solve this problem?<\/h6>\n

The solution is: Masquerade the ssh packets inside an https connection, hence, the firewall will have to do a man-in-the-middle attack<\/a> in order to know what you’re trying to do. This will never happen! Hence, I call this solution: “The perfect solution<\/span><\/strong>“.<\/p>\n

How to create the tunnel?<\/h2>\n

I use HAProxy<\/a> for this purpose. You need that on your server. It’s available in standard linux systems. In Debian and Ubuntu, you can install it using<\/p>\n

sudo apt-get install haproxy<\/pre>\n
You will need “socat” on your client to connect to this tunnel. This comes later after setting up HAProxy.<\/p>\n
How does HAProxy work?<\/h6>\n
I don’t have a PhD in HAProxy, it’s fairly a complicated program that can be used for many purposes, including load balancing and simple internal proxying between different ports, and\u00a0I use it only for this purpose. Let me give a brief explanation on how it works. HAProxy uses the model\u00a0of frontends and backends. A frontend is what\u00a0a client sees. You set a port there, and a communication mode (tcp, for example). You tell also a frontend “where these packets should go”, based on some conditions (called ACL, Access Control Lists). You choose to which\u00a0backend<\/em> the packets have to go. The backend contains information about the target local port. So in short words, you tell HAProxy where to forward these packets from the frontend to the backend based on some conditions.<\/p>\n
A little\u00a0complication if you use https websites on the same server<\/h6>\n
If you use https webserver on the same machine, you’ll have a problem. The problem is that you’ll need to check whether the packets are ssh before decrypting them<\/strong>, because once you decrypt them, you can’t\u00a0use them as non-encrypted again (hence haproxy doesn’t support forking encrypted and decrypted\u00a0packets side-by-side). This is because you choose to decrypt in your frontend. That’s why we\u00a0use SNI (Server Name Indication)<\/a>\u00a0and do a trick:<\/p>\n