Reverse shell access

Problem

In my case this was a weird situation. I had a server I had to administer remotely [server C in the image] set up with some paranoid network security settings (no open remote SSH access). The only way to get to the sshd services was to use a special dedicated proxy [server B in the image] whose static IP address was excluded from the firewall list on the destination server (thus establishing a theoretically more secure SSH tunnel on some not so common port).

The main problem was the latency resulting from such a construction. My route to the destination server [C] was only a few hops away and direct communication (ICMP) was always less than 20 ms. But the route via B was horrible, very unstable (some high-traffic node so latency spikes occurred every now and then). Normal SSH session got some 100-200 ms delay which meant usable, though not too comfy. But the spikes (2-3 seconds) utterly blighted any more complicated tasks being done on the server.

Solution

As I had a dynamic IP there was no easy way to grant me direct access to the machine in question. But I found a very interesting program, which enabled me to bypass the constraints established by the paranoid firewall setup.

Reverse Remote Shell by Michel Blomgren (Cycom AB) supports inverse SSH-like (OpenSSL) connections established between remote host [C] and the listener [my workstation - A]. As remote outgoing connections are fully accepted by the firewall on machine [C], I only had to set up a listener on my computer, connect through the old method (via tunnel) to the remote server and issue a reverse connection request to my current dynamic IP. When the connection got accepted, my listener transformed into a full-blown remote shell client and I could disconnect the tunnelled session enjoying near local latency of a direct connection.

Reverse Remote Shell is distributed under the MIT License and runs smoothly under Linux and BSD-family systems.

To make it as seamless as possible, I made a quick connection script for Linux.

First make a main connection script (something like ~/start.sh):

#!/bin/sh
# Establish a new screen session
killall screen
screen -dmS remoteShell
sleep 1
# Connect to the server via tunnel, when the session is completed - exit screen
screen -S remoteShell -p 0 -X stuff "~/connect.sh &amp;&amp; exit^M"
sleep 1
# This gets executed on the remote server - request a connection to the listener
screen -S remoteShell -p 0 -X stuff "~/remote.sh &amp;&amp; exit^M"
# Turn on listening on local side
~/listen.sh

You will also need a tunnel connection script (connect.sh). This can be something so trivial as:

#!/bin/sh
/usr/bin/ssh -p 22 -i ~/.ssh/myIdentityFile user@example.com

The remote part (remote.sh) is something like this:

#!/bin/sh
/bin/sleep 1
# Check your rrs location here, 12345 is a port of the listener
# and dynamic.example.com is a dynamic hostname for the listener (client)
~/rrs --daemon --ssl --pem ~/rrs.pem --timeout 15 dynamic.example.com 12345

And the last part – listener (listen.sh):

#!/bin/sh
~/rrs --listen --ssl --pem ~/rrs.pem --port 12345

This way a lot of paranoid firewall setups can be penetrated. Be aware, however, that this would probably need some reworking for corporate scenarios (even more strict as they are) and could potentially lead to some serious security level degradation. Notwithstanding, Reverse Remote Shell can be a really useful tool in such situations, so big thanks goes to Michel Blomgren for that kind of unique application.