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

On Tue, 7 Jun 2022, Brandon Cheng wrote:
> This works well, but intermittently the remote forward is unexpectedly
> destroyed. We've narrowed down the problem to the RemoteForward config
> not interacting well with multiple SSH clients. Specifically, each
> subsequent client attempts to initiate a new RemoteForward, destroying
> any previous forwards when doing so. When the most recently connected SSH
> client disconnects, the forward is left in an unbound state for all other
> existing clients.
[...]
> ## Possibility 1: New RemoteForward syntax
[...]
> ## Possiblity 2: New ForwardGpgAgent config
[...]
> ## Possibility 3: Allow client-side TCP port to be used in bind path
Another possibility would be to have some %-expansion that expands to
a random value that is long enough to be safely used as a temporary
path.

E.g. %R expanding to 24 base64 characters. You could use this to obtain
effectively unique paths.

-d

On Fri, 10 Jun 2022, Damien Miller wrote:
> Another possibility would be to have some %-expansion that expands to
> a random value that is long enough to be safely used as a temporary
> path.
>
> E.g. %R expanding to 24 base64 characters. You could use this to
> obtain effectively unique paths.
This would be a great solution.

To complete this option, how might the server determine the unique path?
I'm leaning towards SetEnv and updating it to understand
%-expansions. (If it doesn't already.)

  Host example
    RemoteForward /tmp/%R.sock /home/local/.gnupg/S.gpg-agent.extra
    SetEnv SSH_R_EXPANSION=%R

At the moment all %-expansions happen client-side, which is a nice and
simple design. The server could perform the %R expansion server-side if
that's the right approach, but it'd introduce a lot of new logic to the
server.

One other alternative to SetEnv would be to send the client-computed %R
as a SSH_CHANNEL_LARVAL state command, which is also involved.