Hi Damien, I was wondering if you had any further thoughts or if this isn't solvable without significant tradeoffs. I'm still happy to implement any of the suggestions and submit patches. I think I prefer the most recently mentioned $SSH_REMOTE_FORWARD_SOCKS_DIR approach. Thanks for your time. > On Jun 14, 2022, at 12:48 AM, Brandon Cheng <brandon@xxxxxxxxxxxxxxx> wrote: > > On Mon, 13 Jun 2022, Damien Miller wrote: > >> On Fri, 10 Jun 2022, Brandon Cheng wrote: >>> 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. > > I think you're right. Although the random token derived socket paths > don't need to be secret for this use case, I could see users relying on > the random token for other use cases requiring secrecy. > > Thanks for keeping security in mind. Although this could work, I'd > be nervous about creating a new common pattern of security > vulnerabilities. > > On Mon, 13 Jun 2022, Damien Miller wrote: > >> 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. > > Does the server-generated path need to be communicated back to the > client? Taking a spin on the "Possibility 1: New RemoteForward syntax" > suggestion from the first email, could the server-generated tmp path be > placed in an $SSH_REMOTE_FORWARD_SOCKS_DIR environment variable? > > Host example > RemoteForward 0:example-foo /home/local/.foo.sock > RemoteForward 0:example-bar /home/local/.bar.sock > > $ ssh example > $ echo $SSH_REMOTE_FORWARD_SOCKS_DIR > /tmp/ssh-UIzrILLqkZ > $ ls -l $SSH_REMOTE_FORWARD_SOCKS_DIR > example-foo.sock > example-bar.sock > > Some immediate caveats I can think of: > > - This deviates from the TCP port behavior, which can be surprising. > - All forwarded sockets share the same server-generated path. Is this > a security concern? I think any unique path -> envvar approach would > leak RemoteForward socket paths to on-host attackers anyway, even if > each RemoteForward had a unique environment variable. By design this > is intentionally available to on-host processes. > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
