openssh bugs - Jun 2022 - [Bug 3450] New: provide a %u{N}token to encode special characters as literal ones

https://bugzilla.mindrot.org/show_bug.cgi?id=3450

            Bug ID: 3450
           Summary: provide a %u{N}token to encode special characters as
                    literal ones
           Product: Portable OpenSSH
           Version: v9.0p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Miscellaneous
          Assignee: unassigned-bugs at mindrot.org
          Reporter: calestyo at scientia.org

Hey.

The following would be absolutely cosmetic and not really needed for
functionality... so if you say it's overkill, just close it, and I'm
fine with that.

I stumbled over this when trying to do:
  LocalForward /home/local-user/.ssh/forward-sockets/%r@%h:someID
/home/remote-user/sock

That fails with something like:
  /home/local-user/.ssh/config line 118: Bad forwarding specification.
  /home/local-user/.ssh/config: terminating, 1 bad configuration
options
which is because of the ":" in the pathname, which makes ssh think
that
would be a port and not a socket forwarding.

If one had a token like %u{N}, which takes the N to be a unicode
codepoint and takes that then "literally" (for *Formward in the sense
of not counting as a ":" that makes it a port forwarding), one could
write the above like:
  LocalForward /home/local-user/.ssh/forward-sockets/%r@%h%u{3A}someID
/home/remote-user/sock

and in addition also encode other weird characters in ssh config
options.

Cheers,
Chris.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.