"ssh -R 0:example.org:port" will forward a dynamically allocated port on the server to example.org:port from the client. The dynamically allocated port gets printed; however, as far as I can tell there's no way to access it programmatically from the server. I'd like to have it exposed via an environment variable on the server (for instance, SSH_FORWARDED_PORTS), which would allow programs run on the server to know and use the dynamic port. If the client set up multiple dynamic port forwards, the environment variable would contain a space-separated list of port numbers, in the same order as the requests on the ssh command line.
Created attachment 2531 [details] Expose remote port forwarding info for the executed command The patch is for version 6.7p1.
(In reply to Sami Hartikainen from comment #1) > Expose remote port forwarding info for the executed command > > The patch is for version 6.7p1. ...please also note that the patch should be considered as an example only; for example, gateway_ports value 3 does not exist in vanilla Portable OpenSSH.
The reason we haven't done this is that it is when clients start forwardings after establishing the shell/login session - these will not get into the environment.
(In reply to Damien Miller from comment #3) > The reason we haven't done this is that it is when clients start > forwardings after establishing the shell/login session - these will > not get into the environment. Quite right, a real application requires an additional method for conveying runtime changes. I've done that, but the implementation is very much application-specific.
(In reply to Sami Hartikainen from comment #4) > (In reply to Damien Miller from comment #3) > > The reason we haven't done this is that it is when clients start > > forwardings after establishing the shell/login session - these will > > not get into the environment. > > Quite right, a real application requires an additional method for > conveying runtime changes. I've done that, but the implementation is > very much application-specific. Fair point, but let's not let the perfect be the enemy of the good here. Quite a few things don't quite work right with runtime changes or with persistent shared SSH connections, but at least conveying the *initial* data via an environment variable would help. For runtime changes, I'd suggest an environment variable containing a socket that receives notification of changes in a well-defined format. However, that would take quite a lot more work to implement, and the simple environment variable still seems preferable for simple cases.
Had a look at the code trying to figure out if this was something i could patch myself, but I couldn't find an easy way to get hold of the local host and port for the RemoteForward. Anyway, I would really like some way to get hold of the port-number in a more programmatic way, and in most cases the initial ones set up from the command line is fine, but just having a list of the ports in the same order as the command line parameters is not enough, as this order could be changed by aliases, added to by the config by RemoteForward, and posibly other mans. I, at least, would need to know which port mapped to which host:port on the other side of the tunnel, so an environment variable with all the -R (and RemoteForward) parameters in a list with the 0-ports replaced would be a nice solution. Some way to query the running ssh of all forwards would also be nice, but I guess that is a bit harder to implement than the initial forwards in a list. Another possibility for the initial connections would be to expand the syntax for -R to include a name (in place of the 0-port or some other mean), and then store the allocated port (or the whole R-argument) in an environment variable with that name. Looking forward to seeing the 0-port feature beeing more useful for programmatic use :)