search

strongloop / strong-tunnel

Disposable ssh proxy for TCP connections via URL
Other
6 stars 5 forks source link

Add native ssh support #6

Closed daankets closed 3 years ago

daankets commented 8 years ago

The ssh2 library used for ssh connectivity does not use the user's ssh config, and therefore does not support ProxyCommand and other configuration. It would be really nice if there was an option to use native ssh instead of the js version. Currently we can not deploy via an ssh gateway using strong-deploy. We have to setup our tunnel manually first.

rmg commented 8 years ago

This is interesting, as the use of the ssh2 module is specifically because it does not require a native ssh like most ssh modules do. This was done because there are many environments where development is done on Windows and deployment is done to Linux.

daankets commented 8 years ago

That's true as well, I used to be one of these developers many years ago. However I used native ssh even then. Many enterprise environments nowadays use ssh gateways in order to be able to control who gets access and when - as well as not exposing concrete production server passwords and keys. For this reason we provide a managed ssh configuration that allows users to connect using the DNS name of the final host even when going through a gateway. This is however not possible with the ssh2 library today.

rmg commented 8 years ago

@daankets do you have the option of setting up the proxy yourself?

All strong-tunnel is doing is creating a local server that proxies requests over an ssh tunnel that it opens.

In other words, it's just turning this:

$ slc ctl -C http+ssh://remote.host.com:8701/ status
  ... status from remote

Into this (without actually running ssh, of course):

$ ssh -L 8701:remote.host.com:8701 ci.strongloop.com -N &
$ slc ctl status
  ... status from remote
$ slc deploy
   ... deploys to localhost, which is proxied to remote.host.com
daankets commented 8 years ago

@rmg Sure, this is how we deploy currently. But it requires a script, and we need it for every possible command (unless when running in dev, which are local docker containers). It's way more convenient when we can just use the same rules as already defined within ~/.ssh/config...

At this time, I have created a script which manages this more or less, but it won't work with all tools, and it's more susceptible to mistakes. Also, it's hard to run simultaneous commands (as they will open tunnels to the same port).