Secure SHell is usually seen as a secure alternative to old telnet and other unencrypted sysadmin tools. But when it comes to break rules set by over-annoying sysadmins, it appears to be quite useful too. It basically establishes an encrypted connection between two hosts, but once this connection made, it gets easy to include any kind of TCP packets on it, and why not? IP packets as well.

Usecase One: I am using web services which may not be secure

I just want to set online a proof of concept about a Web service. But this service is not secure and does require extra protection. Maybe I don’t want to bother with apache authentication or whatever, just install the service, and set it online. If I have a firewall between this service and the Internet (the service is then in a DMZ), here is what is possible to do:

1
2
3
4
5

ssh -L $localport:$target_host:$hostport myself@myserver
ssh -L 8000:$web_service:80 user@firewall
# Here is what I would do if instead of web services, I want to access my mail server:
ssh -N -L 2025:smtp_server:25 -L 2143:imap_server:143 my_gateway
# All I have to do then is configuring my mail client to use localhost:25 for outgoing mails and localhost:149 for reception (IMAP)

All I have to do is launching this command on my laptop, and get my browser to https://localhost:8000. I chose a port number higher than 1024, to avoid launching my browser as root. I am the only one then to connect to this service, whithout having to think to extra web based protection.

An other use case is when the web server is behing a cache server. I don’t want to reset cache. Just to have a look as if there would not be any cache. This way lets us connecting to the web server directly.

Yet an other use case is when I have services known to be unsecure and still necessary. For instance, web servers on PDU powering servers. Sometimes, these devices can only be managed to the web interface, and connecting to them directly (with a HTTP session) would let BoB listens the login and password. Of course, this would securize traffic between client and firewall, and not between firewall and service. Too bad, failed attempt to securize HTTP or Telnet still in use to manage network equipements.

Usecase Two: Daddy needs this access, but not from work

Ok, things are going good when I am at work, having management access to the servers I’m working on, but its sometimes comfortable to work from home. Or from wherever I want to. But things are, the Sysadmins don’t let me in. Whatever; If he(she?) forgets to block outcoming access, here is what I can do. At work, I draw a connection from the target server to my private server, opening a incoming connection to the inside. Once at home, I connect as usually to this private server, and get back to the office station through this preview connection.

1
2
3

$worker@$admin_station: ssh -TR $come_back_port:localhost:22 $outside_server
# Once at home; I can connect to my private server $outside_server
$daddy@$outside_server: ssh -p $come_back_port localhost

An other use case is when I put some servers to a strongly securized DMZ (highly important, or vulnerable). And I don’t want to give these servers any access but SSH for administrative tasks. Well, I still need updates on these servers.

1

$admin@admin_station: ssh -R 1080:my_update_server:80 $isolated_server

On this isolated server, I set localhost:1080 on /etc/apt/sources.list file. This is the same spirit as earlier. The SSH command, instead of forwarding port from the isolated_server to localhost, continues until the update server, through localhost (my admin PC).

Usecase Three: Bypass firewall to access blacklisted web sites

Once again, the sysadmin is a BOFH, but he didn’t think outcoming access are as dangerous as incomming ones. So, let’s access Facebook from office.

From my office station:

1

ssh -D $chosen_port my@my_server

I then need a SOCKS proxy to let my web-browser use this tunnel. On Firefox,

1

Edit -> Preferences -> Advanced -> Network -> Settings

Configure proxy manually (host: localhost, and port: $chosen_port), of course, no proxy for localhost. Then, surf the Internet as you would to from your server.

What about security?

Well, this is a question one should ask to himself before doing anything stupid. Of course, to protect access to unsecure services, SSH tunneling can help. But you should think twice when it comes to break rules, especially those established to protect inside network from outside.