ProxyCommand not working if $SHELL not defined

[Antonio Mignolli]

I forgot, same issue with sftp, when executing local commands.



2009/9/12 Antonio Mignolli <antoniomignolli at gmail.com>

> Now I got it.
> It happens when SHELL is defined but as empty string,
> so I don't know if is to be considered an openssh issue.
>
> My user had a blank field in /etc/passwd, and logging in
> in a icewm environment will give me shells with
> an empty SHELL variable, causing getenv return a not NULL value.
> Same issue when executing ssh_local_cmd, for the same reason,
> there is another check on SHELL not null.
> I have tested that, and with SHELL="" I got "Couldn't execute ..".
>
> Thanks for your attention.
>
> 2009/9/11 Darren Tucker <dtucker at zip.com.au>
>
> Antonio Mignolli wrote:
>>
>>> Probably is not a real issue, because everyone should have its SHELL var
>>> defined,
>>> but as said above, when it's not, ssh with ProxyCommand will fail.
>>> I use connect.c, but with no SHELL var defined is not executed, ssh -v
>>> will give "No such file", and I'm pretty sure it refers to the shell,
>>> I read in ChangeLog that now ProxyCommand will use $SHELL instead
>>> of /bin/sh.
>>> Maybe consider using /bin/sh as default when SHELL is not defined?
>>>
>>
>> It already does that.  From sshconnect.c:ssh_proxy_connect()
>>
>>        if ((shell = getenv("SHELL")) == NULL)
>>                shell = _PATH_BSHELL;
>>
>> where _PATH_BSHELL is defined in defines.h as:
>>
>> #ifndef _PATH_BSHELL
>> # define _PATH_BSHELL "/bin/sh"
>>
>> The only thing I can think of is _PATH_BSHELL being defined in the system
>> headers and pointing somewhere else.  If you strace/truss ssh can you see
>> what it's trying to open immediately before the "No such file"?
>>
>> --
>> Darren Tucker (dtucker at zip.com.au)
>> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>>    Good judgement comes with experience. Unfortunately, the experience
>> usually comes from bad judgement.
>>
>
>