Skip to content

Instantly share code, notes, and snippets.

@meilinger

meilinger/reverse_tunneling.md

Last active December 2, 2016 19:31
Show Gist options
  • Save meilinger/823ba74c6b3443fa8e6ae5e629b84e3b to your computer and use it in GitHub Desktop.
Save meilinger/823ba74c6b3443fa8e6ae5e629b84e3b to your computer and use it in GitHub Desktop.
Download ZIP
Live dev site reviews via SSH reverse tunneling
Raw
reverse_tunneling.md

Hosting live dev site reviews using SSH reverse tunnels

Why

  • Allows for end-users to be able to interact with your dev site directly, using their own browser and their own tools from their own computer
  • Easier for manual cross-browser testing (eg. use IE on Windows VM to test your dev site w/o having to deploy the site to a server)

How

These instructions assume the public server is Ubuntu-based and the dev machine has an SSH client

The eventual setup will look like this from a high level:

        Client
          +
          |
          |
+---------v---------+          +------------------+
|                   |          |                  |
|   Public Server   +---------->    Dev machine   |
|                   |          |                  |
+-------------------+          +------------------+

In order for any of this to work, you need to have a public server available running the SSH daemon (SSHD) you have SSH access to and your end-user will be able to connect to. By default, in a Ubuntu server, SSHD will now allow for reverse tunnels to be bound to the wildcard adapter, which is required in order to expose the tunnel and your dev site to the public. You'll need to add:

GatewayPorts clientspecified

To the /etc/ssh/sshd_config file on the public server and then restart SSHD via service ssh restart.

Now you should be able to expose your local development site to the public. On you dev machine, setup the SSH reverse tunnel using [LOCAL_PORT] as the port that your development webserver is running on and [REMOTE_PORT] as the port the client will be connecting to. Be sure that the [REMOTE_PORT] isn't already being used. High port numbers are recommended to prevent potential conflict and see the IANA port list for more information. You can also do an lsof -i on the public server to see currently-used ports.

ssh -R *:[REMOTE_PORT]:localhost:[LOCAL_PORT] [email protected]

Now your client will be able to access your development site on http://mypublicserver.com:[REMOTE_PORT]

Examples

I have a local Django application running on my dev machine and I want to expose it on http://mypublicserver.com:5001

ssh -R *:5001:localhost:8000 [email protected]

The client then navigates the site at http://mypublicserver.com:5001 using their browser.

I have a Flask application running on a Vagrant VM that running at 192.168.33.15:80 and I want to expose it on http://mypublicserver.com:5005

ssh -R *:5005:192.168.33.15:80 [email protected]

The client can then see your development Flask site at http://mypublicserver.com:5005.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment