Problems using RemoteForward for gpg-agent with multiple sessions

Brandon Cheng brandon at brandoncheng.me
Wed Jun 8 08:46:45 AEST 2022


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.



More information about the openssh-unix-dev mailing list