Mailing List Archive

Feature Request: socket-passing support in ssh client
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@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Feature Request: socket-passing support in ssh client [ In reply to ]
I could be misunderstanding your use-case, but ssh has a
ProxyUseFdpass option where it can accept an already-connected socket.

On Thu, Jan 13, 2022 at 8:19 AM Chris Mitchell
<ssh-list@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@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@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Feature Request: socket-passing support in ssh client [ In reply to ]
On Thu, 13 Jan 2022 09:04:46 -0800
Peter Moody <mindrot@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@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@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@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@mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Feature Request: socket-passing support in ssh client [ In reply to ]
On Fri, 14 Jan 2022 at 03:17, Chris Mitchell <ssh-list@chris.oldnest.ca>
wrote:

> 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. ;-)
>

It's not exactly what you ask for later, but it's the exact counterpart for
sshd -i: you can run ssh under inetd (or similar) in "netcat mode" (-W),
where it will pass data on stdin/out to a remote port forward. You'd put
something like this in inetd.conf:

ssh -W destinationhost:port intermediatehost

and set it up with passwordless auth. This will bring up the connection on
demand, but the caveat is that there will be one SSH connection per
forwarded TCP connection, not many multiplexed TCP connections within a
single SSH connection. I've used this construction in the past for various
shenanigans such as routing low-volume mail and accessing backup servers
between networks without direct connections.

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
RE: Feature Request: socket-passing support in ssh client [ In reply to ]
On January 13, 2022 6:01 PM, Darren Tucker wrote:
> On Fri, 14 Jan 2022 at 03:17, Chris Mitchell <ssh-list@chris.oldnest.ca>
> wrote:
>
> > 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. ;-)
> >
>
> It's not exactly what you ask for later, but it's the exact counterpart
for sshd -i: you
> can run ssh under inetd (or similar) in "netcat mode" (-W), where it will
pass data
> on stdin/out to a remote port forward. You'd put something like this in
inetd.conf:
>
> ssh -W destinationhost:port intermediatehost
>
> and set it up with passwordless auth. This will bring up the connection
on demand,
> but the caveat is that there will be one SSH connection per forwarded TCP
> connection, not many multiplexed TCP connections within a single SSH
> connection. I've used this construction in the past for various
shenanigans such as
> routing low-volume mail and accessing backup servers between networks
without
> direct connections.

For multiplexed connections, would not local port forwarding be a better
architecture? It does not pass off sockets but allows on-demand access.
--Randall

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Feature Request: socket-passing support in ssh client [ In reply to ]
On Fri, 14 Jan 2022 10:01:29 +1100
Darren Tucker <dtucker@dtucker.net> wrote:

> It's not exactly what you ask for later, but it's the exact
> counterpart for sshd -i: you can run ssh under inetd (or similar) in
> "netcat mode" (-W), where it will pass data on stdin/out to a remote
> port forward. You'd put something like this in inetd.conf:
>
> ssh -W destinationhost:port intermediatehost

Ah-ha! I think that will do nicely for my purposes. I'll try my
on-demand setup with that option and see what sort of trouble I can get
myself into.

Cheers!
-Chris
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Feature Request: socket-passing support in ssh client [ In reply to ]
On Thu, 13 Jan 2022 18:11:20 -0500
<rsbecker@nexbridge.com> wrote:

> For multiplexed connections, would not local port forwarding be a
> better architecture? It does not pass off sockets but allows
> on-demand access. --Randall

I must admit I don't really get what you're suggesting.

When you say "local port forwarding", do you mean the "ssh -L" option?
Because if that allows the kind of on-demand access I've described,
I'd be grateful if you could explain how to do it.

Or do you mean some other tool to forward one or more local ports to the
one local port that ssh is already forwarding to the remote host? (Does
that even make sense?) Or something else again?

And I may have made an A/B error talking about passing off sockets.
Passing sockets is not an objective per se, but rather in my limited
understanding I had assumed it was "the" way to achieve the kind of
on-demand port forwarding I'm after.

Cheers!
-Chris
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
RE: Feature Request: socket-passing support in ssh client [ In reply to ]
On January 14, 2022 12:45 PM, Chris Mitchell wrote:
> On Thu, 13 Jan 2022 18:11:20 -0500
> <rsbecker@nexbridge.com> wrote:
>
> > For multiplexed connections, would not local port forwarding be a
> > better architecture? It does not pass off sockets but allows on-demand
> > access. --Randall
>
> I must admit I don't really get what you're suggesting.
>
> When you say "local port forwarding", do you mean the "ssh -L" option?
> Because if that allows the kind of on-demand access I've described, I'd be
grateful
> if you could explain how to do it.
>
> Or do you mean some other tool to forward one or more local ports to the
one
> local port that ssh is already forwarding to the remote host? (Does that
even make
> sense?) Or something else again?
>
> And I may have made an A/B error talking about passing off sockets.
> Passing sockets is not an objective per se, but rather in my limited
understanding I
> had assumed it was "the" way to achieve the kind of on-demand port
forwarding
> I'm after.

Yes, ssh -L address. Once you set up the forward, you can then connect a
local socket over an existing SSH session. The connection is independent of
other connections, so you don't have to worry about multiplexing. Once the
session ends, all of the forwarding ends also. You don't need to pass off
the socket, although you can use standard Linux socket passing techniques to
do that.
--Randall

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Feature Request: socket-passing support in ssh client [ In reply to ]
Chris Mitchell wrote this message on Fri, Jan 14, 2022 at 13:01 -0400:
> On Fri, 14 Jan 2022 10:01:29 +1100
> Darren Tucker <dtucker@dtucker.net> wrote:
>
> > It's not exactly what you ask for later, but it's the exact
> > counterpart for sshd -i: you can run ssh under inetd (or similar) in
> > "netcat mode" (-W), where it will pass data on stdin/out to a remote
> > port forward. You'd put something like this in inetd.conf:
> >
> > ssh -W destinationhost:port intermediatehost
>
> Ah-ha! I think that will do nicely for my purposes. I'll try my
> on-demand setup with that option and see what sort of trouble I can get
> myself into.

ControlMaster/ControlPath (see ssh_config(5)) can be used to send multiple
sessions over a single connection if that is so desired.

From ControlMaster:
These sessions will try to reuse the master instance's
network connection rather than initiating new ones, but will fall
back to connecting normally if the control socket does not exist,
or is not listening.

--
John-Mark Gurney Voice: +1 415 225 5579

"All that I will do, has been done, All that I have, has not."
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev