Feature proposal: ProxyUseFdpass-like behavior for a regular ssh session

[Spencer Baugh]

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!