Is it possible to have a shared port for ssh tunneling that segregates sessions based on client? For example, if I have client1 using a tunnel to port 9999 on a shared server for an ssh tunnel to another server like below:

Client1 port 8888 —> shared host port 9999 —> server1 port 4477

Is there a way that port 9999 on the shared server can also be used by another client to tunnel into a different end host like below?

Client2 port 8888—> shared host port 9999 —> server2 port 5568

The key point is that the client local port forward to the shared host port would always be the same ports. From the shared host the tunnel can be extended to the desired endpoint but the tunnel would still be passing over the same port on the shared host.

I’ve tried a number of things but either ended up with the client2 session rejected over that port or traffic from client1 being fed to client2.

I realize this is not an ideal setup but unfortunately, it’s what I have to work with.

--Edit-- Adding example:

There are 2 web servers that are only reachable through a shared host. In this example, they will just reply with either 'server1 response' or 'server2 response'. Authentication is handled by rsa keys and user1 and user2 are using completely separate hardware.

user1 connects first:

user1@localbox1$ ssh -t -L 8888:localhost:9999 user1@sharedhost.com "ssh -L 9999:localhost:80 user1@"
user1@ $ 

The tunnel works as expected:

user1@localbox1$ curl "http://localhost:8888"
server1 repsonse

When user2 attempts to connect, they are given an error message and the tunnel from user one is used:

user2@localbox2$ ssh -t -L 8888:localhost:9999 user2@sharedhost.com "ssh -L 9999:localhost:80 user2@"
bind: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 9999
Could not request local forwarding.
user2@ $ 

User1's session is then forwarded to user2's tunnel.

user2@localbox2$ curl "http://localhost:8888"
server1 response

If the tunnel had been created the response would have been server2 response instead of server1 response.

It's important to note that the remote command for the second tunnel is an unfortunate necessity, as the end host address may change and the values cannot be determined from the user end. For simplicity in this example, I've just used some actual end host addresses.

  • 1
    You should add what you have tried to the question. – Kusalananda Nov 12 '18 at 6:45

Yes, it is possible, assuming client1 and client2 are different computers, not different users on the same computer.

Is there a reason why you think it wouldn't work? Have you tried it and something doesn't work?


In your example, client1 and client2 are on the same computer, localbox, so of course this doesn't work.

The easiest solution is to use two different ports. Is there any particular reason not to use different ports?

Another solution is to use different source addresses:

ssh -t -L user1@sharedhost.com

ssh -t -L user2@sharedhost.com

You can now connect to and for your targets.

You can use namespaces, containers, virtual machines, but that would be more complicated and depends on your needs.

  • I realize that the word traffic is probably not the correct phrasing. I've replaced it with what I think makes more sense but the actual verbiage may still not be correct. I've added the command examples to the post. I hope that explains it better. – Kriggs Nov 13 '18 at 6:08
  • The localbox hostname is just a dummy tag for the PS1 prompt, not the actual hostname. The clients are completely separate computers with separate hardware and distros. – Kriggs Nov 13 '18 at 8:40
  • I’ve edited the PS1 prompts to clarify the hostname. As far as using different ports, the problem is that it would have to rely on the client side changing the port as a reactionary measure. Another reason for the shared port is that if hundreds of users are using the shared host for the tunnels, this would be very time consuming to find an open port, and if the user is connecting through putty on a windows box, it would be even rougher. – Kriggs Nov 13 '18 at 8:56
  • If you use different hosts, there should be no problem. – RalfFriedl Nov 13 '18 at 17:53
  • Have you tested this? It doesn’t work, which is why I posted the question. Port 9999 in the example is the port on the shared host, hence the error message for port 9999 and not 8888, which is the local port of the client devices. – Kriggs Nov 13 '18 at 21:46

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.