Reverse SSH Tunnelling

References

• https://www.howtoforge.com/reverse-ssh-tunneling

So you have access to console access on a protected (NAT-ed) network and can reach the whole Internet. You can use a reverse SSH tunnel to get back to using a full featured and fast terminal window instead of the slow graphical console.

In my case I am doing lab exercises for online Linux training in a course provided lab. The lab has Internet access which is great so you can even backup you lab exercises to GitHub for example. However, working through a graphical desktop for terminal work is not desirable with lag, special keys not mapped and dropped keys.   I could not SSH into the lab environment directly so I used a reverse tunnel.


My public SSH server:

1. only allows access via SSH key. I specifically used "ed25519" key as the public keys are really short, easier to copy out of, especially if you have to type it;
2. operates on a non-standard port.

On the  Network Protected Client

Create a port forward on the loopback interface of the public server.  Every user with access to the public server can now connect back to the SSH daemon on the protected client.  They still have to authenticate but in my case "student" is not a good password, so be careful.

ssh [-i <identity_file>] [-p <public_port>] -R <local_port>:localhost:22 <user>@<public_server>

Common Server Accessible by Both Parties

Identify a public server that both your workstation and the network protected client can access via SSH.  Enable compression on the inner SSH session as it is the one that has access to the raw text and therefore maximum compression.  There is no point enabling compression on the (outer) reverse tunnel as it only sees the inner encrypted SSH session.

ssh [-C] -p <local_port> <protected_user>@localhost