Bug 3450 - provide a %u{N}token to encode special characters as literal ones
Summary: provide a %u{N}token to encode special characters as literal ones
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: Miscellaneous (show other bugs)
Version: 9.0p1
Hardware: Other Linux
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-24 08:28 AEST by Christoph Anton Mitterer
Modified: 2022-06-24 08:28 AEST (History)
0 users

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:28:58 AEST
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.