On Thu, 13 Jan 2022 09:04:46 -0800 Peter Moody <mindrot@xxxxxxxx> wrote: > I could be misunderstanding your use-case, but ssh has a > ProxyUseFdpass option where it can accept an already-connected socket. Hmm, interesting. It's entirely possible that *I* am misunderstanding, but by my reading, that doesn't look like it addresses the problem. As I understand it, ProxyUseFdpass only has any effect when used in conjunction with ProxyCommand, and results in a flow like the following: ssh is invoked → ssh invokes proxy command → proxy command creates a port and actually establishes a connection to the remote (ssh server) machine → proxy command (which is a child of ssh) now passes the connected port back to ssh by FD → ssh assumes the passed port is plugged in to an ssh server somewhere and starts the authentication process, skipping the network connection phase. But if some process has already claimed the local port (eg a systemd "socket" unit, or xinetd), before any of this process starts, the proxy command will simply error out because the port is already in use… Right? What I'm looking for is the initial invocation of ssh client to go something like: ssh -N -T -L localhost:UsePassedFD:localhost:12345 user@server There's no proxy, and no remote connection has been made. But the process invoking ssh client (systemd or xinetd) is holding a local port that some process is trying to connect to with the expectation that the port is forwarded to "localhost:12345" on "server" over an ssh tunnel. Along with the above command line, systemd (or xinetd) also passes that port by FD, just like it would if it were invoking sshd with "-i". SSH then handles making the connection and everything as normal. The only difference being at the step of establishing the actual port-forward tunnel to server:12345, the ssh client attaches the local end of the tunnel to the FD it was passed, instead of trying to create its own local port. Sorry if my terminology is sloppy, imprecise, or plain wrong. I hope I've got the details right enough to be comprehensible, but I may be in a bit over my head here. Cheers! -Chris > On Thu, Jan 13, 2022 at 8:19 AM Chris Mitchell > <ssh-list@xxxxxxxxxxxxxxxx> wrote: > > > > Hi all, > > > > My apologies if what I'm looking for is already possible. If that is > > the case, I would gratefully welcome pointers to where in the > > documentation to find it and/or key words to search for. > > > > What I hope to accomplish is on-demand activation of ssh port > > forwards. I gather that the OpenSSH server's -i flag is essentially > > what I'm looking for, in which something like inetd or systemd > > already has port 22 open and passes it to sshd at launch. As far as > > I understand things, the OpenSSH *client* has no similar > > capability, which is unsurprising given that it's not a server. ;-) > > > > For the use case where I want to use an SSH port forward to access a > > remote service on a regular-ish (but not "always-on") basis, it > > doesn't really make sense to try to hold that tunnel open all the > > time with keepalives and timeouts and restarts and such. But > > setting it up manually each time is suboptimal, especially for > > someone who uses numerous such tunnels, eg to access a bunch of > > web-based management interfaces behind a firewall. As far as I > > know, current capabilities don't allow any reasonable on-demand > > automated solution. > > > > It would be really cool if I could have a meta-server listening > > on the local port right from boot, and then on access to that port > > it would invoke something like: > > /usr/bin/ssh -N -T -L localhost:12345:localhost:12345 user@server > > ...but with some equivalent to sshd's "-i" flag, so that the > > ssh client would accept being passed local port 12345 instead of > > trying to open it itself and erroring out because it's already in > > use. > > > > In my particular use-case I would use a systemd socket unit for > > this, but if I'm not mistaken xinetd could fulfill that role too, > > so what I'm looking for is platform-independent and doesn't > > introduce any systemd dependencies. Finally, it would be convenient > > if it could take the local socket from the command line rather than > > requiring custom entries in /etc/services, but that's a minor > > detail. > > > > Does that make sense? > > > > Cheers! > > -Chris > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev@xxxxxxxxxxx > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
