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.

  • How are Docker containers published? With or without hostPort:containerPort mapping? – Praveen Premaratne 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 2 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. – Praveen Premaratne Jan 3 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 3 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. – Praveen Premaratne Jan 3 at 20:06
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.

  • 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 1 at 0: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 2 at 16:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.