Feature Request: socket-passing support in ssh client

[Chris Mitchell]

On Thu, 13 Jan 2022 09:04:46 -0800
Peter Moody <mindrot at hda3.com> 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 at 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 at chris.oldnest.ca> 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 at 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 at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev  
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev