openssh bugs - Mar 2020 - [Bug 3142] New: ProxyCommand should not depend on SHELL environment variable.

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

            Bug ID: 3142
           Summary: ProxyCommand should not depend on SHELL environment
                    variable.
           Product: Portable OpenSSH
           Version: 8.0p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: penguin-kernel at I-love.SAKURA.ne.jp

(Sorry if this problem does not apply to upstream latest version.)

I noticed that /usr/bin/ssh in RHEL6/7/8 depends on SHELL environment
variable when invoking external command specified in ProxyCommand.

I tried to call

  /usr/bin/ssh -nT -i /path/to/key -o 'ProxyCommand nc -x
proxy_host:proxy_port %h %p' target_user at target_host command

from Apache's CGI program, but this request failed because $SHELL
environment variable was set to /sbin/nologin because Apache's login
shell is "/sbin/nologin").

While it is unlikely that users specify shell-specific commands as
ProxyCommand, I suspect that /usr/bin/ssh uses $SHELL when executing
ProxyCommand is what users want.
(ProxyCommand can be used in /etc/ssh/ssh_config which is a system-wide
configuration, but its interpretation depends on $SHELL which is a
per-user/process configuration. This might sound strange.)

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

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

Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |penguin-kernel at I-love.SAKUR
                   |                            |A.ne.jp

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

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

--- Comment #1 from Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp>
---
Well, it seems that CGI process did not set $SHELL environment
variable, and /usr/bin/ssh from CGI process scanned /etc/passwd for
login shell, and /sbin/nologin was used for executing ProxyCommand.

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

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

Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ProxyCommand should not     |ProxyCommand should be
                   |depend on SHELL environment |interpreted by a fixed
                   |variable.                   |shell like /bin/sh .

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

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #2 from Darren Tucker <dtucker at dtucker.net> ---
I don't think this is a good idea.  Always using /bin/sh would allow
users to evade any restrictions enforced by a restricted shell.

-- 
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=3142

--- Comment #3 from Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp>
---
I don't think that ProxyCommand is subjected to restricted shells, for
the shell used for interpreting ProxyCommand is currently controllable
by $SHELL environment variable.

If you do want to enforce restricted shell specified in /etc/passwd
file, you must ignore $SHELL (and you will break my program calling
batched operations using /usr/bin/ssh from Apache CGI).

-- 
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.

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

--- Comment #4 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Tetsuo Handa from comment #3)
> I don't think that ProxyCommand is subjected to restricted shells,
> for the shell used for interpreting ProxyCommand is currently
> controllable by $SHELL environment variable.
Restricted shells usually don't let you set $SHELL for exactly this
reason, eg:
https://www.gnu.org/software/bash/manual/html_node/The-Restricted-Shell.html

"""
A restricted shell behaves identically to bash with the exception that
the following are disallowed or not performed:
[...]
Setting or unsetting the values of the SHELL, PATH, ENV, or BASH_ENV
variables.
"""

-- 
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=3142

--- Comment #5 from Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp>
---
But my program (which is called as Apache CGI) does allow setting
$SHELL.

  sudo -u user /usr/bin/ssh -nT -i /path/to/key -o 'ProxyCommand nc -x
proxy_host:proxy_port %h %p' target_user at target_host command

which I chose

  sudo -u user SHELL=/bin/bash /usr/bin/ssh -nT -i /path/to/key -o
'ProxyCommand nc -x proxy_host:proxy_port %h %p'
target_user at target_host command

as a workaround for this problem.

-- 
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.

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

--- Comment #6 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Tetsuo Handa from comment #5)
> But my program (which is called as Apache CGI) does allow setting
> $SHELL.
That's great, because it means you have a way to make it work when you
want it to work.

Making the change you're asking for would mean that in other situations
it would work *when it's not supposed to work* which is a security
problem.

-- 
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=3142

Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|NEW                         |RESOLVED

--- Comment #7 from Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp>
---
OK, "manage the caller side" is the answer.

Closing this report as "WONTFIX". Thank 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=3142

--- Comment #8 from Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp>
---
(For the record)

Although Apache's login shell is /sbin/nologin , it is meant not to
allow shell login. Apache's CGI program is given freedom to use
arbitrary executable specified in the CGI program (i.e. not only
restricted shells but /bin/bash and perl and python). Therefore, for
processes invoked from CGI, it is an unexpected behavior that
/usr/bin/ssh uses /sbin/nologin for interpreting ProxyCommand. But
since CGI program can also set SHELL environment variable, setting
SHELL environment variable is the correct approach for preventing
/usr/bin/ssh from using /sbin/nologin .

-- 
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=3142

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #9 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
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.