From vishnug76 at yahoo.com  Thu Oct  1 06:21:57 2009
From: vishnug76 at yahoo.com (Vishnu Govardhana)
Date: Wed, 30 Sep 2009 15:21:57 -0700 (PDT)
Subject: Issue with PAM enabled dropbear !!
In-Reply-To: <20090929142235.GD8850@ucc.gu.uwa.edu.au>
References: <982544.67553.qm@web58308.mail.re3.yahoo.com>
	<20090929142235.GD8850@ucc.gu.uwa.edu.au>
Message-ID: <447797.10831.qm@web58307.mail.re3.yahoo.com>

Thanks for the response Matt.
I resolved it. I enabled PAM debug and that was pumping all
PAM messages to SSH and caused this failure.
Thanx,
~Sreedhar



----- Original Message ----
From: Matt Johnston <matt at ucc.asn.au>
To: Vishnu Govardhana <vishnug76 at yahoo.com>
Cc: dropbear at ucc.gu.uwa.edu.au
Sent: Tuesday, September 29, 2009 7:22:35 AM
Subject: Re: Issue with PAM enabled dropbear !!

On Fri, Sep 25, 2009 at 07:16:13PM -0700, Vishnu Govardhana wrote:
> Hi Gurus,
>  I am a newbie to dropbear. I compiled 0.48.1 version with --enable-pam.
> Now after installing it, my connection from a remote system is failing due
> to 'Bad packet length' (the number varies everytime). I tried to debug a bit
> using tcpdump and I see that 'pam_start' etc., messages has sent to remote
> system. 

Hi,

tcpdump of port 22 shouldn't see anything about PAM - everything should
be encrypted at that point. Could you save it to a file 
(tcpdump with "-w file.cap -s 0"), don't type your password,
and send it?

Matt


      


From rob at landley.net  Thu Oct  1 08:17:55 2009
From: rob at landley.net (Rob Landley)
Date: Wed, 30 Sep 2009 19:17:55 -0500
Subject: scp in dropbearmulti?
Message-ID: <200909301917.56112.rob@landley.net>

Is there a reason that one can't be included?

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


From vapier at gentoo.org  Thu Oct  1 11:46:17 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 30 Sep 2009 23:46:17 -0400
Subject: scp in dropbearmulti?
In-Reply-To: <200909301917.56112.rob@landley.net>
References: <200909301917.56112.rob@landley.net>
Message-ID: <200909302346.18277.vapier@gentoo.org>

On Wednesday 30 September 2009 20:17:55 Rob Landley wrote:
> Is there a reason that one can't be included?

dbscp is already in the multi build
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20090930/adedec29/attachment.pgp 

From rob at landley.net  Thu Oct  1 13:34:30 2009
From: rob at landley.net (Rob Landley)
Date: Thu, 1 Oct 2009 00:34:30 -0500
Subject: scp in dropbearmulti?
In-Reply-To: <200909302346.18277.vapier@gentoo.org>
References: <200909301917.56112.rob@landley.net>
	<200909302346.18277.vapier@gentoo.org>
Message-ID: <200910010034.30945.rob@landley.net>

On Wednesday 30 September 2009 22:46:17 Mike Frysinger wrote:
> On Wednesday 30 September 2009 20:17:55 Rob Landley wrote:
> > Is there a reason that one can't be included?
>
> dbscp is already in the multi build
> -mike

Really?

# ./dropbearmulti 
Dropbear multi-purpose version 0.52
Make a symlink pointing at this binary with one of the following names:
'dropbear' - the Dropbear server
'dbclient' or 'ssh' - the Dropbear client
'dropbearkey' - the key generator
'dropbearconvert' - the key converter

Where?

# ln -s dropbearmulti dbscp
# ./dbscp
Dropbear multi-purpose version 0.52
Make a symlink pointing at this binary with one of the following names:
'dropbear' - the Dropbear server
'dbclient' or 'ssh' - the Dropbear client
'dropbearkey' - the key generator
'dropbearconvert' - the key converter

Because I'm not finding it in the output of

./configure
make -j 2 MULTI=1

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


From matt at ucc.asn.au  Thu Oct  1 13:37:52 2009
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu, 1 Oct 2009 13:37:52 +0800
Subject: scp in dropbearmulti?
In-Reply-To: <200910010034.30945.rob@landley.net>
References: <200909301917.56112.rob@landley.net>
	<200909302346.18277.vapier@gentoo.org>
	<200910010034.30945.rob@landley.net>
Message-ID: <20091001053752.GC18879@ucc.gu.uwa.edu.au>

On Thu, Oct 01, 2009 at 12:34:30AM -0500, Rob Landley wrote:
> On Wednesday 30 September 2009 22:46:17 Mike Frysinger wrote:
> >
> > dbscp is already in the multi build
> 
> Really?
...
> Where?
...
> Because I'm not finding it in the output of
> 
> ./configure
> make -j 2 MULTI=1

It's not in the list by default. Try something like:

make -j 2 MULTI=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp"

and it should work. I'll make the docs a bit clearer.

Cheers,
Matt

From vapier at gentoo.org  Thu Oct  1 13:41:11 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 1 Oct 2009 01:41:11 -0400
Subject: scp in dropbearmulti?
In-Reply-To: <200910010034.30945.rob@landley.net>
References: <200909301917.56112.rob@landley.net>
	<200909302346.18277.vapier@gentoo.org>
	<200910010034.30945.rob@landley.net>
Message-ID: <200910010141.12577.vapier@gentoo.org>

On Thursday 01 October 2009 01:34:30 Rob Landley wrote:
> On Wednesday 30 September 2009 22:46:17 Mike Frysinger wrote:
> > On Wednesday 30 September 2009 20:17:55 Rob Landley wrote:
> > > Is there a reason that one can't be included?
> >
> > dbscp is already in the multi build
> 
> Really?
> 
> # ./dropbearmulti
> Dropbear multi-purpose version 0.52
> Make a symlink pointing at this binary with one of the following names:
> 'dropbear' - the Dropbear server
> 'dbclient' or 'ssh' - the Dropbear client
> 'dropbearkey' - the key generator
> 'dropbearconvert' - the key converter
> 
> Where?

reading the docs looks pretty straight forward to me.  plus there's always 
`grep` to find things.

$ ./dropbearmulti
Dropbear multi-purpose version 0.52
Make a symlink pointing at this binary with one of the following names:
'dropbear' - the Dropbear server
'dbclient' or 'ssh' - the Dropbear client
'dropbearkey' - the key generator
'dropbearconvert' - the key converter
'scp' - secure copy
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20091001/3d41d7d3/attachment.pgp 

From vapier at gentoo.org  Thu Oct  1 14:11:13 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 1 Oct 2009 02:11:13 -0400
Subject: scp in dropbearmulti?
In-Reply-To: <20091001053752.GC18879@ucc.gu.uwa.edu.au>
References: <200909301917.56112.rob@landley.net>
	<200910010034.30945.rob@landley.net>
	<20091001053752.GC18879@ucc.gu.uwa.edu.au>
Message-ID: <200910010211.14223.vapier@gentoo.org>

On Thursday 01 October 2009 01:37:52 Matt Johnston wrote:
> make -j 2 MULTI=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert
>  scp"
> 
> and it should work. I'll make the docs a bit clearer.

how would you feel about a dbscp alias ?  requiring the name to be "scp" is a 
bit annoying as it can easily conflict with parallel installs of openssh.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dropbear-0.51-dbscp.patch
Type: text/x-patch
Size: 552 bytes
Desc: not available
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20091001/5bd57119/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20091001/5bd57119/attachment.pgp 

From rob at landley.net  Thu Oct  1 17:21:21 2009
From: rob at landley.net (Rob Landley)
Date: Thu, 1 Oct 2009 04:21:21 -0500
Subject: scp in dropbearmulti?
In-Reply-To: <20091001053752.GC18879@ucc.gu.uwa.edu.au>
References: <200909301917.56112.rob@landley.net>
	<200910010034.30945.rob@landley.net>
	<20091001053752.GC18879@ucc.gu.uwa.edu.au>
Message-ID: <200910010421.21921.rob@landley.net>

On Thursday 01 October 2009 00:37:52 Matt Johnston wrote:
> On Thu, Oct 01, 2009 at 12:34:30AM -0500, Rob Landley wrote:
> > On Wednesday 30 September 2009 22:46:17 Mike Frysinger wrote:
> > > dbscp is already in the multi build
> >
> > Really?
>
> ...
>
> > Where?
>
> ...
>
> > Because I'm not finding it in the output of
> >
> > ./configure
> > make -j 2 MULTI=1
>
> It's not in the list by default. Try something like:
>
> make -j 2 MULTI=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert
> scp"
>
> and it should work. I'll make the docs a bit clearer.

I tried that already, why didn't it work?

Ah, I figured it out.

I did a "make" just specifying "MULTI=1" and nothing else (naievely assuming 
it'd build everything), then when it didn't include SMP I did another make 
with the PROGRAMS= list including scp (dunno where this is documented, I just 
read the comment at the top of the makefile).  And it did build several more 
files with scp in their names... and then once again produced a dropbearmulti 
binary that still didn't list scp.

What I _didn't_ do is "make clean" between the two, because I forgot that make 
dependencies are horked in the majority of projects in the world.  (Make 
dependencies are always horked, because make's dependency generation is 
obsolete.  They have to be maintained by hand and are seldom if ever tested, 
so they bit rot for anything but "make all" from a clean state.  Meaning you 
always need to do a "make clean; make all" when anything actually changes, 
such as configuration options or source code.)

I just forgot, my bad.

> Cheers,
> Matt

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


From rob at landley.net  Thu Oct  1 17:26:44 2009
From: rob at landley.net (Rob Landley)
Date: Thu, 1 Oct 2009 04:26:44 -0500
Subject: scp in dropbearmulti?
In-Reply-To: <200910010211.14223.vapier@gentoo.org>
References: <200909301917.56112.rob@landley.net>
	<20091001053752.GC18879@ucc.gu.uwa.edu.au>
	<200910010211.14223.vapier@gentoo.org>
Message-ID: <200910010426.45448.rob@landley.net>

On Thursday 01 October 2009 01:11:13 Mike Frysinger wrote:
> On Thursday 01 October 2009 01:37:52 Matt Johnston wrote:
> > make -j 2 MULTI=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert
> >  scp"
> >
> > and it should work. I'll make the docs a bit clearer.
>
> how would you feel about a dbscp alias ?  requiring the name to be "scp" is
> a bit annoying as it can easily conflict with parallel installs of openssh.

Ok, now I'm curious.  If this is really a problem, why didn't you need to 
similarly prefix every busybox command so you can call bbls and bbcp and 
install them in parallel to the gnu versions?

Or wouldn't it make more sense to do what busybox has been doing for the past 
decade and use "./dropbearmulti scp"?  (Or two different directories full of 
names, with your $PATH selecting which ones to use?)

Personally I dunno why it doesn't just call the server functionality sshd and 
have dropbear _be_ the multiplexer, but oh well.  It's not like openssh was 
the first ssh either, they forked off an existing one that closed up...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


From vapier at gentoo.org  Fri Oct  2 00:04:37 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 1 Oct 2009 12:04:37 -0400
Subject: scp in dropbearmulti?
In-Reply-To: <200910010426.45448.rob@landley.net>
References: <200909301917.56112.rob@landley.net>
	<200910010211.14223.vapier@gentoo.org>
	<200910010426.45448.rob@landley.net>
Message-ID: <200910011204.38316.vapier@gentoo.org>

On Thursday 01 October 2009 05:26:44 Rob Landley wrote:
> On Thursday 01 October 2009 01:11:13 Mike Frysinger wrote:
> > On Thursday 01 October 2009 01:37:52 Matt Johnston wrote:
> > > make -j 2 MULTI=1 PROGRAMS="dropbear dbclient dropbearkey
> > > dropbearconvert scp"
> > >
> > > and it should work. I'll make the docs a bit clearer.
> >
> > how would you feel about a dbscp alias ?  requiring the name to be "scp"
> > is a bit annoying as it can easily conflict with parallel installs of
> > openssh.
> 
> Ok, now I'm curious.  If this is really a problem, why didn't you need to
> similarly prefix every busybox command so you can call bbls and bbcp and
> install them in parallel to the gnu versions?

because we dont install busybox in parallel other than as a rescue shell, and 
once launched it is able to find its own applets just fine.  all existing db 
programs already have a db prefix, so having dbscp is nothing new.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20091001/096f5699/attachment-0001.pgp 

From rob at landley.net  Fri Oct  2 03:44:47 2009
From: rob at landley.net (Rob Landley)
Date: Thu, 1 Oct 2009 14:44:47 -0500
Subject: scp in dropbearmulti?
In-Reply-To: <200910011204.38316.vapier@gentoo.org>
References: <200909301917.56112.rob@landley.net>
	<200910010426.45448.rob@landley.net>
	<200910011204.38316.vapier@gentoo.org>
Message-ID: <200910011444.47596.rob@landley.net>

On Thursday 01 October 2009 11:04:37 Mike Frysinger wrote:
> On Thursday 01 October 2009 05:26:44 Rob Landley wrote:
> > On Thursday 01 October 2009 01:11:13 Mike Frysinger wrote:
> > > On Thursday 01 October 2009 01:37:52 Matt Johnston wrote:
> > > > make -j 2 MULTI=1 PROGRAMS="dropbear dbclient dropbearkey
> > > > dropbearconvert scp"
> > > >
> > > > and it should work. I'll make the docs a bit clearer.
> > >
> > > how would you feel about a dbscp alias ?  requiring the name to be
> > > "scp" is a bit annoying as it can easily conflict with parallel
> > > installs of openssh.
> >
> > Ok, now I'm curious.  If this is really a problem, why didn't you need to
> > similarly prefix every busybox command so you can call bbls and bbcp and
> > install them in parallel to the gnu versions?
>
> because we dont install busybox in parallel other than as a rescue shell,
> and once launched it is able to find its own applets just fine.  all
> existing db programs already have a db prefix, so having dbscp is nothing
> new. -mike

Actually only one has a db prefix, the rest all have a "dropbear" prefix, but if 
it makes you happy...

But if Matt goes there, it seems to me that the "dropbear" program should 
probably also be callable as "sshd" the way dbclient/ssh is.  (dropbearconvert 
is specific to dropbear, and dropbearkey isn't a drop-in replacement for ssh-
keygen the way the others are and only used once in a blue moon anyway).

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


From rob at landley.net  Fri Oct  2 14:55:29 2009
From: rob at landley.net (Rob Landley)
Date: Fri, 2 Oct 2009 01:55:29 -0500
Subject: scp in dropbearmulti?
In-Reply-To: <200910011444.47596.rob@landley.net>
References: <200909301917.56112.rob@landley.net>
	<200910011204.38316.vapier@gentoo.org>
	<200910011444.47596.rob@landley.net>
Message-ID: <200910020155.30087.rob@landley.net>

On Thursday 01 October 2009 14:44:47 Rob Landley wrote:
> On Thursday 01 October 2009 11:04:37 Mike Frysinger wrote:
> > On Thursday 01 October 2009 05:26:44 Rob Landley wrote:
> > > On Thursday 01 October 2009 01:11:13 Mike Frysinger wrote:
> > > > On Thursday 01 October 2009 01:37:52 Matt Johnston wrote:
> > > > > make -j 2 MULTI=1 PROGRAMS="dropbear dbclient dropbearkey
> > > > > dropbearconvert scp"
> > > > >
> > > > > and it should work. I'll make the docs a bit clearer.
> > > >
> > > > how would you feel about a dbscp alias ?  requiring the name to be
> > > > "scp" is a bit annoying as it can easily conflict with parallel
> > > > installs of openssh.
> > >
> > > Ok, now I'm curious.  If this is really a problem, why didn't you need
> > > to similarly prefix every busybox command so you can call bbls and bbcp
> > > and install them in parallel to the gnu versions?
> >
> > because we dont install busybox in parallel other than as a rescue shell,
> > and once launched it is able to find its own applets just fine.  all
> > existing db programs already have a db prefix, so having dbscp is nothing
> > new. -mike
>
> Actually only one has a db prefix, the rest all have a "dropbear" prefix,
> but if it makes you happy...
>
> But if Matt goes there, it seems to me that the "dropbear" program should
> probably also be callable as "sshd" the way dbclient/ssh is. 
> (dropbearconvert is specific to dropbear, and dropbearkey isn't a drop-in
> replacement for ssh- keygen the way the others are and only used once in a
> blue moon anyway).

By the way, you can't say "ssh" in PROGRAMS=, you have to say "dbclient".  But 
right now you have to list scp in there, and if you rename it does the build 
invocation change or will it handle both?

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


From matt at ucc.asn.au  Fri Oct  2 21:07:40 2009
From: matt at ucc.asn.au (Matt Johnston)
Date: Fri, 2 Oct 2009 21:07:40 +0800
Subject: scp in dropbearmulti?
In-Reply-To: <200910010211.14223.vapier@gentoo.org>
References: <200909301917.56112.rob@landley.net>
	<200910010034.30945.rob@landley.net>
	<20091001053752.GC18879@ucc.gu.uwa.edu.au>
	<200910010211.14223.vapier@gentoo.org>
Message-ID: <20091002130740.GG18879@ucc.gu.uwa.edu.au>

On Thu, Oct 01, 2009 at 02:11:13AM -0400, Mike Frysinger wrote:
> On Thursday 01 October 2009 01:37:52 Matt Johnston wrote:
> > make -j 2 MULTI=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert
> >  scp"
> > 
> > and it should work. I'll make the docs a bit clearer.
> 
> how would you feel about a dbscp alias ?  requiring the name to be "scp" is a 
> bit annoying as it can easily conflict with parallel installs of openssh.
> -mike

While I'm considering build-related issues - would anyone
have a problem if I converted all the #ifdefs related to
options.h into #if statements, to make it easier to override
options on the commandline? Rather than 

#define ENABLE_CLI_PROXYCMD

it'd become 

#ifndef ENABLE_CLI_PROXYCMD
#define ENABLE_CLI_PROXYCMD 1
#end

etc.

Back to the original topic...

I think a dbscp alias is a good idea. The problem with scp
is that running as a server (probably Dropbear's
more common use-case) the scp binary _must_ be called "scp",
since that's how the remote client runs it. "dbscp" as a
client works fine - dbclient now actually has some
orthogonal functionality to OpenSSH client (multihop has
made me use it a lot more), so a different alias might be
useful. I'll keep "scp" as the default program name though
- that Makefile is nasty enough as-is :-\ 

I don't think there's much reason for "dropbear" as "sshd",
since it's usually just used in an init.d or inetd file, and
it is configured differently (via the command line). Most
mail/dns/web server programs have unique names.

I'll add the "dropbearmulti scp" functionality too - I
actually thought it was there already :)

Regarding the "dropbear" vs "db" prefix, I initially had
"dropbearclient" but it was too annoying to type. Perhaps I
should add "dsh" too ;)

Thanks for the suggestions.

Cheers,
Matt

From vapier at gentoo.org  Sat Oct  3 00:37:30 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Fri, 2 Oct 2009 12:37:30 -0400
Subject: scp in dropbearmulti?
In-Reply-To: <20091002130740.GG18879@ucc.gu.uwa.edu.au>
References: <200909301917.56112.rob@landley.net>
	<200910010211.14223.vapier@gentoo.org>
	<20091002130740.GG18879@ucc.gu.uwa.edu.au>
Message-ID: <200910021237.30913.vapier@gentoo.org>

On Friday 02 October 2009 09:07:40 Matt Johnston wrote:
> On Thu, Oct 01, 2009 at 02:11:13AM -0400, Mike Frysinger wrote:
> > On Thursday 01 October 2009 01:37:52 Matt Johnston wrote:
> > > make -j 2 MULTI=1 PROGRAMS="dropbear dbclient dropbearkey
> > > dropbearconvert scp"
> > >
> > > and it should work. I'll make the docs a bit clearer.
> >
> > how would you feel about a dbscp alias ?  requiring the name to be "scp"
> > is a bit annoying as it can easily conflict with parallel installs of
> > openssh.
> 
> While I'm considering build-related issues - would anyone
> have a problem if I converted all the #ifdefs related to
> options.h into #if statements, to make it easier to override
> options on the commandline? Rather than
> 
> #define ENABLE_CLI_PROXYCMD
> 
> it'd become
> 
> #ifndef ENABLE_CLI_PROXYCMD
> #define ENABLE_CLI_PROXYCMD 1
> #end

works for me.  if you wanted to get creative, this would also allow you to 
change some of the #if logic in the source to if ().

#ifdef ENABLE_FOO
	... some stuff ...
#endif

becomes
	if (ENABLE_FOO) {
		... some stuff ...
	}

helps catch latent bugs such as variables undeclared behind certain #if combos 
or typos in rarely used defines.

> I think a dbscp alias is a good idea. The problem with scp
> is that running as a server (probably Dropbear's
> more common use-case) the scp binary _must_ be called "scp",
> since that's how the remote client runs it. "dbscp" as a
> client works fine - dbclient now actually has some
> orthogonal functionality to OpenSSH client (multihop has
> made me use it a lot more), so a different alias might be
> useful.

right, the server part sucks

> I'll keep "scp" as the default program name though
> - that Makefile is nasty enough as-is :-\

OK by me
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20091002/364be01c/attachment.pgp 

From kavita.raghunathan at skyfiber.com  Tue Oct  6 04:49:09 2009
From: kavita.raghunathan at skyfiber.com (Kavita Raghunathan)
Date: Mon, 5 Oct 2009 15:49:09 -0500 (CDT)
Subject: How to integrate dropbear with CLISH?
Message-ID: <1660004357.226601254775749499.JavaMail.root@mail-1.01.com>

Hi, 
I have a cli program running and need to integrate dropbear ssh to take 
input from the cli commands and not from /bin/sh. I have an idea that it 
all needs to be done with compile options and the file cli-runopts.c but 
not sure. can someone give me a few pointers ? Or documentation ? 
Thanks, 
Kavita 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20091005/91ca371b/attachment.htm 

From rob at landley.net  Tue Oct  6 23:28:40 2009
From: rob at landley.net (Rob Landley)
Date: Tue, 6 Oct 2009 10:28:40 -0500
Subject: scp in dropbearmulti?
In-Reply-To: <20091002130740.GG18879@ucc.gu.uwa.edu.au>
References: <200909301917.56112.rob@landley.net>
	<200910010211.14223.vapier@gentoo.org>
	<20091002130740.GG18879@ucc.gu.uwa.edu.au>
Message-ID: <200910061028.40832.rob@landley.net>

On Friday 02 October 2009 08:07:40 Matt Johnston wrote:
> While I'm considering build-related issues - would anyone
> have a problem if I converted all the #ifdefs related to
> options.h into #if statements, to make it easier to override
> options on the commandline?

CFLAGS="-DWALRUS=0" you mean?

> Rather than
>
> #define ENABLE_CLI_PROXYCMD
>
> it'd become
>
> #ifndef ENABLE_CLI_PROXYCMD
> #define ENABLE_CLI_PROXYCMD 1
> #end
>
> etc.

Having them always #defined to 0/1 also means you can use if() in your code 
instead of #ifdef, and let dead code elimination remove the unreachable bits.  
This means everything's always syntax checked the same way no matter your 
config, so you don't get config-dependent build breaks.  (Trick I picked up from 
the linux kernel.)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


From sourav.chakraborty at rebaca.com  Wed Oct  7 20:35:08 2009
From: sourav.chakraborty at rebaca.com (Sourav Chakraborty)
Date: Wed, 7 Oct 2009 18:05:08 +0530
Subject: FTP tunneling query
Message-ID: <034c01ca474a$9e7992c0$0b32a8c0@godavori31>

Hello List,

Does the ssh client send explicit forward requests for the FTP tunneling control as well as the data connections or does the SSH server snoop  the FTP packets and forwards the data channels automatically? 

Rgds
Sourav

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20091007/6c2c201f/attachment.htm 

From matt at ucc.asn.au  Thu Oct  8 00:29:48 2009
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu, 8 Oct 2009 00:29:48 +0800
Subject: FTP tunneling query
In-Reply-To: <034c01ca474a$9e7992c0$0b32a8c0@godavori31>
References: <034c01ca474a$9e7992c0$0b32a8c0@godavori31>
Message-ID: <20091007162948.GB9406@ucc.gu.uwa.edu.au>

Hi,

Dropbear doesn't know anything particular about FTP. I
suspect that forwarding FTP through dropbear (or any other
SSH server) won't work very well, given they dynamic
port allocation. Perhaps OpenSSH client with socks
forwarding might work?

Cheers,
Matt

On Wed, Oct 07, 2009 at 06:05:08PM +0530, Sourav Chakraborty wrote:
> Hello List,
> 
> Does the ssh client send explicit forward requests for the FTP tunneling control as well as the data connections or does the SSH server snoop  the FTP packets and forwards the data channels automatically? 
> 
> Rgds
> Sourav
> 

From matt at ucc.asn.au  Thu Oct  8 00:31:06 2009
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu, 8 Oct 2009 00:31:06 +0800
Subject: How to integrate dropbear with CLISH?
In-Reply-To: <1660004357.226601254775749499.JavaMail.root@mail-1.01.com>
References: <1660004357.226601254775749499.JavaMail.root@mail-1.01.com>
Message-ID: <20091007163106.GC9406@ucc.gu.uwa.edu.au>

Hi,

There isn't anything in options.h, though you could edit
bits of svr-chansession.c to achieve what you want.
Alternatively you could change the shell in /etc/passwd
(depending how the system is set up).

Cheers,
Matt

On Mon, Oct 05, 2009 at 03:49:09PM -0500, Kavita Raghunathan wrote:
> Hi, 
> I have a cli program running and need to integrate dropbear ssh to take 
> input from the cli commands and not from /bin/sh. I have an idea that it 
> all needs to be done with compile options and the file cli-runopts.c but 
> not sure. can someone give me a few pointers ? Or documentation ? 
> Thanks, 
> Kavita 

From rob at landley.net  Fri Oct  9 11:06:18 2009
From: rob at landley.net (Rob Landley)
Date: Thu, 8 Oct 2009 22:06:18 -0500
Subject: FTP tunneling query
In-Reply-To: <20091007162948.GB9406@ucc.gu.uwa.edu.au>
References: <034c01ca474a$9e7992c0$0b32a8c0@godavori31>
	<20091007162948.GB9406@ucc.gu.uwa.edu.au>
Message-ID: <200910082206.19457.rob@landley.net>

On Wednesday 07 October 2009 11:29:48 Matt Johnston wrote:
> Hi,
>
> Dropbear doesn't know anything particular about FTP. I
> suspect that forwarding FTP through dropbear (or any other
> SSH server) won't work very well, given they dynamic
> port allocation. Perhaps OpenSSH client with socks
> forwarding might work?

Actually ftp has a "passive" mode that's often the default these days that 
uses the existing connection rather than dialing back the other way (which was 
an insane design to begin with and gives masquerading routers hives).  When it 
isn't typing "passive" generally enables it.

And there's an sftp program stock in ubuntu, which seems to go through ssh the 
way scp does but I dunno much more about it.  (I just use scp.)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


From rob at landley.net  Fri Oct  9 11:06:18 2009
From: rob at landley.net (Rob Landley)
Date: Thu, 8 Oct 2009 22:06:18 -0500
Subject: FTP tunneling query
In-Reply-To: <20091007162948.GB9406@ucc.gu.uwa.edu.au>
References: <034c01ca474a$9e7992c0$0b32a8c0@godavori31>
	<20091007162948.GB9406@ucc.gu.uwa.edu.au>
Message-ID: <200910082206.19457.rob@landley.net>

On Wednesday 07 October 2009 11:29:48 Matt Johnston wrote:
> Hi,
>
> Dropbear doesn't know anything particular about FTP. I
> suspect that forwarding FTP through dropbear (or any other
> SSH server) won't work very well, given they dynamic
> port allocation. Perhaps OpenSSH client with socks
> forwarding might work?

Actually ftp has a "passive" mode that's often the default these days that 
uses the existing connection rather than dialing back the other way (which was 
an insane design to begin with and gives masquerading routers hives).  When it 
isn't typing "passive" generally enables it.

And there's an sftp program stock in ubuntu, which seems to go through ssh the 
way scp does but I dunno much more about it.  (I just use scp.)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


From matt at ucc.asn.au  Fri Oct  9 11:41:33 2009
From: matt at ucc.asn.au (Matt Johnston)
Date: Fri, 9 Oct 2009 11:41:33 +0800
Subject: FTP tunneling query
In-Reply-To: <200910082206.19457.rob@landley.net>
References: <034c01ca474a$9e7992c0$0b32a8c0@godavori31>
	<20091007162948.GB9406@ucc.gu.uwa.edu.au>
	<200910082206.19457.rob@landley.net>
Message-ID: <20091009034133.GK9406@ucc.gu.uwa.edu.au>

On Thu, Oct 08, 2009 at 10:06:18PM -0500, Rob Landley wrote:
> On Wednesday 07 October 2009 11:29:48 Matt Johnston wrote:
> > Hi,
> >
> > Dropbear doesn't know anything particular about FTP. I
> > suspect that forwarding FTP through dropbear (or any other
> > SSH server) won't work very well, given they dynamic
> > port allocation. Perhaps OpenSSH client with socks
> > forwarding might work?
> 
> Actually ftp has a "passive" mode that's often the default these days that 
> uses the existing connection rather than dialing back the other way (which was 
> an insane design to begin with and gives masquerading routers hives).  When it 
> isn't typing "passive" generally enables it.

I don't think passive mode uses the single port 21
connection - rather it makes a new TCP connection to the
server on a random port? A single SSH port forward won't
cope with that.

Matt

From matt at ucc.asn.au  Fri Oct  9 11:41:33 2009
From: matt at ucc.asn.au (Matt Johnston)
Date: Fri, 9 Oct 2009 11:41:33 +0800
Subject: FTP tunneling query
In-Reply-To: <200910082206.19457.rob@landley.net>
References: <034c01ca474a$9e7992c0$0b32a8c0@godavori31>
	<20091007162948.GB9406@ucc.gu.uwa.edu.au>
	<200910082206.19457.rob@landley.net>
Message-ID: <20091009034133.GK9406@ucc.gu.uwa.edu.au>

On Thu, Oct 08, 2009 at 10:06:18PM -0500, Rob Landley wrote:
> On Wednesday 07 October 2009 11:29:48 Matt Johnston wrote:
> > Hi,
> >
> > Dropbear doesn't know anything particular about FTP. I
> > suspect that forwarding FTP through dropbear (or any other
> > SSH server) won't work very well, given they dynamic
> > port allocation. Perhaps OpenSSH client with socks
> > forwarding might work?
> 
> Actually ftp has a "passive" mode that's often the default these days that 
> uses the existing connection rather than dialing back the other way (which was 
> an insane design to begin with and gives masquerading routers hives).  When it 
> isn't typing "passive" generally enables it.

I don't think passive mode uses the single port 21
connection - rather it makes a new TCP connection to the
server on a random port? A single SSH port forward won't
cope with that.

Matt

From jn at hz6.de  Thu Oct 15 23:17:04 2009
From: jn at hz6.de (Jan Niggemann)
Date: Thu, 15 Oct 2009 17:17:04 +0200
Subject: dropbear logging
Message-ID: <501e9ed58dbea5d70ba379a4f03ac243@localhost>


Hello List,

I'm using dropbear v0.52 (Tomato 1.25 on my router).
I noticed that at some point in the past weeks, it changed its logging
behaviour.
I need your help to sort out what might have caused this.

Before, the logfile read like this while logging in via ssh:
child connection from xx.yy.xx.yy (my IP)
Date Time IP dropbear[3168]: pubkey auth succeeded for 'root' with key md5
aa:bb:cc... from IP:port

Now the line with "child connection" is no longer logged.
Can someone please give me a hint why?
Thank you in advance!

Regards
jan


From Christian.Engelmayer at frequentis.com  Tue Oct 20 19:26:52 2009
From: Christian.Engelmayer at frequentis.com (Engelmayer Christian)
Date: Tue, 20 Oct 2009 13:26:52 +0200
Subject: dropbear - RSA authentication sporadically fails
Message-ID: <9EE81EBECB70824985BE0EDA8DC9B51502845B31@VIECLEX01.frequentis.frq>

Hi,

I have got the problem that a client that periodically connects
to a dropbear server occasionally fails to authenticate as the
size check in buf_rsa_verify() fails (slen is 127 vs. 128 as
calculated from n).

	if (slen != (unsigned int)mp_unsigned_bin_size(key->n)) {
		TRACE(("bad size"))
		goto out;
	}

Removing the check I can see that the user can be authenticated.
After stepping a bit into the topic it seems to me like the following
issue that was solved for OpenSSH. Also this client only faces the
problem when connecting to a dropbear server.

 
<http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/rsa-verify-failed
.html>

At the moment I am not sure whether this check is stricter than
the requirements stated in the RFCs. Any suggestions?

Regards,
Christian



From Christian.Engelmayer at frequentis.com  Tue Oct 27 17:33:05 2009
From: Christian.Engelmayer at frequentis.com (Engelmayer Christian)
Date: Tue, 27 Oct 2009 10:33:05 +0100
Subject: dropbear - RSA authentication sporadically fails
In-Reply-To: <9EE81EBECB70824985BE0EDA8DC9B51502845B31@VIECLEX01.frequentis.frq>
References: <9EE81EBECB70824985BE0EDA8DC9B51502845B31@VIECLEX01.frequentis.frq>
Message-ID: <9EE81EBECB70824985BE0EDA8DC9B51502846698@VIECLEX01.frequentis.frq>

Hi Matt,

It seems to me that the dropbear daemon enforces clients to use
some kind of padding schema for public key authentication. I think
it is obvious why there are detailed standards and all good clients
do that anyway.

I would like to know whether You think it would be a good idea to
also allow older clients that use RSA without padding. As said,
following the ssh RFCs I was missing the requirement that clients
MUST use padding schemes when using RSA.

I don?t want to start a discussion on security best practices, but
just like to know Your opinion whether that could be a topic that
effects more users and should be solved in the daemon as to provide
the same level of interoperability as other ssh implementations.

Regards,
Christian

> -----Original Message-----
> From: dropbear-bounces at ucc.asn.au [mailto:dropbear-bounces at ucc.asn.au] On
Behalf Of Engelmayer Christian
> Sent: Tuesday, October 20, 2009 1:27 PM
> To: dropbear at ucc.asn.au
> Subject: dropbear - RSA authentication sporadically fails
> 
> Hi,
> 
> I have got the problem that a client that periodically connects
> to a dropbear server occasionally fails to authenticate as the
> size check in buf_rsa_verify() fails (slen is 127 vs. 128 as
> calculated from n).
> 
> 	if (slen != (unsigned int)mp_unsigned_bin_size(key->n)) {
> 		TRACE(("bad size"))
> 		goto out;
> 	}
> 
> Removing the check I can see that the user can be authenticated.
> After stepping a bit into the topic it seems to me like the following
> issue that was solved for OpenSSH. Also this client only faces the
> problem when connecting to a dropbear server.
> 
> 
>
<http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/rsa-verify-failed
> .html>
> 
> At the moment I am not sure whether this check is stricter than
> the requirements stated in the RFCs. Any suggestions?
> 
> Regards,
> Christian
> 
> 



From matt at ucc.asn.au  Wed Oct 28 19:50:55 2009
From: matt at ucc.asn.au (Matt Johnston)
Date: Wed, 28 Oct 2009 19:50:55 +0800
Subject: dropbear - RSA authentication sporadically fails
In-Reply-To: <9EE81EBECB70824985BE0EDA8DC9B51502846698@VIECLEX01.frequentis.frq>
References: <9EE81EBECB70824985BE0EDA8DC9B51502845B31@VIECLEX01.frequentis.frq>
	<9EE81EBECB70824985BE0EDA8DC9B51502846698@VIECLEX01.frequentis.frq>
Message-ID: <20091028115055.GZ9406@ucc.gu.uwa.edu.au>

Hi,

I've taken a look at the RFCs (below), and I'm fairly sure
that the behaviour of Dropbear is correct:

 From rfc3447
- k is the length in octets of the RSA modulus n
- If the length of the signature S is not k octets, output
  "invalid signature" and stop.

Regarding interoperability, I'm reluctant to change
Dropbear's behaviour to handle incorrect implementations.
I might make an exception in the case where the broken
client/server is in widespread use, and the changed
behaviour is obvious. 

In terms of allowing short-length signatures, I'm not sure
of the consequences. If someone sends a S value with mostly
0x00 padding at the front, could that be exploited somehow?
(I doubt it, but can't obviously tell, and crypto tends to
be subtle).

Cheers,
Matt

ssh-transport, Page 14
http://www.ietf.org/rfc/rfc4253.txt  

PKCS, section 4.1 specifically says that there should be
zero digit padding. 8.2.2 defines how verification
should work.
http://www.ietf.org/rfc/rfc3447.txt

On Tue, Oct 27, 2009 at 10:33:05AM +0100, Engelmayer Christian wrote:
> Hi Matt,
> 
> It seems to me that the dropbear daemon enforces clients to use
> some kind of padding schema for public key authentication. I think
> it is obvious why there are detailed standards and all good clients
> do that anyway.
> 
> I would like to know whether You think it would be a good idea to
> also allow older clients that use RSA without padding. As said,
> following the ssh RFCs I was missing the requirement that clients
> MUST use padding schemes when using RSA.
> 
> I don?t want to start a discussion on security best practices, but
> just like to know Your opinion whether that could be a topic that
> effects more users and should be solved in the daemon as to provide
> the same level of interoperability as other ssh implementations.
> 
> Regards,
> Christian
> 
> > -----Original Message-----
> > From: dropbear-bounces at ucc.asn.au [mailto:dropbear-bounces at ucc.asn.au] On
> Behalf Of Engelmayer Christian
> > Sent: Tuesday, October 20, 2009 1:27 PM
> > To: dropbear at ucc.asn.au
> > Subject: dropbear - RSA authentication sporadically fails
> > 
> > Hi,
> > 
> > I have got the problem that a client that periodically connects
> > to a dropbear server occasionally fails to authenticate as the
> > size check in buf_rsa_verify() fails (slen is 127 vs. 128 as
> > calculated from n).
> > 
> > 	if (slen != (unsigned int)mp_unsigned_bin_size(key->n)) {
> > 		TRACE(("bad size"))
> > 		goto out;
> > 	}
> > 
> > Removing the check I can see that the user can be authenticated.
> > After stepping a bit into the topic it seems to me like the following
> > issue that was solved for OpenSSH. Also this client only faces the
> > problem when connecting to a dropbear server.
> > 
> > 
> >
> <http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/rsa-verify-failed
> > .html>
> > 
> > At the moment I am not sure whether this check is stricter than
> > the requirements stated in the RFCs. Any suggestions?
> > 
> > Regards,
> > Christian
> > 
> > 
> 
> 

From Christian.Engelmayer at frequentis.com  Wed Oct 28 21:14:16 2009
From: Christian.Engelmayer at frequentis.com (Engelmayer Christian)
Date: Wed, 28 Oct 2009 14:14:16 +0100
Subject: dropbear - RSA authentication sporadically fails
In-Reply-To: <20091028115055.GZ9406@ucc.gu.uwa.edu.au>
References: <9EE81EBECB70824985BE0EDA8DC9B51502845B31@VIECLEX01.frequentis.frq>
	<9EE81EBECB70824985BE0EDA8DC9B51502846698@VIECLEX01.frequentis.frq>
	<20091028115055.GZ9406@ucc.gu.uwa.edu.au>
Message-ID: <9EE81EBECB70824985BE0EDA8DC9B515028BC46D@VIECLEX01.frequentis.frq>

Hi,

Thanks for the clarification!

> I'm fairly sure that the behaviour of Dropbear is correct

I tend to agree. Your response pointed me to the piece of information
on the "ssh-rsa" key format in RFC 4253 that I was missing before:

   Signing and verifying using this key format is performed according to
   the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash.

Regards,
Christian

> -----Original Message-----
> From: Matt Johnston [mailto:matt at ucc.asn.au]
> Sent: Wednesday, October 28, 2009 12:51 PM
> To: Engelmayer Christian
> Cc: dropbear at ucc.asn.au
> Subject: Re: dropbear - RSA authentication sporadically fails
> 
> Hi,
> 
> I've taken a look at the RFCs (below), and I'm fairly sure
> that the behaviour of Dropbear is correct:
> 
>  From rfc3447
> - k is the length in octets of the RSA modulus n
> - If the length of the signature S is not k octets, output
>   "invalid signature" and stop.
> 
> Regarding interoperability, I'm reluctant to change
> Dropbear's behaviour to handle incorrect implementations.
> I might make an exception in the case where the broken
> client/server is in widespread use, and the changed
> behaviour is obvious.
> 
> In terms of allowing short-length signatures, I'm not sure
> of the consequences. If someone sends a S value with mostly
> 0x00 padding at the front, could that be exploited somehow?
> (I doubt it, but can't obviously tell, and crypto tends to
> be subtle).
> 
> Cheers,
> Matt
> 
> ssh-transport, Page 14
> http://www.ietf.org/rfc/rfc4253.txt
> 
> PKCS, section 4.1 specifically says that there should be
> zero digit padding. 8.2.2 defines how verification
> should work.
> http://www.ietf.org/rfc/rfc3447.txt
> 
> On Tue, Oct 27, 2009 at 10:33:05AM +0100, Engelmayer Christian wrote:
> > Hi Matt,
> >
> > It seems to me that the dropbear daemon enforces clients to use
> > some kind of padding schema for public key authentication. I think
> > it is obvious why there are detailed standards and all good clients
> > do that anyway.
> >
> > I would like to know whether You think it would be a good idea to
> > also allow older clients that use RSA without padding. As said,
> > following the ssh RFCs I was missing the requirement that clients
> > MUST use padding schemes when using RSA.
> >
> > I don?t want to start a discussion on security best practices, but
> > just like to know Your opinion whether that could be a topic that
> > effects more users and should be solved in the daemon as to provide
> > the same level of interoperability as other ssh implementations.
> >
> > Regards,
> > Christian
> >
> > > -----Original Message-----
> > > From: dropbear-bounces at ucc.asn.au [mailto:dropbear-bounces at ucc.asn.au]
On
> > Behalf Of Engelmayer Christian
> > > Sent: Tuesday, October 20, 2009 1:27 PM
> > > To: dropbear at ucc.asn.au
> > > Subject: dropbear - RSA authentication sporadically fails
> > >
> > > Hi,
> > >
> > > I have got the problem that a client that periodically connects
> > > to a dropbear server occasionally fails to authenticate as the
> > > size check in buf_rsa_verify() fails (slen is 127 vs. 128 as
> > > calculated from n).
> > >
> > > 	if (slen != (unsigned int)mp_unsigned_bin_size(key->n)) {
> > > 		TRACE(("bad size"))
> > > 		goto out;
> > > 	}
> > >
> > > Removing the check I can see that the user can be authenticated.
> > > After stepping a bit into the topic it seems to me like the following
> > > issue that was solved for OpenSSH. Also this client only faces the
> > > problem when connecting to a dropbear server.
> > >
> > >
> > >
> >
<http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/rsa-verify-failed
> > > .html>
> > >
> > > At the moment I am not sure whether this check is stricter than
> > > the requirements stated in the RFCs. Any suggestions?
> > >
> > > Regards,
> > > Christian
> > >
> > >
> >
> >


From rob at landley.net  Wed Nov 18 12:48:02 2009
From: rob at landley.net (Rob Landley)
Date: Tue, 17 Nov 2009 22:48:02 -0600
Subject: ./configure --disable-zlib
Message-ID: <200911172248.03155.rob@landley.net>

Why does ./configure die on a system that hasn't got zlib installed unless you 
tell it --disable-zlib?

Isn't the point of configure to find out what you have and haven't got on your 
system, and build accordingly?

Confused,

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

From matt at ucc.asn.au  Wed Nov 18 22:03:49 2009
From: matt at ucc.asn.au (Matt Johnston)
Date: Wed, 18 Nov 2009 22:03:49 +0800
Subject: ./configure --disable-zlib
In-Reply-To: <200911172248.03155.rob@landley.net>
References: <200911172248.03155.rob@landley.net>
Message-ID: <20091118140349.GM14157@ucc.gu.uwa.edu.au>

On Tue, Nov 17, 2009 at 10:48:02PM -0600, Rob Landley wrote:
> Why does ./configure die on a system that hasn't got zlib installed unless you 
> tell it --disable-zlib?
> 
> Isn't the point of configure to find out what you have and haven't got on your 
> system, and build accordingly?

In general missing zlib support will result in noticably
slower interactive SSH session (at least over remote links).
Since it's an easy thing to miss I prefer needing it to be
explicitly disabled. I guess an alternative would be to
print a clearer list of which options are selected after
configure finishes.

Cheers,
Matt

From lj at linjian.org  Tue Nov 24 08:56:06 2009
From: lj at linjian.org (Jian Lin)
Date: Tue, 24 Nov 2009 08:56:06 +0800
Subject: To support PAM better
In-Reply-To: <119341710910220739qff9ed6eq3e46d4dbda2a24ff@mail.gmail.com>
References: <119341710910220739qff9ed6eq3e46d4dbda2a24ff@mail.gmail.com>
Message-ID: <119341710911231656w7dd9e54cw1d5f24268af9ddad@mail.gmail.com>

I am using Dropbear with PAM authentication. I found something may be bugs or
unkind features:

1. Line 119, svr-authpam.c (pamConvFunc), m_burn was called to destroy saved
password for security after each PAM conversation. However, there might be
more than one conversations in a PAM configuration for a certain program,
such as pam_unix.so, pam_ldap.so, ... If the password was destroyed in the
first conversation, the following conversations will get 'ffff...' and failed.
So I think this m_burn calling should be deleted. The password should be
destroyed only once after pam_authenticate.

2. I use my own NSS and PAM modules for user mapping in my environment. An
app_user and an app_password are sent to sshd, then sshd calls getpwnam (which
calls my own NSS modules) to return a struct_passwd including a local_user.
This routine works well with OpenSSHd and some similar programs (login, vsftpd,
and gdm). However, it doesn't work with dropbear server. I found the reason:
Dropbear saves the user name returned by getpwnam (of my own NSS) in
ses.authstate.pw_name. It calls pam_start with this user name (local_user) but
not the original input one (app_user). So the pair of "local_user + app_user"
will certainly reject by my own PAM. It is not a bug, but I think this is an
incompatible feature with OpenSSHd, login, vsftpd, and gdm.

In order to fit my application, I patched Dropbear as follows. Maybe these are
useful for PAM developers.


linjian at goslin:~/dev/dropbear-0.52$ cat options.h.diff
152c152
< #define ENABLE_SVR_PASSWORD_AUTH
---
> /*#define ENABLE_SVR_PASSWORD_AUTH*/
154c154
< /*#define ENABLE_SVR_PAM_AUTH*/
---
> #define ENABLE_SVR_PAM_AUTH


linjian at goslin:~/dev/dropbear-0.52$ cat svr-auth.c.diff
36a37,38
> char client_login_username[256];
>
142a145,146
> ? ? ? strncpy(client_login_username, username, 256);
>


linjian at goslin:~/dev/dropbear-0.52$ cat svr-authpam.c.diff
41a42,43
> extern char client_login_username[256];
>
101c103
< ? ? ? ? ? ? ? ? ? ? ? if (!(strcmp(compare_message, "password:") == 0)) {
---
> ? ? ? ? ? ? ? ? ? ? ? if (/*!(strcmp(compare_message, "password:") == 0)*/ 0) {
119c121
< ? ? ? ? ? ? ? ? ? ? ? m_burn(userDatap->passwd, strlen(userDatap->passwd));
---
> ? ? ? ? ? ? ? ? ? ? ? /*m_burn(userDatap->passwd, strlen(userDatap->passwd));*/
198c200
< ? ? ? userData.user = ses.authstate.pw_name;
---
> ? ? ? userData.user = m_strdup(client_login_username);
247a250,252
> ? ? ? if (userData.user != NULL) {
> ? ? ? ? ? ? ? m_free(userData.user);
> ? ? ? }


Jian LIN

From antony at pavlenko.net  Sun Dec  6 01:18:11 2009
From: antony at pavlenko.net (Antony Pavlenko)
Date: Sat, 5 Dec 2009 20:18:11 +0300
Subject: DROPBEAR_PASSWORD and password expiration
Message-ID: <20091205171811.GB15465@amaliya>

Hello.
There is rather unpleasant dbclient behavior when DROPBEAR_PASSWORD is used.
Everything works great until password expiration is used.
Then password is expired and you try to login wuth dbclient with DROPBEAR_PASSWORD than dbclient will change password to ffff . And there will be as much 'f' symbols in new password as DROPBEAR_PASSWORD length.

It works so because in recv_msg_userauth_info_request you call getpass_or_cancel and if DROPBEAR_PASSWORD is used it returns a pointer to the DROPBEAR_PASSWORD environment variable. And then you use m_burn to clear password value from the memory.

here is the code :

unsigned char* p = getpass_or_cancel(prompt);
response = m_strdup(p);
m_burn(p, strlen(p));

But if this pass is correct and expired than host will ask dbclient to enter new one pass. dbclient will take DROPBEAR_PASSWORD again but now there is another pass, which was written by m_burn.

I like very much DROPBEAR_PASSWORD feature and that dbclient can change expired password. Also it is great that nobody can dump password from environment variable.

I don't know the best way to fix it and doesn't break this great
feature. I can't say that I really understand dropbear code, but may be move m_burn for environment variable to the end of  recv_msg_userauth_specific_60, or any other place where authorization is really finished?

With regards,
-- 
Anton Pavlenko


From matt at ucc.asn.au  Tue Dec  8 07:34:33 2009
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue, 8 Dec 2009 07:34:33 +0800
Subject: DROPBEAR_PASSWORD and password expiration
In-Reply-To: <20091205171811.GB15465@amaliya>
References: <20091205171811.GB15465@amaliya>
Message-ID: <20091207233433.GB4138@ucc.gu.uwa.edu.au>

Hi Anton,

It certainly is wrong for it to be calling m_burn on the
DROPBEAR_PASSWORD environment variable, I'll fix that. I'm
not totally sure what the correct behaviour for "change
password" or other similar auth prompts is - perhaps
DROPBEAR_PASSWORD should only be used for the first
"no-echo" response.

In keyboard interactive mode dbclient just gets given a
series of "ask the user this question, with echo off/on"
prompts from the server - it doesn't really know if it's
being asked for the current password, a new password, or
something totally different (like a token ID etc).

Cheers,
Matt

On Sat, Dec 05, 2009 at 08:18:11PM +0300, Antony Pavlenko wrote:
> Hello.
> There is rather unpleasant dbclient behavior when DROPBEAR_PASSWORD is used.
> Everything works great until password expiration is used.
> Then password is expired and you try to login wuth dbclient with DROPBEAR_PASSWORD than dbclient will change password to ffff . And there will be as much 'f' symbols in new password as DROPBEAR_PASSWORD length.
> 
> It works so because in recv_msg_userauth_info_request you call getpass_or_cancel and if DROPBEAR_PASSWORD is used it returns a pointer to the DROPBEAR_PASSWORD environment variable. And then you use m_burn to clear password value from the memory.
> 
> here is the code :
> 
> unsigned char* p = getpass_or_cancel(prompt);
> response = m_strdup(p);
> m_burn(p, strlen(p));
> 
> But if this pass is correct and expired than host will ask dbclient to enter new one pass. dbclient will take DROPBEAR_PASSWORD again but now there is another pass, which was written by m_burn.
> 
> I like very much DROPBEAR_PASSWORD feature and that dbclient can change expired password. Also it is great that nobody can dump password from environment variable.
> 
> I don't know the best way to fix it and doesn't break this great
> feature. I can't say that I really understand dropbear code, but may be move m_burn for environment variable to the end of  recv_msg_userauth_specific_60, or any other place where authorization is really finished?
> 
> With regards,
> -- 
> Anton Pavlenko
> 

From roytam at gmail.com  Tue Dec  8 13:59:53 2009
From: roytam at gmail.com (Roy Tam)
Date: Tue, 8 Dec 2009 13:59:53 +0800
Subject: SFTP Server
Message-ID: <473191350912072159o7f437c06j11fcabc8bab39c3b@mail.gmail.com>

Hi all,

Besides OpenSSH sftp server, I found that Green End SFTP Server works
with dropbear too. (Python requirement is for test only which can be
safely removed from configure.ac)
http://www.greenend.org.uk/rjk/sftpserver/

Best regards,
Roy

From antony at pavlenko.net  Tue Dec  8 15:35:12 2009
From: antony at pavlenko.net (Antony Pavlenko)
Date: Tue, 8 Dec 2009 10:35:12 +0300
Subject: DROPBEAR_PASSWORD and password expiration
In-Reply-To: <20091207233433.GB4138@ucc.gu.uwa.edu.au>
References: <20091205171811.GB15465@amaliya>
	<20091207233433.GB4138@ucc.gu.uwa.edu.au>
Message-ID: <b5ae18400912072335u710c1ecu1b7c59faf150eccf@mail.gmail.com>

Hello.
First of all thanks a lot for your great ssh client/server!
As for me, it isn't really "totally wrong" to call m_burn on the
DROPBEAR_PASSWORD. It is really useful feature because when ssh session
already established nobody can find correct password at /proc/pid/ environ (
Linux ) or pargs -e ( Solaris ).
So it will be great not just remove m_burn for DROPBEAR_PASSWORD but just
move to any place, after authorization.

With regards,
Anton Pavlenko

On Tue, Dec 8, 2009 at 2:34 AM, Matt Johnston <matt at ucc.asn.au> wrote:

> Hi Anton,
>
> It certainly is wrong for it to be calling m_burn on the
> DROPBEAR_PASSWORD environment variable, I'll fix that. I'm
> not totally sure what the correct behaviour for "change
> password" or other similar auth prompts is - perhaps
> DROPBEAR_PASSWORD should only be used for the first
> "no-echo" response.
>
> In keyboard interactive mode dbclient just gets given a
> series of "ask the user this question, with echo off/on"
> prompts from the server - it doesn't really know if it's
> being asked for the current password, a new password, or
> something totally different (like a token ID etc).
>
> Cheers,
> Matt
>
> On Sat, Dec 05, 2009 at 08:18:11PM +0300, Antony Pavlenko wrote:
> > Hello.
> > There is rather unpleasant dbclient behavior when DROPBEAR_PASSWORD is
> used.
> > Everything works great until password expiration is used.
> > Then password is expired and you try to login wuth dbclient with
> DROPBEAR_PASSWORD than dbclient will change password to ffff . And there
> will be as much 'f' symbols in new password as DROPBEAR_PASSWORD length.
> >
> > It works so because in recv_msg_userauth_info_request you call
> getpass_or_cancel and if DROPBEAR_PASSWORD is used it returns a pointer to
> the DROPBEAR_PASSWORD environment variable. And then you use m_burn to clear
> password value from the memory.
> >
> > here is the code :
> >
> > unsigned char* p = getpass_or_cancel(prompt);
> > response = m_strdup(p);
> > m_burn(p, strlen(p));
> >
> > But if this pass is correct and expired than host will ask dbclient to
> enter new one pass. dbclient will take DROPBEAR_PASSWORD again but now there
> is another pass, which was written by m_burn.
> >
> > I like very much DROPBEAR_PASSWORD feature and that dbclient can change
> expired password. Also it is great that nobody can dump password from
> environment variable.
> >
> > I don't know the best way to fix it and doesn't break this great
> > feature. I can't say that I really understand dropbear code, but may be
> move m_burn for environment variable to the end of
>  recv_msg_userauth_specific_60, or any other place where authorization is
> really finished?
> >
> > With regards,
> > --
> > Anton Pavlenko
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20091208/7b3ef302/attachment.html 

From aanantha at riverbed.com  Wed Dec  9 07:47:02 2009
From: aanantha at riverbed.com (Ahilan Anantha)
Date: Tue, 8 Dec 2009 15:47:02 -0800
Subject: dbclient and detecting broken connections
Message-ID: <4B1EE576.2030406@riverbed.com>

Hi List,

I plan to use "dbclient" as a low memory footprint alternative to 
OpenSSH's "ssh" for SSH tunnels.

On the client I have software that creates SSH tunnels to many systems. 
Sometimes the connection to these remote systems will break, at which 
point "ssh" will exit. The exit gets detected and the connection gets 
reestablished. But this works in "ssh" because I'm using the 
ServerAliveInterval and ServerAliveCountMax options. Without them, ssh 
would never check that the connection was up and I'd have to wait an 
eternity for a TCP timeout. Or implement my own heartbeat on top of the 
tunnel.

dbclient instead has a "-K" option. It's been suggested on this mailing 
list that this basically did the same thing... but based on my testing 
that doesn't appear to be true. At least for the case of dbclient 
against an OpenSSH server.

I ran "dbclient -K 3" against an OpenSSH server. Then I sent a SIGSTOP 
to the sshd child process servicing the connection. dbclient did not 
terminate the session within any reasonable amount of time. Perhaps if I 
waited a really long time, I would see a TCP timeout.

When I try the same with an "ssh -oServerAliveInterval=3 
-oServerAliveCountMax=1", the ssh client disconnects very quickly:

"Disconnecting: Timeout, server not responding."

After comparing the OpenSSH and dropbear source code, it appears to me 
that dropbear implements the equivalent of OpenSSH's "TCP keep alive" 
but not "server alive".

In the case of "server alive", OpenSSH requires a response from the 
server. Each server alive interval it checks to see how many server 
alive requests are outstanding. If that count exceeds the max (default 
is 3), it terminates the connection. In the case of "TCP keep alive", 
ssh sends a message with no response requested. In this case, it's just 
trying to maintain some activity over the stream so that intermediate 
firewalls don't kill it as an idle connection.

Is this a known issue? Has anyone else asked for this?

Regards,

Ahilan

From fja0568 at gmail.com  Wed Dec  9 13:36:36 2009
From: fja0568 at gmail.com (Farrell Aultman)
Date: Wed, 9 Dec 2009 00:36:36 -0500
Subject: dbclient and detecting broken connections
In-Reply-To: <4B1EE576.2030406@riverbed.com>
References: <4B1EE576.2030406@riverbed.com>
Message-ID: <3ba466150912082136w145524f3y5a86dc209412ea5b@mail.gmail.com>

Hello Ahilan,

Look at the Idletimeout option, "-I".  Try to run "-I" on the client.  To
the best of my remembrance, you are correct, -K only sends keep alive
messages and doesn't actually check for any response.  Some type of keep
alive will have to be sent from the server side for this to work.  I don't
recall if there is a response to -K (when sending keep alives from the
client), so you may have to send keep alives from the server to the clients.

What I do is run -I on the server and -K on the clients to detect when
clients have went down and shut down the server process, which causes the
client to die.  But if my server process died, I'd be screwed too.

Farrell

On Tue, Dec 8, 2009 at 6:47 PM, Ahilan Anantha <aanantha at riverbed.com>wrote:

> Hi List,
>
> I plan to use "dbclient" as a low memory footprint alternative to OpenSSH's
> "ssh" for SSH tunnels.
>
> On the client I have software that creates SSH tunnels to many systems.
> Sometimes the connection to these remote systems will break, at which point
> "ssh" will exit. The exit gets detected and the connection gets
> reestablished. But this works in "ssh" because I'm using the
> ServerAliveInterval and ServerAliveCountMax options. Without them, ssh would
> never check that the connection was up and I'd have to wait an eternity for
> a TCP timeout. Or implement my own heartbeat on top of the tunnel.
>
> dbclient instead has a "-K" option. It's been suggested on this mailing
> list that this basically did the same thing... but based on my testing that
> doesn't appear to be true. At least for the case of dbclient against an
> OpenSSH server.
>
> I ran "dbclient -K 3" against an OpenSSH server. Then I sent a SIGSTOP to
> the sshd child process servicing the connection. dbclient did not terminate
> the session within any reasonable amount of time. Perhaps if I waited a
> really long time, I would see a TCP timeout.
>
> When I try the same with an "ssh -oServerAliveInterval=3
> -oServerAliveCountMax=1", the ssh client disconnects very quickly:
>
> "Disconnecting: Timeout, server not responding."
>
> After comparing the OpenSSH and dropbear source code, it appears to me that
> dropbear implements the equivalent of OpenSSH's "TCP keep alive" but not
> "server alive".
>
> In the case of "server alive", OpenSSH requires a response from the server.
> Each server alive interval it checks to see how many server alive requests
> are outstanding. If that count exceeds the max (default is 3), it terminates
> the connection. In the case of "TCP keep alive", ssh sends a message with no
> response requested. In this case, it's just trying to maintain some activity
> over the stream so that intermediate firewalls don't kill it as an idle
> connection.
>
> Is this a known issue? Has anyone else asked for this?
>
> Regards,
>
> Ahilan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20091209/744c58a1/attachment.html 

From matt at ucc.asn.au  Wed Dec  9 20:39:13 2009
From: matt at ucc.asn.au (Matt Johnston)
Date: Wed, 9 Dec 2009 20:39:13 +0800
Subject: dbclient and detecting broken connections
In-Reply-To: <4B1EE576.2030406@riverbed.com>
References: <4B1EE576.2030406@riverbed.com>
Message-ID: <20091209123913.GJ4138@ucc.gu.uwa.edu.au>

On Tue, Dec 08, 2009 at 03:47:02PM -0800, Ahilan Anantha wrote:
> Hi List,
>
> I plan to use "dbclient" as a low memory footprint alternative to  
> OpenSSH's "ssh" for SSH tunnels.
>
> On the client I have software that creates SSH tunnels to many systems.  
> Sometimes the connection to these remote systems will break, at which  
> point "ssh" will exit. The exit gets detected and the connection gets  
> reestablished. But this works in "ssh" because I'm using the  
> ServerAliveInterval and ServerAliveCountMax options. Without them, ssh  
> would never check that the connection was up and I'd have to wait an  
> eternity for a TCP timeout. Or implement my own heartbeat on top of the  
> tunnel.

dbclient sends an "ignore" packet every N seconds, but I
don't think that elicits a server response. It will
generally time out after a minute or so when the client OS
gives up on receiving an ACK, though SIGSTOP is a funny
case since the remote OS is probably still sending TCP ACKs.
I'll take a look at implementing something closer to what
ServerAliveInterval does (sending something that will fail
and checking for a reply, iirc).

OpenSSH's "tcpkeepalive" just sets the TCP keepalive option
on the socket with setsockopt(), but won't probe the
connection itself.

Cheers,
Matt

From jean.eckard at gmail.com  Thu Dec 10 00:00:53 2009
From: jean.eckard at gmail.com (Jean Eckard)
Date: Wed, 9 Dec 2009 17:00:53 +0100
Subject: NAS $PATH problem
Message-ID: <525ad49d0912090800y7efd2ef3t426543c21798ff68@mail.gmail.com>

Hi!
Everytime I boot up my NAS, /root/.profile and the "all users"
equivalent reset, which mean all my personnal commands and more
important the Optware binaries are not accessible unless I type in the
full path or add the optware/bin path to $PATH.
Is there a way to avoid this odd and annoying behaviour?


From aanantha at riverbed.com  Thu Dec 10 02:28:52 2009
From: aanantha at riverbed.com (Ahilan Anantha)
Date: Wed, 9 Dec 2009 10:28:52 -0800
Subject: dbclient and detecting broken connections
In-Reply-To: <3ba466150912082136w145524f3y5a86dc209412ea5b@mail.gmail.com>
References: <4B1EE576.2030406@riverbed.com>
	<3ba466150912082136w145524f3y5a86dc209412ea5b@mail.gmail.com>
Message-ID: <4B1FEC64.2020708@riverbed.com>

Hi Farrell,

That's an interesting idea. But like you said, if the server suddenly 
disappears off the network then the client won't be told to die if we do 
idle timeouts and/or keep alives. The server alive in OpenSSH is 
request/response so it ensures that the client can figure out the 
connection is hozed even if the server is frozen. Fortunately it doesn't 
look too hard to port over support from OpenSSH. I should hopefully have 
a messy patch today that I can tidy up.

Thanks,

Ahilan

Farrell Aultman wrote:
> Hello Ahilan,
> 
> Look at the Idletimeout option, "-I".  Try to run "-I" on the client.  
> To the best of my remembrance, you are correct, -K only sends keep alive 
> messages and doesn't actually check for any response.  Some type of keep 
> alive will have to be sent from the server side for this to work.  I 
> don't recall if there is a response to -K (when sending keep alives from 
> the client), so you may have to send keep alives from the server to the 
> clients.
> 
> What I do is run -I on the server and -K on the clients to detect when 
> clients have went down and shut down the server process, which causes 
> the client to die.  But if my server process died, I'd be screwed too.
> 
> Farrell 
> 
> On Tue, Dec 8, 2009 at 6:47 PM, Ahilan Anantha <aanantha at riverbed.com 
> <mailto:aanantha at riverbed.com>> wrote:
> 
>     Hi List,
> 
>     I plan to use "dbclient" as a low memory footprint alternative to
>     OpenSSH's "ssh" for SSH tunnels.
> 
>     On the client I have software that creates SSH tunnels to many
>     systems. Sometimes the connection to these remote systems will
>     break, at which point "ssh" will exit. The exit gets detected and
>     the connection gets reestablished. But this works in "ssh" because
>     I'm using the ServerAliveInterval and ServerAliveCountMax options.
>     Without them, ssh would never check that the connection was up and
>     I'd have to wait an eternity for a TCP timeout. Or implement my own
>     heartbeat on top of the tunnel.
> 
>     dbclient instead has a "-K" option. It's been suggested on this
>     mailing list that this basically did the same thing... but based on
>     my testing that doesn't appear to be true. At least for the case of
>     dbclient against an OpenSSH server.
> 
>     I ran "dbclient -K 3" against an OpenSSH server. Then I sent a
>     SIGSTOP to the sshd child process servicing the connection. dbclient
>     did not terminate the session within any reasonable amount of time.
>     Perhaps if I waited a really long time, I would see a TCP timeout.
> 
>     When I try the same with an "ssh -oServerAliveInterval=3
>     -oServerAliveCountMax=1", the ssh client disconnects very quickly:
> 
>     "Disconnecting: Timeout, server not responding."
> 
>     After comparing the OpenSSH and dropbear source code, it appears to
>     me that dropbear implements the equivalent of OpenSSH's "TCP keep
>     alive" but not "server alive".
> 
>     In the case of "server alive", OpenSSH requires a response from the
>     server. Each server alive interval it checks to see how many server
>     alive requests are outstanding. If that count exceeds the max
>     (default is 3), it terminates the connection. In the case of "TCP
>     keep alive", ssh sends a message with no response requested. In this
>     case, it's just trying to maintain some activity over the stream so
>     that intermediate firewalls don't kill it as an idle connection.
> 
>     Is this a known issue? Has anyone else asked for this?
> 
>     Regards,
> 
>     Ahilan
> 
> 

From aanantha at riverbed.com  Thu Dec 10 04:26:40 2009
From: aanantha at riverbed.com (Ahilan Anantha)
Date: Wed, 9 Dec 2009 12:26:40 -0800
Subject: dbclient and detecting broken connections
In-Reply-To: <20091209123913.GJ4138@ucc.gu.uwa.edu.au>
References: <4B1EE576.2030406@riverbed.com>
	<20091209123913.GJ4138@ucc.gu.uwa.edu.au>
Message-ID: <4B200800.3050404@riverbed.com>

Matt Johnston wrote:
> On Tue, Dec 08, 2009 at 03:47:02PM -0800, Ahilan Anantha wrote:
>> Hi List,
>>
>> I plan to use "dbclient" as a low memory footprint alternative to  
>> OpenSSH's "ssh" for SSH tunnels.
>>
>> On the client I have software that creates SSH tunnels to many systems.  
>> Sometimes the connection to these remote systems will break, at which  
>> point "ssh" will exit. The exit gets detected and the connection gets  
>> reestablished. But this works in "ssh" because I'm using the  
>> ServerAliveInterval and ServerAliveCountMax options. Without them, ssh  
>> would never check that the connection was up and I'd have to wait an  
>> eternity for a TCP timeout. Or implement my own heartbeat on top of the  
>> tunnel.
> 
> dbclient sends an "ignore" packet every N seconds, but I
> don't think that elicits a server response. It will
> generally time out after a minute or so when the client OS
> gives up on receiving an ACK, though SIGSTOP is a funny
> case since the remote OS is probably still sending TCP ACKs.
> I'll take a look at implementing something closer to what
> ServerAliveInterval does (sending something that will fail
> and checking for a reply, iirc).
> 
> OpenSSH's "tcpkeepalive" just sets the TCP keepalive option
> on the socket with setsockopt(), but won't probe the
> connection itself.
> 
> Cheers,
> Matt
> 

Thanks, Matt.

OpenSSH's client is sending an "SSH2_MSG_GLOBAL_REQUEST" with a bogus 
request type of "keepalive at openssh.com" with want reply set to 1. And on 
the server side it doesn't try to match that name and just always sends 
an "SSH2_MSG_REQUEST_FAILURE" when it gets that message.

And then every time the client gets an SSH2_MSG_REQUEST_SUCCESS or 
SSH2_MSG_REQUEST_FAILURE it sets the number of outstanding server alives 
to 0.

Regards,

Ahilan

From vapier at gentoo.org  Thu Dec 10 07:06:11 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 9 Dec 2009 18:06:11 -0500
Subject: NAS $PATH problem
In-Reply-To: <525ad49d0912090800y7efd2ef3t426543c21798ff68@mail.gmail.com>
References: <525ad49d0912090800y7efd2ef3t426543c21798ff68@mail.gmail.com>
Message-ID: <200912091806.11810.vapier@gentoo.org>

On Wednesday 09 December 2009 11:00:53 Jean Eckard wrote:
> Everytime I boot up my NAS, /root/.profile and the "all users"
> equivalent reset, which mean all my personnal commands and more
> important the Optware binaries are not accessible unless I type in the
> full path or add the optware/bin path to $PATH.
> Is there a way to avoid this odd and annoying behaviour?

i dont see how this is a dropbear issue ?  perhaps you meant to e-mail an list 
specific to your NAS (or the distro it's using)  or a general embedded linux 
list.  dropbear is an ssh package only.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20091209/208b03c9/attachment.pgp 

From rob at landley.net  Thu Dec 10 10:35:48 2009
From: rob at landley.net (Rob Landley)
Date: Wed, 9 Dec 2009 20:35:48 -0600
Subject: NAS $PATH problem
In-Reply-To: <200912091806.11810.vapier@gentoo.org>
References: <525ad49d0912090800y7efd2ef3t426543c21798ff68@mail.gmail.com>
	<200912091806.11810.vapier@gentoo.org>
Message-ID: <200912092035.49390.rob@landley.net>

On Wednesday 09 December 2009 17:06:11 Mike Frysinger wrote:
> On Wednesday 09 December 2009 11:00:53 Jean Eckard wrote:
> > Everytime I boot up my NAS, /root/.profile and the "all users"
> > equivalent reset, which mean all my personnal commands and more
> > important the Optware binaries are not accessible unless I type in the
> > full path or add the optware/bin path to $PATH.
> > Is there a way to avoid this odd and annoying behaviour?
>
> i dont see how this is a dropbear issue ?  perhaps you meant to e-mail an
> list specific to your NAS (or the distro it's using)  or a general embedded
> linux list.  dropbear is an ssh package only.
> -mike

Or, if you'd like a useful answer, add a line like:

export PATH=/bin:/usr/bin:/sbin:/usr/sbin:/path/to/more/stuff:$PATH

to the file "/etc/profile".  For more info on this, look at the bash man page 
(which is a whole book disguised as a man page, but reading it should teach 
you a bunch if you have a spare weekend to do so).

Email me if you have more questions,

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

From roytam at gmail.com  Mon Dec 21 13:39:18 2009
From: roytam at gmail.com (Roy Tam)
Date: Mon, 21 Dec 2009 13:39:18 +0800
Subject: SFTP Server
In-Reply-To: <473191350912072159o7f437c06j11fcabc8bab39c3b@mail.gmail.com>
References: <473191350912072159o7f437c06j11fcabc8bab39c3b@mail.gmail.com>
Message-ID: <473191350912202139qde123eap9ebd6bae2add050a@mail.gmail.com>

Hi all,

For this standalone SFTP server, there's a glitch that makes it
allocates ~32MB virtual memory, the patch below fix this glitch.

--- queue.c.old	2009-12-21 13:17:19.000000000 +0800
+++ queue.c	2009-12-21 13:19:34.000000000 +0800
@@ -75,29 +75,32 @@
   return 0;
 }

 void queue_init(struct queue **qr,
 		const struct queuedetails *details,
 		int nthreads) {
   int n;
   struct queue *q;
+  pthread_attr_t attr;

   q = xmalloc(sizeof *q);
   memset(q, 0, sizeof *q);
   q->jobs = 0;
   q->jobstail = &q->jobs;
   ferrcheck(pthread_mutex_init(&q->m, 0));
   ferrcheck(pthread_cond_init(&q->c, 0));
   q->details = details;
   q->nthreads = nthreads;
   q->threads = xcalloc(nthreads, sizeof (pthread_t));
   q->join = 0;
+  pthread_attr_init(&attr);
+  pthread_attr_setstacksize(&attr,128*1024);
   for(n = 0; n < q->nthreads; ++n)
-    ferrcheck(pthread_create(&q->threads[n], 0, queue_thread, q));
+    ferrcheck(pthread_create(&q->threads[n], &attr, queue_thread, q));
   *qr = q;
 }

 void queue_add(struct queue *q, void *job) {
   struct queuejob *qj;

   qj = xmalloc(sizeof *qj);
   qj->next = 0;


2009/12/8 Roy Tam <roytam at gmail.com>:
> Hi all,
>
> Besides OpenSSH sftp server, I found that Green End SFTP Server works
> with dropbear too. (Python requirement is for test only which can be
> safely removed from configure.ac)
> http://www.greenend.org.uk/rjk/sftpserver/
>
> Best regards,
> Roy
>