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@xxxxxxxxxxx. 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
