Thanks for your thoughts Thorsten, On Tue, 7 Jun 2022, Thorsten Glaser wrote: > > not interacting well with multiple SSH clients. Specifically, each subsequent client attempts to initiate a new RemoteForward, destroying > > This is the same for TCP port forwarding, except the next attempts say they cannot bind. TCP port forwarding has a dynamic port selection feature not available to unix socket forwarding. From ssh_config: If the port argument is 0, the listen port will be dynamically allocated on the server and reported to the client at run time. I think it seems reasonable to extend that to unix socket forwarding. This is similar in principle to what ForwardAgent currently does. Note that one problem with setting the TCP port argument to 0 is that the bound value is reported to the client rather than the remote environment. I think others have noticed that this could have more utility reported as an environment variable on the remote. Example: https://bugzilla.mindrot.org/show_bug.cgi?id=2336 > Canonical solution for that is to use a muxmaster, which then does the forwards, and subsequent connections just pick up the mux. Recognizing that this is a possible workaround, I think there's still significant advantages to decoupling RemoteForward from ControlMaster. With a muxer, all SSH connections go through a single TCP connection which can cause shared latency. It seems unintuitive to couple ControlMaster and its side effects to a seamless RemoteForward workflow, especially when ForwardAgent has a first-party private implementation that third-party tools like gpg-agent could benefit from. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
