openssh unix dev - May 2021 - Feature proposal: ProxyUseFdpass-like behavior for a regular ssh session

Hi,

I have a feature that I'd like to implement if it's acceptable to the
OpenSSH developers.

In short, I'd like to implement a mode for running an ssh session which
functions like ProxyCommand+ProxyUseFdpass: the specified command is
passed a socketpair, and is then expected to pass out a file descriptor;
IO from the client will then be forwarded to and from that file
descriptor.

This is similar to -W, except that instead of forwarding stdin to a
socket connected to a specified host and port, stdin is forwarded to an
arbitrary file descriptor as passed out by the command.

The advantage relative to today is reduced overhead and reduced
complexity.  One could achieve similar behavior today by just running a
command which proxies stdio to a user-specified file descriptor; but the
extra command both adds overhead and increases complexity.  The argument
is the same as the argument for ProxyUseFdpass: By allowing the user to
specify which file descriptor OpenSSH should forward data to, that
overhead and complexity is elimiated.

I'm not an expert on the SSH protocol, but I believe this would require
a protocol change; a new @openssh.com channel type, perhaps called
fdpass at openssh.com.

Use cases for this:

- -W-style socket forwarding for AF_UNIX and other socket families. This
is useful for, among other things, accessing remote daemons without
extra overhead.

- More customization of AF_INET socket parameters for -W, including
customization of the source address. This could be achieved with an
invocation of "ssh -XXX nc -f -s 1.2.3.4". (I see this was
coincidentally requested on this list a few weeks ago)

- Implementation of other more dynamic forwarding modes, without added
overhead, and without requiring OpenSSH to support them. As a concrete
example, I'd like to use TCP forwarding like -L, but with a listening
socket pre-created by the user and passed in to ssh; this is useful when
using chroot/container/network namespacing features, where ssh might be
running in a separate container from the listening socket. This could be
achieved with minimal overhead by a simple user-written script which
accepts connections on the listening socket and runs "ssh -XXX nc -f
1.2.3.4 1234" for each connection.

- In general, zero-extra-overhead usage of SSH channels. With this
fd-passing behavior, the user is able to determine the file descriptors
used by OpenSSH on both sides, and OpenSSH simply forwards data from the
user-controlled file descriptors on one side to the other side.
Zero-overhead access to SSH channels like this has many uses in
application programming.

I'm happy to implement this with whatever design is preferred by the
OpenSSH developers, as long as it provides the core feature of
user-controlled minimal-overhead access to SSH channels which are
maintained by OpenSSH, without the user having to implement the SSH
protocol.

Thanks for OpenSSH!

Hi Spencer,

Spencer Baugh wrote:
> In short, I'd like to implement a mode for running an ssh session which
> functions like ProxyCommand+ProxyUseFdpass: the specified command is
> passed a socketpair, and is then expected to pass out a file descriptor;
> IO from the client will then be forwarded to and from that file
> descriptor.
> 
> This is similar to -W, except that instead of forwarding stdin to a
> socket connected to a specified host and port, stdin is forwarded to an
> arbitrary file descriptor as passed out by the command.
So you know that ProxyCommand executes on the client before the session
starts while -W opens a "direct-tcpip" channel inside the session
making
the peer sshd create a TCP connection to the -W host and port parameters,
right?

To me, these two don't compare at all well.

Since "direct-tcpip" is a standardized channel type it's
reasonable
to expect widespread support in servers and -W/-J work widely.

> I'm not an expert on the SSH protocol, but I believe this would require
> a protocol change; a new @openssh.com channel type, perhaps called
> fdpass at openssh.com.
If you want sshd itself to implement this then yes.


But couldn't you achieve what you want with a subsystem configured in
existing sshd_config and invoked through ssh -s on clients?

> - -W-style socket forwarding for AF_UNIX and other socket families.
> This is useful for, among other things, accessing remote daemons
> without extra overhead.
Which software is AF_UNIX client in that use case?

Do you envision the original daemon client utility transparently using
the SSH channel? If so, how?

> - More customization of AF_INET socket parameters for -W, including
> customization of the source address. This could be achieved with an
> invocation of "ssh -XXX nc -f -s 1.2.3.4". (I see this was
> coincidentally requested on this list a few weeks ago)
Right, direct-tcpip doesn't permit the client to dictate what address
the sshd TCP client binds to for the outgoing connection.

> - Implementation of other more dynamic forwarding modes, without added
> overhead, and without requiring OpenSSH to support them. As a concrete
> example, I'd like to use TCP forwarding like -L, but with a listening
> socket pre-created by the user and passed in to ssh; this is useful when
> using chroot/container/network namespacing features, where ssh might be
> running in a separate container from the listening socket. This could be
> achieved with minimal overhead by a simple user-written script which
> accepts connections on the listening socket and runs "ssh -XXX nc -f
> 1.2.3.4 1234" for each connection.
How is the socket passed out of the container/namespace? In a pipe? Which?

> - In general, zero-extra-overhead usage of SSH channels. With this
> fd-passing behavior, the user is able to determine the file descriptors
> used by OpenSSH on both sides, and OpenSSH simply forwards data from the
> user-controlled file descriptors on one side to the other side.
> Zero-overhead access to SSH channels like this has many uses in
> application programming.
Is this also a subsystem candidate?

> user-controlled minimal-overhead access to SSH channels
A subsystem is pretty much that..?

> which are maintained by OpenSSH
What does that actually mean?

> without the user having to implement the SSH protocol.
Hm, why would they have to?


I'm sorry - as you can tell I'm pretty confused. Can you help me out?


Thanks

//Peter

On Wed, 26 May 2021, Spencer Baugh wrote:
> Hi,
> 
> I have a feature that I'd like to implement if it's acceptable to
the
> OpenSSH developers.
> 
> In short, I'd like to implement a mode for running an ssh session which
> functions like ProxyCommand+ProxyUseFdpass: the specified command is
> passed a socketpair, and is then expected to pass out a file descriptor;
> IO from the client will then be forwarded to and from that file
> descriptor.
> 
> This is similar to -W, except that instead of forwarding stdin to a
> socket connected to a specified host and port, stdin is forwarded to an
> arbitrary file descriptor as passed out by the command.
This is basically how the multiplexing protocol works right now.
Take a look at mux.c:mux_client_request_session() - it passes the
stdin, stdout and stderr fds to the primary multiplexing process.
>From what you describe, you couple probably use this facility with
a custom client that spoke the simple (but undocumented) multiplexing
protocol to do what you need.

-d