bugzilla-daemon at mindrot.org
2015-Jan-09 19:45 UTC
[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.
bugzilla-daemon at mindrot.org
2015-Jan-26 10:45 UTC
[Bug 2336] Expose dynamic port for -R 0:... via environment
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.
bugzilla-daemon at mindrot.org
2015-Jan-26 10:54 UTC
[Bug 2336] Expose dynamic port for -R 0:... via environment
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.
bugzilla-daemon at mindrot.org
2015-Apr-22 01:47 UTC
[Bug 2336] Expose dynamic port for -R 0:... via environment
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.
bugzilla-daemon at mindrot.org
2015-May-08 18:43 UTC
[Bug 2336] Expose dynamic port for -R 0:... via environment
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.
bugzilla-daemon at mindrot.org
2015-May-08 18:50 UTC
[Bug 2336] Expose dynamic port for -R 0:... via environment
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.
bugzilla-daemon at mindrot.org
2021-Sep-19 09:40 UTC
[Bug 2336] Expose dynamic port for -R 0:... via environment
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.
Seemingly Similar Threads
- [Bug 2081] New: extend the parameters to the AuthorizedKeysCommand
- [Bug 2272] New: Global "PermitTunnel Yes" required to connect to a tunnel
- [Bug 2324] New: remote port forward w/ empty bind_address via multiplexed connection: doc violation
- [PATCH/RFC 0/6] New mux client request to list open tcp forwardings.
- How do I make "vnd.dovecot.environment" available?