openssh unix dev - Jun 2022 - Problems using RemoteForward for gpg-agent with multiple sessions

On Tue, 7 Jun 2022, Brandon Cheng 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.

Canonical solution for that is to use a muxmaster, which then does
the forwards, and subsequent connections just pick up the mux.

bye,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://www.tarent.de/newsletter
??? header encryption!
                        ****************************************************

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.