StreamLocalBindUnlink is advertised as an option for the client program. Following the codepath, it ends up as an option for the server program. Server process receives in serverloop.c:1409 "streamlocal-forward@openssh.com" receives fwd.listen_path calls channel_setup_remote_fwd_listener(&fwd, NULL, &options.fwd_opts) channels.c: channel_setup_local_fwd_listener -> channel_setup_fwd_listener_streamlocal channel_setup_fwd_listener_streamlocal(int type, struct Forward *fwd, struct ForwardOptions *fwd_opts) calls unix_listener(fwd->listen_path, SSH_LISTEN_BACKLOG, fwd_opts->streamlocal_bind_unlink) fwd_opts->streamlocal_bind_unlink is set in servconf.c and thus a server option. To fix this, not only the fwd.listen_path would have to be transmitted, but also the bind_unlink flag, which would probably need a new type of message, like "streamlocal-forward-unbind@openssh.com"
Could you take a look at this Todd?
ping?
A Unix domain socket can be used on either the local or remote side. That is why the StreamLocalBindUnlink and StreamLocalBindMask settings appear in both ssh_config and sshd_config. I'm not sure that overriding the values in sshd_config on the remote end with those from the local ssh is a good idea. Perhaps we need separate options to specify the values to be sent to the remote end?
(In reply to Todd C. Miller from comment #3) > A Unix domain socket can be used on either the local or remote side. > That is why the StreamLocalBindUnlink and StreamLocalBindMask > settings appear in both ssh_config and sshd_config. I'm not sure > that overriding the values in sshd_config on the remote end with > those from the local ssh is a good idea. Perhaps we need separate > options to specify the values to be sent to the remote end? why should it be globally restricted in sshd_config?
This bug is remarkably irritating! I use domain sockets forwarding to bring my GPG agent with me as I ssh around the universe and roughly 100% of the time, I have to log in, rm the stale forwarding socket, log out, and log back in. "Warning: remote port forwarding failed for listen path /users/nwf/.gnupg/S.gpg-agent" is particularly galling because I have full permission to remove the offending file *and* I have the StreamLocalBindUnlink directive asserted which is documented to solve this problem! There appears to be nothing that executes, server-side, under client control prior to attempting UNIX domain socket bindings, so I can't even hack around the bug with something like .ssh/rc containing a rm call.
Just ran into this - the documentation on the client makes it sound like it will clean up the socket when remote forwarding is happening, but the server must be configured to do this. Currently, there is no way to properly do remote forwarding of unix sockets to a server more than once as it will fail the second time.