openssh bugs - Aug 2023 - [Bug 3609] New: Support the special ${RANDOM} environment variable

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

            Bug ID: 3609
           Summary: Support the special ${RANDOM} environment variable
           Product: Portable OpenSSH
           Version: 9.4p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: erjoalgo at gmail.com

Created attachment 3727
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3727&action=edit
Patch to implement ${RANDOM} support

I use the RemoteForward keyword in my sshd_config file to create a unix
socket
on the remote host, I personally use this socket to map to a local
program
that can receive GUI-related commands, e.g. set clipboard, open a URL
in a browser,
etc, from any commands executed on the remote server. It looks
something like this:


Match host *
    SendEnv DESKTOP_GROUP_NUMBER
    RemoteForward /tmp/.x-service-debian-x1-7th.sock localhost:1959


Sometimes I have multiple ssh connections to the same machine, e.g.
using
multiple desktops for different areas of work, and the RemoteForward
request will fail because the remote socket has a fixed path and will
already be taken. So I need to make the RemoteForward unix socket path
to
be unique for each ssh connection.

I looked through man ssh_config and noticed the TOKENS section, but
they all
appear to be deterministic. I also noticed that RemoteForward
supports environment variables and tried to use the ${RANDOM}
environment variable, but this failed because ${RANDOM} is not a real
environment variable but rather a bash feature.

So I implemented a feature to support a bash-like ${RANDOM} environment
variable
when expanding tokens and environment variables. This can be very
useful for
generating connection-unique strings, and usage should be
straightforward. My RemoteForward directive now looks like:


Match host *
    SendEnv DESKTOP_GROUP_NUMBER
    RemoteForward /tmp/.x-service-debian-x1-7th-${RANDOM}.sock
localhost:1959


I've tested and this works as expected. I have attached the patch, I
hope it can be merged, please let me know if you have any suggestions.

Thanks,

Ernesto

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
How would this actually work? $RANDOM doesn't end up anywhere usable
other than the listening path on the remote side. Do you enumerate all
paths there to figure out which one?

I suspect $RANDOM isn't the best solution for your underlying problem.
For a start, some shells already provide this with syntax that is
incompatible with yours (e.g. https://man.openbsd.org/ksh.1#RANDOM).
Furthermore, a merely random input is only part of an effective
unique/temporary name facility.

Would an explicit unique/temporary name facility for forwarded Unix
domain sockets be better? There is already an analogous thing for
remote-forward ports, where a listener port number of 0 indicates that
the server should allocate one and tell the client what it picked. We
could do something similar here (say when passed an empty listen
pathname). Would this work for you?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

--- Comment #2 from Ernesto Alfonso <erjoalgo at gmail.com>
---
> How would this actually work? $RANDOM doesn't end up anywhere usable
other than the listening path on the remote side. Do you enumerate all paths
there to figure out which one?
On the remote side the client program can use a glob like
/tmp/.x-service-*.sock. This is possible because I can control where
within the RemoteForward path the ${RANDOM} gets inserted.
> I suspect $RANDOM isn't the best solution for your underlying problem. 
The solution certainly works for me but if you have a better suggestion
I would be open to it.
> For a start, some shells already provide this with syntax that is
incompatible with yours (e.g. https://man.openbsd.org/ksh.1#RANDOM).
Not sure I follow. I installed ksh and `echo ${RANDOM}` worked as
expected, how is that syntax incompatible?
> Furthermore, a merely random input is only part of an effective
unique/temporary name facility.
That is exactly how the feature would be useful to me.
> Would an explicit unique/temporary name facility for forwarded Unix domain
sockets be better? There is already an analogous thing for remote-forward ports,
where a listener port number of 0 indicates that the server should allocate one
and tell the client what it picked. We could do something similar here (say when
passed an empty listen pathname). Would this work for you?
On the remote side I need to know where to look, so binding to a random
port or wouldn't be very useful. That is the reason I am using unix
sockets with a regular, globabble pattern and a fixed prefix.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.