Bug 3449 - LocalForward doesn't support ~/path syntax for UNIX sockets
Summary: LocalForward doesn't support ~/path syntax for UNIX sockets
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 9.0p1
Hardware: Other Linux
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_9_4
  Show dependency treegraph
 
Reported: 2022-06-24 08:19 AEST by Christoph Anton Mitterer
Modified: 2023-03-17 13:33 AEDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Anton Mitterer 2022-06-24 08:19:52 AEST
Hey.

LocalForward, and presumably the other *Forward options too, doesn't seem to support ~/ syntax for UNIX sockets, as e.g. supported by options like IdentityFile.

e.g.:
  LocalForward ~/.ssh/forward-sockets/foo /home/remote-user/sock
doesn't work, while:
  LocalForward /home/local-user/.ssh/forward-sockets/foo /home/remote-user/sock
works.

Perhaps that could be added.

Thanks,
Chris.
Comment 1 Darren Tucker 2022-06-24 14:17:14 AEST
(In reply to Christoph Anton Mitterer from comment #0):
> LocalForward, and presumably the other *Forward options too, doesn't
> seem to support ~/ syntax for UNIX sockets, as e.g. supported by
> options like IdentityFile.

That would not be hard to add.

Note that it would not make sense to expand tildes for the remote path since there's no guarantee that the local path is the same as the remote path (this is not in your example, just mentioning it.)
Comment 2 Christoph Anton Mitterer 2022-06-25 00:14:49 AEST
I guess for a remote expansion sshd would need to support it?

At least ssh should then fail (or warn), if a remote component is a tilde-expansion style pathname, so that users don't wrongly assume it might work.