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

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.

On Fri, 10 Jun 2022, Brandon Cheng wrote:
> 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
I think that could be made to work - we'd need ssh's main() to generate
a single random token per connection, though it might be possible for
a user to shoot themselves in the foot if they reused the token for
multiple things and exposed it to an on-host attacker. We generally
avoid leaving footguns around.
> 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.
Another option: remote port-forwarding has a notion of server-allocated
ports, that are communicated back to the client. We could do something
similar for Unix domain sockets too, but with a server-generated /tmp
path instead of a port.

The downside is that this is only really useful when used in conjunction
with ControlPath, and they take a fair bit more connection setup.

Another option still: use the server-assigned port/temp-path feature, but
have the client automatically create SetEnv directives for it. Since
forwardings are processed before shell/command session execution, this
could be fairly automatic for users. The catch here is figuring out how
to communicate multiple (potentially many) forwardings via SetEnv.

-d