2015.69 and password authentication

[Peter Krefting]

Hi!

Upgrading from 2015.68 to 2015.69 on the embedded platform at $DAYJOB, 
password authentication does no longer work. This seems to be related 
to a newly added test for crypt() in the configure script, which fails 
to find it and thus disables password authentication.


Has anyone else been bit by this, and is there a better workaround 
than to edit options.h to unconditionally enable 
ENABLE_SVR_PASSWORD_AUTH (removing the #ifdef HAVE_CRYPT test, which 
works fine).


--
\\// Peter - http://www.softwolves.pp.se/

Re: 2015.69 and password authentication

[Matt Johnston]

I'll sort out a new release to fix this later today.

Cheers,
Matt

On 26 November 2015 4:57:16 pm AWST, Peter Meerwald-Stadler  
wrote:
>
>> Upgrading from 2015.68 to 2015.69 on the embedded platform at
>$DAYJOB,
>> password authentication does no longer work. This seems to be related
>to a
>> newly added test for crypt() in the configure script, which fails to
>find it
>> and thus disables password authentication.
>
>same here
> 
>> Has anyone else been bit by this, and is there a better workaround
>than to
>> edit options.h to unconditionally enable ENABLE_SVR_PASSWORD_AUTH
>(removing
>> the #ifdef HAVE_CRYPT test, which works fine).
>
>export ac_cv_func_crypt=yes
>before calling configure -- just a nasty workaround, haven't looked
>into 
>the problem yet
>
>p.

Re: dropbear uclinux multiple client sessions

[Naveen Mamindlapalli]

Hi All,

Running from inetd solved the issue of multiple client connections at a time.

There is a limitation with non-inetd mode. Am I correct?

Thanks and Regards,
Naveen

On Wed, Nov 25, 2015 at 12:25 PM, Naveen Mamindlapalli
 wrote:
> Hi All,
>
> I am using dropbear sshd v0.52 (non-inetd mode) ported onto uClinux os
> running on ARM cortex M3 processor.
>
> I found that dropbear server is not accepting multiple ssh clients at
> a time. I need to exit the first client & then second client is
> connected. Until then the second client is suspended.
>
> I have debugged the code and found that vfork() in main_noinetd() is
> not returned for parent process & after reading man pages, I found
> that vfork() suspends the parent process until child exits or calls
> execve().
>
> Is there any fix for this issue?
>
> Thanks and Regards,
> Naveen

Re: dropbear uclinux multiple client sessions

[Naveen Mamindlapalli]

Hi Matt,

I didn't see your reply since it went into trash folder.Thanks for the reply.
I tried running from inetd & it worked fine.

Regards,
Naveen

On Thu, Nov 26, 2015 at 5:02 PM, Naveen Mamindlapalli
 wrote:
> Hi All,
>
> Running from inetd solved the issue of multiple client connections at a time.
>
> There is a limitation with non-inetd mode. Am I correct?
>
> Thanks and Regards,
> Naveen
>
> On Wed, Nov 25, 2015 at 12:25 PM, Naveen Mamindlapalli
>  wrote:
>> Hi All,
>>
>> I am using dropbear sshd v0.52 (non-inetd mode) ported onto uClinux os
>> running on ARM cortex M3 processor.
>>
>> I found that dropbear server is not accepting multiple ssh clients at
>> a time. I need to exit the first client & then second client is
>> connected. Until then the second client is suspended.
>>
>> I have debugged the code and found that vfork() in main_noinetd() is
>> not returned for parent process & after reading man pages, I found
>> that vfork() suspends the parent process until child exits or calls
>> execve().
>>
>> Is there any fix for this issue?
>>
>> Thanks and Regards,
>> Naveen

Dropbear 2015.70 fixes password authentication

[Matt Johnston]

Hi,

Dropbear 2015.70 released now fixes password server
authentication on Linux. It's a bit of an embarassing
mistake, apologies for that. Commenting out the test in
options.h is a fine workaround. 

Cheers,
Matt

On Thu, Nov 26, 2015 at 05:37:25PM +0800, Matt Johnston wrote:
> I'll sort out a new release to fix this later today.
> 
> Cheers,
> Matt
> 
> On 26 November 2015 4:57:16 pm AWST, Peter Meerwald-Stadler 
>  wrote:
> >
> >> Upgrading from 2015.68 to 2015.69 on the embedded platform at
> >$DAYJOB,
> >> password authentication does no longer work. This seems to be related
> >to a
> >> newly added test for crypt() in the configure script, which fails to
> >find it
> >> and thus disables password authentication.
> >
> >same here
> > 
> >> Has anyone else been bit by this, and is there a better workaround
> >than to
> >> edit options.h to unconditionally enable ENABLE_SVR_PASSWORD_AUTH
> >(removing
> >> the #ifdef HAVE_CRYPT test, which works fine).
> >
> >export ac_cv_func_crypt=yes
> >before calling configure -- just a nasty workaround, haven't looked
> >into 
> >the problem yet
> >
> >p.
>