Once again, no extra imagination for the title. Ok, last time, I present you different ways to overcome firewalling with SSH-tunneling. Most of it boils down to the fact the sysadmin does not put enough attention to outgoing traffic. Well, if he would, there is still something possible: Using the allowed HTTPS port for the SSH connections.

The fact is, most of time, firewalls does not inspect packets content. They only allow or block traffic at the TCP/IP layer, and make decisions regarding the couples IP source <–> IP destination and port source <–> port destination. Well, the sysadmin may have blocked every outgoing ports except a few essential ones (HTTP, HTTPS, DNS, …) we can still connect to our server by SSH using a port traditionnaly used for another server. Just change SSH Port directive for something like 80, 443, …

Nevertheless there are still two problems. First of all, it makes impossible to provide a server which should use the port you have chosen. For instance, using 80 for SSH makes it impossible to host Web servers as there is no way you can tell your visitors to use another port instead of this one. And if you keep using port 80 (OK, you may not have Web server listening for visitors), any inspection on your traffic will show encrypted traffic… quite unusual for HTTP connection. Furthermore, what would happen if your organization uses proxies to filter HTTP content? We are presuming anyway that HTTPS proxy are more tricky to set up, and (usually…) employees should be aware of this interception.

SSHL is a simple tool analyzing the protocol used (Analyse on first characters of data) and deciding to forward traffic according to your needs. sslh. For instance, if you choose to makes SSH listen on port 443, traffic looking like HTTPS connection will be resend to apache (which listens on localhost:443) and SSH to sshd (which listens on localhost:22).