0

I have services running (in docker containers) on a remote server for which I have ssh access.

These services are admin apis that I'd prefer not to expose to the world(I don't really fancy setting up authentication for each of those services, and having more passwords to manage, when only a few admins who already have ssh access might need to use them). Still, I'd like to be able to interact with those services from my workstation(using the tools installed on my workstation). I'd like to reuse my existing ssh authentication.

Ideally, what I'd want is to create a secure tunnel connection to the remote server once, and use it to access those apis which are only listening to requests coming from the local network(i.e. as if from localhost), so that only those able to ssh to the server can access those apis.

I don't think it's possible to proxy traffic "through" the remote loopback interface, but is there a way to have those services only listen to connections proxied through the server, without needing to have configuration specific to each service(like a firewall rule for each port)?

I've been playing around and trying to understand different methods of ssh tunneling, e.g. ssh -D ..., ssh -L ..., ssh -R ..., ... but they don't allow me to access services listening to the remote "localhost", so I'd have to have firewall rules anyway.

Thanks.

Charles Langlois
  • 111
  • 5
  • How are Docker containers published? With or without `hostPort:containerPort` mapping? – Prav Dec 31 '18 at 23:22
  • With port mapping and explicit IP, i.e. `127.0.0.1:1234:1234`. My goal is to avoid exposing the services to the outside, hence binding to localhost. I'm wondering if there's a way to connect to the server and act as localhost, but from another remote machine. – Charles Langlois Jan 02 '19 at 16:15
  • Not with that binding, because `127.0.0.1` is in theory a NIC of its own and the local IP is (`192.x.x.x`) is a NIC of its own or global (`0.0.0.0`) is allowed to all NICs. At the moment you're only allowing traffic coming from `loopback` NIC and that's why not even the tunnel works. If you give the standard NIC (`192.x.x.x`) it'll allow all devices within that network to access since you're bound to that NIC. When you put `1234:1234` you're saying `0.0.0.0:1234:1234` that's why anything and everything can access that. – Prav Jan 03 '19 at 15:25
  • Yeah, I get the difference between binding to `0.0.0.0` and `127.0.0.1`. When I use a socks proxy(`ssh -D localhost:localport me@remote`), I can see the client IP is `192.168.0.1`. So if I bind to `192.168.0.1`, does it allow connections from any machines in the local network? – Charles Langlois Jan 03 '19 at 19:59
  • In theory it should allow you access it. But it needs to be the IP of the machine not the network. So `192.168.0.1` probably won't work since this is the router/switch IP. Keep in mind this will allow anyone on that network can also access the container by `machine-ip:port`. Use firewall rules to block traffic in/out of the machine on that port. – Prav Jan 03 '19 at 20:06
  • That's what I was thinking. I'll stick with port forwarding then I guess. Thanks! – Charles Langlois Jan 03 '19 at 20:17

1 Answers1

1

I think what you are trying to accomplish it's called SSH Tunneling. Basically you can configure a local port in you workstation to be forwarded to a remote server as follows:

Local server: node1(10.0.0.1) (i.e., with port 5000 available).
Remote server: node2(10.0.0.10) running an web app on port 8080.

On node1:

ssh root@node2 -L 5000: node2:8080

Testing from node1:

http://localhost:5000 or http://10.0.0.1:5000

You can find more info here.

I hope this helps.

Manuel Florian
  • 261
  • 1
  • 5
  • Thanks, yes I've investigated this as a solution. However, 1. it requires setting up one "tunnel" per service, and configuring my tools to use those tunnels. It might be doable, but it's not ideal; 2. if the remote service endpoint only listens to the local(loopback) interface, I don't think it will work. So I still have to set the endpoints to bind to any address, which makes the tunneling useless unless I also configure firewall rules on the remote machine, which kinds of defeat the whole purpose. – Charles Langlois Dec 31 '18 at 21:36
  • 1
    Regarding point one you are right. But point two it definitely works. How many API's do you have? Because if you need just two tunnels it could be a good workaround in the meantime. – Manuel Florian Jan 01 '19 at 00:28
  • It seems you're right, it does work. I could definitely use this, but isn't there a way to make `ssh -D ...` work too? – Charles Langlois Jan 02 '19 at 16:10