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

[Peter Stuge]

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