Remove open ports requirements by forwarding them via SSH

[mtorromeo]

An SSH connection is already required for nuclide-server to work so it might be a good idea to just forward the necessary ports through it instead of having to open them on firewalls.

If the local client port is dynamically assigned in the local_port_range it won't cause any conflicts over multiple remote connections.

This would also allow for a simpler approach to encryption as it wouldn't require to setup dedicated certificates on the server.

Thanks!

[ssorallen]

Related to #86.

[appsforartists]

:+1:

This would simplify remote connections (as you wouldn't need to manually forward additional ports if you have an especially hardened SSH configuration). It would also add peace of mind.

I just manually logged nuclide-remote-connection to see if my connection was secure or not. Thankfully, it is. However at a glance, it appears that the connection silently falls back to unsecure if it can't find a certificate. I haven't looked closely enough to see under what conditions that occurs, but that it's even an option is a bit scary.

I'm not a security engineer, so I don't feel confident auditing nuclide-remote as it is. I'm presuming that the https web socket + the Mac firewall provides a reasonable amount of protection against intrusion. (After all, it's a core part of FB's infrastructure.) Then again, I know that ssh has been a trusted standard in security for a very long time, and that a lot of people have invested a lot of effort making and keeping it secure. I'd be much more comfortable using and recommending Nuclide if all its traffic traveled over its SSH connection.

[mreschke]

I didn't want to open port 9090 either. Found if I use localhost in nuclide server connection instead of actual remote IP, then SSH port forward 9090 it works perfectly.

So lets say my remote server is at server.example.com and it ONLY has port 22 open.

On that remote server, I have a nodejs app running on port 3000.

On my macbook run

ssh -p 22 server.example.com -L 20022:localhost:22 -L 3000:localhost:3000 -L 9090:localhost:9090

Now in nuclide, open new remote connection dialog

server: localhost
port: 20022

So SSHing to localhost:20022 actually SSHs into server.example.com:22 and localhost:9090 is forwarded over to the server along with 3000. Now watchman works perfectly on 9090 and I can access my nodejs app on my macbook at http://localhost:3000

[nlevitt]

I'd like to add a note to @mreschke's helpful comment. His setup seems to assume port 9090 is blocked (by iptables or a firewall or something). That isn't the case for me, and I don't have admin access to the host. But I was able to make the server listen only on localhost by making this change:

--- node_modules/nuclide/pkg/nuclide-server/lib/NuclideServer.js.orig   2016-07-21 18:19:19.946296168 +0000
+++ node_modules/nuclide/pkg/nuclide-server/lib/NuclideServer.js        2016-07-21 17:37:36.446600879 +0000
@@ -212,7 +212,7 @@
           _this4._webServer.removeAllListeners();
           reject(e);
         });
-        _this4._webServer.listen(_this4._port);
+        _this4._webServer.listen(_this4._port, 'localhost');
       });
     }

Another note other folks without admin access to the ssh server. I installed node, watchman, and nuclide-server in my home directory, and I had to add this line to the beginning of nuclide-start-server to make it work (adjust for your installation):

export PATH=/home/nlevitt/nodejs/bin:/home/nlevitt/watchman/bin:/usr/bin:/bin

It would be nice if nuclide made these things stuff easier. :)

[zoidyzoidzoid]

Would it be possible to get more info about how the authentication works? I read the big-dig README, but I've fiddled for the last day or two with trying to get useful debug info out for how to get it to work with forwarding ports, without much success unfortunately. I got it successfully starting the server using ssh-agent and forwarding a local port to 22 on the remote machine, then connecting to 127.0.0.1:8022 as suggested by #332.

I went down this rabbit hole because of issues, which I think are related to #282 and #694.

Will the bootstrapping of the server and client connection work the same way for the VS Code server? I'd happily settle for a manual bootstrap, that required setting some long timeouts, and manually scp'ing the jsonOutputFile to the local machine and configuring certs.

I'd be keen to provide any other info that could be useful, since I'd love to find a solution for this.