SSH identify key used to create a remote random port

I need to access some servers inside NAT. Since I do have a public server, this is what I am doing:

Both A and B have a service that runs the command: ssh -fnN -R 17000:localhost:22 [email protected] -i privateA

Only difference is the port. For B it is 17001.

This creates a sleeping connection from servers inside NAT to my public server 24/7.

Now I can connect any time to S and use the command: ssh -i privateS -p 17000 user@localhost to connect to A.

Great. It solves my immediate problem. But while checking for ways to do it I had other option and I was not able to find a way to actually use it.

Main drawback of this method is to be sure to know every server remote port in advance and configure each server to use it since port selection came from command in A and B not in S.

If we use -R 0:localhost:22 on first commands (in both A and B), it all works the same, but the remote port will be random. And the SSH command even echoes back the number of the port created in S. But this information is available in A and B only.

From S I simple see two open ports in listen mode but do not know the one to use to reach A or B.

Imagine instead of 2 I have 50 remote servers.

How can I identify every SSH connection?

My first attempt was to use commands inside my authorized_keys file and do identification by the private file in use. Here I could retrieve the SSH process and then a list of ports under that process.

But, since I am using -N commands aren't executed at all. What other method I could try?

What is the usage of a command that creates random port on a remote machine and do not share this information to it? What is the intended usage of -R 0:host:22?

Again, my problem is solved, just trying to learn here...

From the point of view of the server, there is no difference between when you use -R 17000:… or -R 0:… on a client. Some port gets allocated. The server machine does not care if it's picked by a human user of the client machine or by some algorithm.

Let's suppose it's picked by a human user of the client machine and the user is you. Then it's your responsibility to pass the number you chose (e.g. 17000) to future users of the tunnel.

If you decide to use -R 0:… then informing future users of the tunnel is still your responsibility, nothing changes in this matter. And you get to know the number at runtime ("the SSH command even echoes back the number of the port created in S").

Note in general future users of the tunnel may or may not be users of S. With -R you can specify a remote (i.e. local to S) bind address, it may be an external address; and if the server is configured to allow this (see this answer of mine) then it will be possible to use the tunnel by connecting from the outside of S, without logging in to S.

Therefore in general storing (or learning) on S what port is tunneled to where would not solve the problem. You see this as a good idea because you can log in to S.

Either you (who runs ssh on clients) use static numbers and then you can inform future users of the tunnels (including yourself) in advance; or you use -R 0:… and take responsibility of informing the future users of the tunnels (including yourself) not in advance.

I understand each ssh -R 0:… is automated in your case. So you should also automate a procedure of informing future users of the tunnel. This is how you can do it to inform a user (possibly yourself) on S:

#!/bin/sh

# client-side, say A
ssh -fNMS /path/to/socket [email protected]
port="$(ssh -S /path/to/socket -O forward -R 0:localhost:22 placeholder)"
echo "$port" | ssh -S /path/to/socket placeholder 'cat >A.port'  # or B.port etc.

It's a quick and dirty script, it is based on this another answer of mine where you can find some details explained.