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

[Spencer Baugh]

Damien Miller <djm at mindrot.org> writes:
> 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.

I've been looking fairly deeply at the multiplexing protocol (I'd
probably use this feature primarily through the multiplexing protocol)
but I don't think it's exactly what I'm talking about.

You're right that a multiplexing client passes stdin/stdout/stderr to
the primary multiplexing process, on the client side of the connection.
So on the client side, the user can completely control what file
descriptors are used, by passing in whatever stdin/stdout/stderr they
want.

But I'm concerned about the server side; there, it's sshd that creates
the file descriptors. I'd like it to be possible to specify to sshd
which file descriptors the channel should be forwarded to, rather than
sshd just creating its own pipes and passing those to the executed
command. (And my proposal is to do that by having the executed command
return one or more file descriptors)