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

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.

On Tue, 7 Jun 2022, Brandon Cheng wrote:
> > 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
You can split that as well, though.

Just add a separate Host section to your SSH config for the muxer,
use it with -fNM to start the muxer, without to use it, and use a
different Host section to create separate connections. On the remote
side, just pick up the agent forwarded from the other connection.

This needs a little shell scripting but no more than your solution,
I believe. I?ve got a similar setup except I make all remote sessions
and all desktop sessions on the remote box (native X and xrdp and VNC)
pick up the ssh-agent and gpg-agent running on the remote box, instead
of forwarding one from the local box.

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!
                        ****************************************************