(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@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.)
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.
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.
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).
(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. """
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@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@target_host command as a workaround for this problem.
(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.
OK, "manage the caller side" is the answer. Closing this report as "WONTFIX". Thank you.
(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 .
closing resolved bugs as of 8.6p1 release