openssh bugs - Jan 2015 - [Bug 2336] New: Expose dynamic port for -R 0:... via environment

https://bugzilla.mindrot.org/show_bug.cgi?id=2336

            Bug ID: 2336
           Summary: Expose dynamic port for -R 0:... via environment
           Product: Portable OpenSSH
           Version: 6.7p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: josh at joshtriplett.org

"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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2336

Sami Hartikainen <hasa100 at hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hasa100 at hotmail.com

--- Comment #1 from Sami Hartikainen <hasa100 at hotmail.com> ---
Created attachment 2531
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2531&action=edit
Expose remote port forwarding info for the executed command

The patch is for version 6.7p1.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2336

--- Comment #2 from Sami Hartikainen <hasa100 at hotmail.com> ---
(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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2336

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2336

--- Comment #4 from Sami Hartikainen <hasa100 at hotmail.com> ---
(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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2336

--- Comment #5 from Josh Triplett <josh at joshtriplett.org> ---
(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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2336

Peder Stray <peder.stray at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peder.stray at gmail.com

--- Comment #6 from Peder Stray <peder.stray at gmail.com> ---
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 :)

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.