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 email@example.com "ssh -L 9999:localhost:80 firstname.lastname@example.org" email@example.com $
The tunnel works as expected:
user1@localbox1$ curl "http://localhost:8888" server1 repsonse user1@localbox1$
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 firstname.lastname@example.org "ssh -L 9999:localhost:80 email@example.com" bind: Address already in use channel_setup_fwd_listener_tcpip: cannot listen to port: 9999 Could not request local forwarding. firstname.lastname@example.org $
User1's session is then forwarded to user2's tunnel.
user2@localbox2$ curl "http://localhost:8888" server1 response user2@localbox2$
If the tunnel had been created the response would have been
server2 response instead of
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.