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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
