If you have something like Match host *.example.com exec /usr/bin/true ProxyCommand /usr/local/bin/ssh-helper %h %p in your ssh config, and your SHELL contains the name of the shell executable (and not its path), connection will fail with: Unable to execute '/usr/bin/true': No such file or directory command '/usr/bin/true' exited abnormally /etc/ssh_config line 46: match exec '/usr/bin/true' error
I don't think searching $PATH for SHELL is correct. The system shoudl never set $SHELL to a relative path and http://pubs.opengroup.org/onlinepubs/009695399/functions/system.html specifies system(3) to use execl(2), and it doesn't search $PATH.
Uhm, system(3) should use sh(1) manpages for sh(1) on my system are explicitly about bash, but otherwise I think it should be about this: http://pubs.opengroup.org/onlinepubs/009695399/utilities/sh.html which says that the path for `sh` should be resolved from PATH (I was under the impression that the POSIX standard specified that /bin/sh would always have to exist, but I guess I was wrong?) I haven't looked into openssh source code, but given the above, I'd be surprised if it used system(3) I understand that the behavior might not be changed, but the error message Unable to execute '/usr/bin/true': No such file or directory Seems to be a bit misleading to me, given that the actual command executed would've been something like sh -c /usr/bin/true Thanks anyhow for looking into this
Forgot to add: Unable to execute 'sh': No such file or directory Would've been much clearer as an error message, imho
Created attachment 3302 [details] check shell is executable to provide better error message
patch applied and will be in openssh-8.1, due soon. Thanks!
closing resolved bugs as of 8.6p1 release