On 19Oct2018 22:22, Christian Weisgerber <naddy@xxxxxxxxxxxx> wrote:
Cameron Simpson:
I don't mean TCP forwards but UNIX domain socket forwarding. I use
LocalForward extensively in my ssh configs for tunnels, but although
these command line options:
-L [bind_address:]port:host:hostport
-L [bind_address:]port:remote_socket
-L local_socket:host:hostport
-L local_socket:remote_socket
work just fine for UNIX domain sockets, all my efforts with UNIX socket
file paths have met with failure in the ssh config file,
Looking at the configuration and argument handling code, I don't
see why they shouldn't work. And some quick checks show them to
be working.
Are you confused about the syntax? The LocalForward option requires
source and destination to be separated by whitespace, e.g.
LocalForward /path/to/socket host:4711
LocalForward /local/socket /remote/socket
I'm an idiot. Reviewing my tests it seems I never tried a combo where
both sockets have full pathnames - all my tests used a relative pathname
for at least one of the sockets.
It is as you say: it works. Provided I use a full pathname for the
socket.
and the ssh_config(5) manual entry doesn't mention them.
This looks like an accidental omission.
Want a patch? I'll make one.
I'd like to include the syntactic distinction required, along the lines
of "socket paths are identified by having a leading slash". I'll check
that that's what the code does :-) _If_ that's the criterion, I'll also
offer a patch supporting a leading "./" as well, as it seem very
desirable to me to be able to make the sockets relative to the users'
home directories.
Cheers,
Cameron Simpson <cs@xxxxxxxxxx>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
