ProxyCommand not working if $SHELL not defined

Antonio Mignolli antonio.mignolli at yahoo.it
Thu Sep 17 19:21:54 EST 2009


Someone told me the patch was not attached.
I see it as correctly attached in my sent mail,
now I retry changing the file name.

2009/9/16 Antonio Mignolli <antonio.mignolli at yahoo.it>:
> Here is the suggested patch fixing the SHELL env var issues.
>
> 2009/9/16 Antonio Mignolli <antoniomignolli at gmail.com>
>>
>> I have a suggested patch for the discussed SHELL var issue.
>> With the help of a function get_shell_from_env(), in misc.c,
>> it is now able to set always a good shell, falling back
>> to default if SHELL is not defined or it is not a valid executable,
>> hence including SHELL="" (empty string).
>>
>> Tested in all cases:
>> . ssh with proxycommand
>> . ssh with local command execution
>> . sftp with local command execution (ex. lls)
>>
>> (The patch also changes getenv("SHELL") with get_shell_from_env()
>>   in ssh-agent.c, where there is a check whether csh is specified).
>>
>> The patch is made (and inspired) also by my friend Daniele Calore ( orkaan () orkaan dot org ).
>>
>> 2009/9/12 Antonio Mignolli <antoniomignolli at gmail.com>
>>>
>>> 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.
>>>>
>>>
>>
>


More information about the openssh-unix-dev mailing list