Forward :808x requests for SSH workspaces

#1

Hi Team,

I’ve been leaning towards moving my workspaces to SSH to improve their performance, however one show stopper is inability to preview development servers on :808x ports (accessible through a “normal” workspace). There are a few workarounds for that, e.g. setting up SSH+Nginx proxy and use port forwarding with self-signed SSL to forward these to localhost on the client (we have to use SSL to preview them in the same window). But these approaches are not particularly user-friendly (every user has to set up SSH tunnels for every workspace, deal with port conflicts etc.). I also don’t want to just expose my servers to the public through Nginx or another self-hosted web proxy (even if authenticated).

It would be extremely helpful if these ports would be forwarded through c9users.io proxy by default (or as an option) so we wouldn’t have to configure anything on the client and it would “just” work. Would it be technically possible and are there any plans to achieve that on your end?

Thanks a lot

#2

I agree that this would be a very useful feature, and would probably be easily feasible thanks to the fact that all c9users.io requests are already proxied to the workspaces, and you could just add entries to proxy to SSH servers.

#3

Interesting idea. So would you imagine that you’d expose your server’s specified ports to Cloud9’s proxy and then the proxy would expose them to the public from there?

#4

I’m thinking that it could continue running servers on :8080-82 without “public” access, but cloud9 core could automatically tunnel those through the proxy. I’m not sure how it works currently though.

In my layman’s view, it could all be done through regular SSH port forwarding (requiring no modifications to our server setups), the only thing we have to take care about is keeping those tunnels alive. I.e. the proxy that currently makes connection through SSH, would also need to forward these standard ports and automatically re-open their tunnels when they close (e.g. when we restart our localhost:8080).

In my current setup, this could be achieved either by:

  1. running ‘autossh’ on the client, which makes it a little less portable;
  2. or Nginx on the server, and then have SSH bind to the ports (e.g. localhost:9080-82) on which Nginx is listening, which in turn forwards those requests to localhost:8080-82. This setup keeps the connections from closing no matter which SSH client we use (I currently use Secure Shell extension on a Chromebook).

I’m sure with Node, (2) can be achieved without Nginx as well.

Alternatively, the core could also open a reverse tunnel to the proxy (and without opening any new ports on the server). Potentially that would be more straightforward for the current proxy and maybe even made into a plugin (I can sketch a few ideas on the weekend).

#5

Another important aspect is the need to properly forward Host headers, such that the *.c9users.io hostname and port appear to a dev server as if it was running on that external host/port. Granted, in SSH workspaces we can just add an /etc/hosts entry if needed. Some servers (e.g. Webpack lately) have required Host header match and won’t work without it. Moreover, for their own live preview they inject the local hostname and port into the code so our browsers need to be able to resolve these (and all they know about is the external *.c9users.io host/port).

A little off-topic, but this issue is actually relevant even for the current setup on hosted workspaces. Some frameworks (like Angular) currently don’t let us preview the app unless we add an /etc/hosts entry for *.c9users.io, and that is ugly (they actually broke their own functionality and are looking to address that). Modifying /etc/hosts once is fine for an SSH workspace, but hosted workspaces migrate and remove that entry automatically.