From g+dropbear at cobb.uk.net  Sat Oct  1 05:38:14 2011
From: g+dropbear at cobb.uk.net (Graham Cobb)
Date: Fri, 30 Sep 2011 22:38:14 +0100
Subject: Interop problem with old dropbear and new openssh
Message-ID: <201109302238.15465.g+dropbear@cobb.uk.net>

Hi,

I have a router running an old version of OpenWRT with an old version of 
dropbear (Dropbear sshd v0.44test3).  It has been working for many years and I 
ssh in from my desktop systems (running Debian Testing) with no problem.

However, recently I upgraded one of my desktops and I can no longer connect to 
the router.  Dropbear on the router is exiting with:

exit before auth: bad buf_getwriteptr

The desktop is running "SSH-2.0-OpenSSH_5.9p1 Debian-1" (it failed with 5.8 as 
well).  However, another desktop still running "SSH-2.0-OpenSSH_5.5p1 
Debian-6" still works fine.  The config files are identical.

I realise this is a very old version of dropbear and that you are not 
responsible for changes in OpenSSH but I thought I would ask here in case 
anyone else has seen this and can maybe suggest a config change to workround 
the problem!

Graham

From rob at landley.net  Sun Oct  2 02:58:30 2011
From: rob at landley.net (Rob Landley)
Date: Sat, 01 Oct 2011 13:58:30 -0500
Subject: Interop problem with old dropbear and new openssh
In-Reply-To: <201109302238.15465.g+dropbear@cobb.uk.net>
References: <201109302238.15465.g+dropbear@cobb.uk.net>
Message-ID: <4E8762D6.6020908@landley.net>

On 09/30/2011 04:38 PM, Graham Cobb wrote:
> Hi,
> 
> I have a router running an old version of OpenWRT with an old version of 
> dropbear (Dropbear sshd v0.44test3).  It has been working for many years and I 
> ssh in from my desktop systems (running Debian Testing) with no problem.
> 
> However, recently I upgraded one of my desktops and I can no longer connect to 
> the router.  Dropbear on the router is exiting with:
> 
> exit before auth: bad buf_getwriteptr
> 
> The desktop is running "SSH-2.0-OpenSSH_5.9p1 Debian-1" (it failed with 5.8 as 
> well).  However, another desktop still running "SSH-2.0-OpenSSH_5.5p1 
> Debian-6" still works fine.  The config files are identical.
> 
> I realise this is a very old version of dropbear and that you are not 
> responsible for changes in OpenSSH but I thought I would ask here in case 
> anyone else has seen this and can maybe suggest a config change to workround 
> the problem!
> 
> Graham
> 

If you'd like to try the current version, statically linked binaries of
current dropbearmulti for several of architectures are at:

  http://landley.net/aboriginal/downloads/binaries/extras/

Rob

From rob at landley.net  Sun Oct  2 03:00:28 2011
From: rob at landley.net (Rob Landley)
Date: Sat, 01 Oct 2011 14:00:28 -0500
Subject: Long delay during login
In-Reply-To: <loom.20110928T201806-539@post.gmane.org>
References: <200506131021.53380.srowe@cambridgebroadband.com>	<20050622053521.GG14943@ucc.gu.uwa.edu.au>
	<loom.20110928T201806-539@post.gmane.org>
Message-ID: <4E87634C.4010100@landley.net>

On 09/28/2011 01:31 PM, Gary wrote:
> Matt Johnston <matt <at> ucc.asn.au> writes:
> 
> On Mon, Jun 13, 2005 at 10:21:53AM +0100, Simon Rowe wrote:
>> We're seeing a long delay when logging in using dropbear on to our embedded 
>> system (60MHz PowerPC). Looking at the debug from the client end it appears 
>> that the issue is the Diffie-Hellman key negotiation within dropbear
>>
>> debug1: expecting SSH2_MSG_KEXDH_REPLY
>>
>> [delay of about 8 seconds]
>>
>> Is there anything we can change to reduce this delay?
> 
> 
> Same problem here.  My bet is that it's blocking on the random 
> device.  For me ssh'ng to a busy machine is fast, ssh'ng to an
> idle machine almost always has a BIG delay.

Switch from /dev/random to /dev/urandom perhaps?

Rob


From rob at landley.net  Tue Oct 11 01:30:30 2011
From: rob at landley.net (Rob Landley)
Date: Mon, 10 Oct 2011 12:30:30 -0500
Subject: No password means no public/private key either?
Message-ID: <4E932BB6.4010608@landley.net>

If the user has no password in /etc/passwd, dropbear rejects them
entirely and won't let them log in with a .ssh key either.

Why?

Rob

From avnerf at web-silicon.com  Wed Oct 12 00:05:01 2011
From: avnerf at web-silicon.com (Avner Flesch)
Date: Tue, 11 Oct 2011 18:05:01 +0200
Subject: Long delay during login
In-Reply-To: <4E87634C.4010100@landley.net>
References: <200506131021.53380.srowe@cambridgebroadband.com>
	<20050622053521.GG14943@ucc.gu.uwa.edu.au>
	<loom.20110928T201806-539@post.gmane.org>
	<4E87634C.4010100@landley.net>
Message-ID: <1318349101.3955.51.camel@avnerf-ThinkPad-SL510>

Hi,

I have also the same issue with dropbear version 0.53.1 on powerpc 50MHz
32bits the login took more then 30 seconds.
After I updated the libtomath library to version 0.42 and libtomcrypt
version to 1.17
I reduced the delay to 13 seconds.

But it still not enough - after a research I found that the delay is in
the routine "mp_exptmod_fast" from libtommath, there is a for(;;) loop
that take a while.
Is anyone know how can I overcome this issue?

Thanks

Avner

-----Original Message-----
From: Rob Landley <rob at landley.net>
To: Gary <gmart at coinet.com>
Cc: dropbear at ucc.asn.au
Subject: Re: Long delay during login
Date: Sat, 01 Oct 2011 14:00:28 -0500


On 09/28/2011 01:31 PM, Gary wrote:
> Matt Johnston <matt <at> ucc.asn.au> writes:
> 
> On Mon, Jun 13, 2005 at 10:21:53AM +0100, Simon Rowe wrote:
>> We're seeing a long delay when logging in using dropbear on to our embedded 
>> system (60MHz PowerPC). Looking at the debug from the client end it appears 
>> that the issue is the Diffie-Hellman key negotiation within dropbear
>>
>> debug1: expecting SSH2_MSG_KEXDH_REPLY
>>
>> [delay of about 8 seconds]
>>
>> Is there anything we can change to reduce this delay?
> 
> 
> Same problem here.  My bet is that it's blocking on the random 
> device.  For me ssh'ng to a busy machine is fast, ssh'ng to an
> idle machine almost always has a BIG delay.

Switch from /dev/random to /dev/urandom perhaps?

Rob



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

From stephanelelievre at orange.fr  Wed Oct 12 02:21:55 2011
From: stephanelelievre at orange.fr (Stephane)
Date: Tue, 11 Oct 2011 20:21:55 +0200
Subject: dropbear client : No auth methods could be used (again !)
Message-ID: <IJEBIAKHEBBNOAFEGJCCGELLCDAA.stephanelelievre@orange.fr>

Hi,

We develop an alternative firmware for NAS with Dropbear as SSH server
(0.53.1).
When we try to open an SSH access with dbclient command from a first NAS to
a second NAS (with the same firmware), we have this error message when using
key authentication mode :

Dropbear daemon with command :
- dropbear -s -r /rw_fs/etc/dropbear/dropbear_rsa_host_key

SSH access attempt :
- dbclient -i /rw_fs/etc/dropbear/dropbear_rsa_host_key root at 192.168.x.y
echo '$PATH'
dbclient: Connection to root at 192.168.x.y 22 exited: No auth methods could be
used.

By against, if we use password authentication mode,SSH access is open :
dbclient root at 192.168.x.y echo '$PATH'
root at 192.168.x.y's password:
/usr/bin:/bin:/sbin:/usr/sbin

Public keys of each server (dropbearkey-y-f ...) are saved reciprocally in
each file "authorized_keys" (pubkey_nas1 => authorized_keys_nas2, and
reversely).
The authorized_keys files are located in the folder "/.ssh" and with correct
permissions (700 /. ssh and 644 authorized_keys)

Dropbear compilation options :
./configure --prefix=/usr

and in options.h
/* The default path. This will often get replaced by the shell */
#define DEFAULT_PATH "/usr/bin:/bin:/sbin:/usr/sbin"

When we use option -F and -E, dropbear returns thhis :
[3815] Oct 10 23:17:31 Child connection from 192.168.x.y:36259
[3815] Oct 10 23:17:32 Exit before auth (user 'root', 0 fails): Exited
normally

What is the problem ?

Thanks in advance


From sl-bay at orange.fr  Thu Oct 13 02:53:17 2011
From: sl-bay at orange.fr (sl Bay)
Date: Wed, 12 Oct 2011 20:53:17 +0200 (CEST)
Subject: dropbear client : No auth methods could be used (again !)
Message-ID: <1390726192.130705.1318445597037.JavaMail.www@wwinf1m18>

The issue is solved !

Dropbear didn't accept to open a SSH access because the pubkey saved in authorized_keys in right format !

My mistake is that until now, I used an old version of putty (<0.61) and the public keys created by PUTYYgen haven't a format identical with those generated by dropbear:

Before Putty release 0.61 , Putty inserts one "=" between encode pubkey and comment field! 
Whilst, Dropbear inserts only one space.

By confusion, I saved the dropbear pubkey in the old putty format.

So, the key wasn't been found when an SSH access attempt by NAS1 in NAS2 !


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

From redhatter at gentoo.org  Thu Oct 13 11:33:40 2011
From: redhatter at gentoo.org (Stuart Longland)
Date: Thu, 13 Oct 2011 13:33:40 +1000
Subject: dropbear client : No auth methods could be used (again !)
In-Reply-To: <1390726192.130705.1318445597037.JavaMail.www@wwinf1m18>
References: <1390726192.130705.1318445597037.JavaMail.www@wwinf1m18>
Message-ID: <4E965C14.4030405@gentoo.org>

On 10/13/11 04:53, sl Bay wrote:
> The issue is solved !
>
> Dropbear didn't accept to open a SSH access because the pubkey saved in
> authorized_keys in right format !
>
> My mistake is that until now, I used an old version of putty (<0.61) and
> the public keys created by PUTYYgen haven't a format identical with
> those generated by dropbear:

Yes, PuTTY uses some funny format for its keys, which OpenSSH does not 
understand, and since dropbear is aiming to be a small-footprint 
alternative to OpenSSH, nor does dropbear.

There is a function in PuTTYgen that allows you to convert it to an 
OpenSSH-compatible format, it'll be one of the fields you see when you 
open a key in PuTTYgen in fact, you just copy it to your clipboard 
before typing:

$ cat >> .ssh/authorized_keys
{right click to paste clipboard}
^D
$
-- 
Stuart Longland (aka Redhatter, VK4MSL)      .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'
http://dev.gentoo.org/~redhatter             :.'

I haven't lost my mind...
   ...it's backed up on a tape somewhere.

From rob at landley.net  Sat Oct 15 01:34:01 2011
From: rob at landley.net (Rob Landley)
Date: Fri, 14 Oct 2011 12:34:01 -0500
Subject: Passwordless user shouldn't prevent public/private key login.
Message-ID: <4E987289.5080803@landley.net>

I'm using the attached horrible patch to allow users with no password to
log in via public/private key.  (Note there's a _separate_ test in the
actual password mechanism that vetos logins that way.)

This lets me switch systems from telnet to dropbear even when /etc is on
a read only filesystem.

Rob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dropbear-fixnopasswd.patch
Type: text/x-patch
Size: 662 bytes
Desc: not available
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20111014/6238cd3c/attachment.bin 

From g+dropbear at cobb.uk.net  Sun Oct 16 19:20:00 2011
From: g+dropbear at cobb.uk.net (Graham Cobb)
Date: Sun, 16 Oct 2011 12:20:00 +0100
Subject: Interop problem with old dropbear and new openssh
In-Reply-To: <4E8762D6.6020908@landley.net>
References: <201109302238.15465.g+dropbear@cobb.uk.net>
	<4E8762D6.6020908@landley.net>
Message-ID: <201110161220.06709.g+dropbear@cobb.uk.net>

On Saturday 01 October 2011 19:58:30 Rob Landley wrote:
> On 09/30/2011 04:38 PM, Graham Cobb wrote:
> > However, recently I upgraded one of my desktops and I can no longer
> > connect to the router.  Dropbear on the router is exiting with:
> > 
> > exit before auth: bad buf_getwriteptr
> > 
> > The desktop is running "SSH-2.0-OpenSSH_5.9p1 Debian-1" (it failed with
> > 5.8 as well).  However, another desktop still running
> > "SSH-2.0-OpenSSH_5.5p1 Debian-6" still works fine.  The config files are
> > identical.
...
> 
> If you'd like to try the current version, statically linked binaries of
> current dropbearmulti for several of architectures are at:
> 
>   http://landley.net/aboriginal/downloads/binaries/extras/

Just to close off this thread in case someone finds it in the future: I tracked 
down the set of changes in OpenSSH that caused the dropbear problem and there 
does not seem to be any option which can revert the behaviour.  So, the only 
fix is to get a newer version of dropbear.

I can report that 0.53.1 fixes the problem (0.44test2 and 0.43 were what I was 
running and both do not work).  Rob's binaries worked but in the end I built a 
smaller (non-static) version specifically for my (old) OpenWRT configuration.

Graham

From tilmanglotzner at hotmail.com  Sun Oct 16 21:50:59 2011
From: tilmanglotzner at hotmail.com (Tilman Glotzner)
Date: Sun, 16 Oct 2011 13:50:59 +0000
Subject: dropbrear not compiling statically
Message-ID: <BAY160-W44436E235B061D0D11656ACFE70@phx.gbl>


Hello
 
 
I am trying to compile dropbrear statically:
 
1)  configure
LDFLAGS="-L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/lib/"  ./configure --prefix=/opt/nfs/vmic7750/usr  --with-zlib=/opt/nfs/vmic7750/usr/lib/
 
2)  STATIC=1 LDFLAGS="-L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/lib/"   make PROGRAMS="dropbear dropbearkey scp"
This results in an error: 
 
gcc -L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/lib/ -static -o dropbear dbutil.o buffer.o dss.o bignum.o signkey.o rsa.o random.o queue.o atomicio.o compat.o  fake-rfc2553.o  common-session.o packet.o common-algo.o common-kex.o common-channel.o common-chansession.o termcodes.o loginrec.o tcp-accept.o listener.o process-packet.o common-runopts.o circbuffer.o -lcrypt svr-kex.o svr-algo.o svr-auth.o sshpty.o svr-authpasswd.o svr-authpubkey.o svr-authpubkeyoptions.o svr-session.o svr-service.o svr-chansession.o svr-runopts.o svr-agentfwd.o svr-main.o svr-x11fwd.o svr-tcpfwd.o svr-authpam.o  libtomcrypt/libtomcrypt.a libtommath/libtommath.a -lutil -lz
svr-chansession.o: In function `execchild':
svr-chansession.c:(.text+0x4b8): warning: Using 'initgroups' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
sshpty.o: In function `pty_setowner':
sshpty.c:(.text+0x18): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
common-session.o: In function `fill_passwd':
common-session.c:(.text+0x9f): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
dbutil.o: In function `connect_remote':
dbutil.c:(.text+0x96f): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
svr-authpasswd.o: In function `svr_auth_password':
svr-authpasswd.c:(.text+0x16): warning: Using 'getspnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
svr-authpasswd.c:(.text+0x70): undefined reference to `crypt'
collect2: ld returned 1 exit status
make: *** [dropbear] Error 1
 
 
3) Next attempt: add LIBS="-lcrypt"
STATIC=1 LDFLAGS="-L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/lib/" LIBS="-lcrypt"  make PROGRAMS="dropbear dropbearkey scp"
 
This links with a couple of warnings: Most noticable one:

gcc -L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/lib/ -static -o scp scp.o progressmeter.o atomicio.o scpmisc.o compat.o
scp.o: In function `main':
scp.c:(.text+0x2092): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
 
4) dropbearkey is not portable 
dropbearkey -t rsa -f /opt/nfs/vmic7750/etc/dropbear/dropbear_rsa_host_key works on the machine on which I compiled it.
 
On another machine, it however does not start. Error message is this: 
dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key
dropbearkey: /lib/libc.so.6: version `GLIBC_2.7' not found (required by dropbear)
 
I guess this is related to different libc's, i.e. the machine that compiled dropbear probably uses an newer version than the one executing it. Unfortunatelly, I do not get libc compiled. And I also wonder a bit, because I hoped to avoid mismatches like this by statically linking. 
 
5) I created dropbear_[rsa|dss]_host_key  on the build machine, and copied to the machine on which I want to run dropbear. /usr/sbin/dropbear starts up fine. A root login is refused however:
 
ssh root at 192.168.1.40
....
The authenticity of host '192.168.1.40 (192.168.1.40)' can't be established.
....
Warning: Permanently added '192.168.1.40' (RSA) to the list of known hosts.
root at 192.168.1.40's password:
Permission denied, please try again.
...
 
Apparantly, dropbear does not know user root -- I wonder why however (root is defined in /etc/passwd) :
 
Oct 16 17:01:30 192.168.1.40 dropbear[867]: Child connection from 192.168.1.59:44549
Oct 16 17:01:31 192.168.1.40 dropbear[867]: Login attempt for nonexistent user from 192.168.1.59:44549
Oct 16 17:01:32 192.168.1.40 dropbear[867]: Login attempt for nonexistent user from 192.168.1.59:44549
Oct 16 17:01:33 192.168.1.40 dropbear[867]: Login attempt for nonexistent user from 192.168.1.59:44549
Oct 16 17:01:34 192.168.1.40 dropbear[867]: Login attempt for nonexistent user from 192.168.1.59:44549
Oct 16 17:01:35 192.168.1.40 dropbear[867]: Exit before auth: Error writing

Help is certainly apprecitated .-)
 
Thanks
 
Tilman
 
Thanks
 
Tilman

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

From matt at ucc.asn.au  Mon Oct 17 18:27:38 2011
From: matt at ucc.asn.au (Matt Johnston)
Date: Mon, 17 Oct 2011 18:27:38 +0800
Subject: dropbrear not compiling statically
In-Reply-To: <BAY160-W44436E235B061D0D11656ACFE70@phx.gbl>
References: <BAY160-W44436E235B061D0D11656ACFE70@phx.gbl>
Message-ID: <20111017102738.GJ17889@ucc.gu.uwa.edu.au>

Hi,

The LIBS="-lcrypt" workaround is known bug, it will be fixed in
the next release.

The other problems with compiling statically are more
general. It isn't really possible to compile a program
totally statically against glibc since it will still depend
on dynamic libnss*.so depending on the contents of
/etc/nsswitch.conf. That's what the warning about
"initgroups" etc means. 

My advice would be to build statically against uClibc which
is well tested with Dropbear. The LIBS="-lcrypt" will still
be needed for the time being.

Cheers,
Matt


On Sun, Oct 16, 2011 at 01:50:59PM +0000, Tilman Glotzner wrote:
> 
> Hello
>  
>  
> I am trying to compile dropbrear statically:
>  
> 1)  configure
> LDFLAGS="-L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/lib/"  ./configure --prefix=/opt/nfs/vmic7750/usr  --with-zlib=/opt/nfs/vmic7750/usr/lib/
>  
> 2)  STATIC=1 LDFLAGS="-L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/lib/"   make PROGRAMS="dropbear dropbearkey scp"
> This results in an error: 
>  
> gcc -L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/lib/ -static -o dropbear dbutil.o buffer.o dss.o bignum.o signkey.o rsa.o random.o queue.o atomicio.o compat.o  fake-rfc2553.o  common-session.o packet.o common-algo.o common-kex.o common-channel.o common-chansession.o termcodes.o loginrec.o tcp-accept.o listener.o process-packet.o common-runopts.o circbuffer.o -lcrypt svr-kex.o svr-algo.o svr-auth.o sshpty.o svr-authpasswd.o svr-authpubkey.o svr-authpubkeyoptions.o svr-session.o svr-service.o svr-chansession.o svr-runopts.o svr-agentfwd.o svr-main.o svr-x11fwd.o svr-tcpfwd.o svr-authpam.o  libtomcrypt/libtomcrypt.a libtommath/libtommath.a -lutil -lz
> svr-chansession.o: In function `execchild':
> svr-chansession.c:(.text+0x4b8): warning: Using 'initgroups' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> sshpty.o: In function `pty_setowner':
> sshpty.c:(.text+0x18): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> common-session.o: In function `fill_passwd':
> common-session.c:(.text+0x9f): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> dbutil.o: In function `connect_remote':
> dbutil.c:(.text+0x96f): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> svr-authpasswd.o: In function `svr_auth_password':
> svr-authpasswd.c:(.text+0x16): warning: Using 'getspnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> svr-authpasswd.c:(.text+0x70): undefined reference to `crypt'
> collect2: ld returned 1 exit status
> make: *** [dropbear] Error 1
>  
>  
> 3) Next attempt: add LIBS="-lcrypt"
> STATIC=1 LDFLAGS="-L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/lib/" LIBS="-lcrypt"  make PROGRAMS="dropbear dropbearkey scp"
>  
> This links with a couple of warnings: Most noticable one:
> 
> gcc -L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/lib/ -static -o scp scp.o progressmeter.o atomicio.o scpmisc.o compat.o
> scp.o: In function `main':
> scp.c:(.text+0x2092): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
>  
> 4) dropbearkey is not portable 
> dropbearkey -t rsa -f /opt/nfs/vmic7750/etc/dropbear/dropbear_rsa_host_key works on the machine on which I compiled it.
>  
> On another machine, it however does not start. Error message is this: 
> dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key
> dropbearkey: /lib/libc.so.6: version `GLIBC_2.7' not found (required by dropbear)
>  
> I guess this is related to different libc's, i.e. the machine that compiled dropbear probably uses an newer version than the one executing it. Unfortunatelly, I do not get libc compiled. And I also wonder a bit, because I hoped to avoid mismatches like this by statically linking. 
>  
> 5) I created dropbear_[rsa|dss]_host_key  on the build machine, and copied to the machine on which I want to run dropbear. /usr/sbin/dropbear starts up fine. A root login is refused however:
>  
> ssh root at 192.168.1.40
> ....
> The authenticity of host '192.168.1.40 (192.168.1.40)' can't be established.
> ....
> Warning: Permanently added '192.168.1.40' (RSA) to the list of known hosts.
> root at 192.168.1.40's password:
> Permission denied, please try again.
> ...
>  
> Apparantly, dropbear does not know user root -- I wonder why however (root is defined in /etc/passwd) :
>  
> Oct 16 17:01:30 192.168.1.40 dropbear[867]: Child connection from 192.168.1.59:44549
> Oct 16 17:01:31 192.168.1.40 dropbear[867]: Login attempt for nonexistent user from 192.168.1.59:44549
> Oct 16 17:01:32 192.168.1.40 dropbear[867]: Login attempt for nonexistent user from 192.168.1.59:44549
> Oct 16 17:01:33 192.168.1.40 dropbear[867]: Login attempt for nonexistent user from 192.168.1.59:44549
> Oct 16 17:01:34 192.168.1.40 dropbear[867]: Login attempt for nonexistent user from 192.168.1.59:44549
> Oct 16 17:01:35 192.168.1.40 dropbear[867]: Exit before auth: Error writing
> 
> Help is certainly apprecitated .-)
>  
> Thanks
>  
> Tilman
>  
> Thanks
>  
> Tilman
> 
>  
>  
>  
>   		 	   		  

From rob at landley.net  Tue Oct 18 01:45:20 2011
From: rob at landley.net (Rob Landley)
Date: Mon, 17 Oct 2011 12:45:20 -0500
Subject: dropbrear not compiling statically
In-Reply-To: <BAY160-W44436E235B061D0D11656ACFE70@phx.gbl>
References: <BAY160-W44436E235B061D0D11656ACFE70@phx.gbl>
Message-ID: <4E9C69B0.4030706@landley.net>

On 10/16/2011 08:50 AM, Tilman Glotzner wrote:
> Hello
>  
>  
> I am trying to compile dropbrear statically:

I'm using the attached patch with the following build sequence to build
the statically linked dropbearmulti instances at
http://landley.net/aboriginal/downloads/binaries/extras against uClibc.

cp -sfR /mnt/dropbear dropbear &&
cd dropbear &&
CFLAGS="-I ../zlib -Os" LDFLAGS="--static -L ../zlib" ./configure &&
sed -i 's@/usr/bin/dbclient at ssh@' options.h &&
make -j $CPUS PROGRAMS="dropbear dbclient dropbearkey dropbearconvert
scp" MULTI=1 SCPPROGRESS=1 &&
strip dropbearmulti &&
upload_result dropbearmulti &&
cd .. &&
rm -rf dropbear || exit 1

> Warning: Permanently added '192.168.1.40' (RSA) to the list of known hosts.
> root at 192.168.1.40's <mailto:root at 192.168.1.40's> password:
> Permission denied, please try again.
> ...
>  
> Apparantly, dropbear does not know user root -- I wonder why however
> (root is defined in /etc/passwd) :

If the root user has no password, dropbear discards it even if you plan
to use public/private key to get in.  (There's a separate test in
password authentication disallowing empty passwords, this is a test in
user verification that discards the user as _invalid_.  It also does so
if their /home directory didn't exist, and a few other things.  Run it
with -F -E and see what it says when you try to log in.)

The second patch is how I worked around that.  (And yes,  I poked the
list about both issues already...)

Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dropbear-fixstatic.patch
Type: text/x-patch
Size: 1548 bytes
Desc: not available
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20111017/b3309646/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dropbear-fixnopasswd.patch
Type: text/x-patch
Size: 662 bytes
Desc: not available
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20111017/b3309646/attachment-0001.bin 

From lists at wildgooses.com  Sun Oct 23 02:38:11 2011
From: lists at wildgooses.com (Ed W)
Date: Sat, 22 Oct 2011 19:38:11 +0100
Subject: Support for ecdsa certs
In-Reply-To: <20110824122247.GD6446@ucc.gu.uwa.edu.au>
References: <4E44F472.2020809@wildgooses.com>
	<20110824115442.GC6446@ucc.gu.uwa.edu.au>
	<4E54E87F.3050309@wildgooses.com>
	<20110824122247.GD6446@ucc.gu.uwa.edu.au>
Message-ID: <4EA30D93.2020109@wildgooses.com>

Hi Matt

I'm still very interested to see if we can add this feature to
Dropbear.  Any chance you could consider taking a look at it again?

As I said before, I would be interested to sponsor such a feature

In particular I'm interested in compatibility with the same in openssh,
so kex: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521

Many thanks

Ed W

On 24/08/2011 13:22, Matt Johnston wrote:
> It's a feature I'd like to add, I'll take a look at how much
> is involved and get back to you off-list.
>
> Cheers,
> Matt
>
> On Wed, Aug 24, 2011 at 01:03:11PM +0100, Ed W wrote:
>> Hi, assuming what you say isn't a complete blocker - are you open to
>> "sponsorship" to add it as a feature?
>>
>> Cheers
>>
>> Ed W
>>
>>
>> On 24/08/2011 12:54, Matt Johnston wrote:
>>> Hi,
>>>
>>> Sorry for the delayed reply. I have a very brief look at it.
>>> The actual SSH protocol parts probably aren't too hard to
>>> implement, just some similar bits to the existing code in
>>> *kex.c and dsa.c.  However I don't know how good
>>> libtomcrypt and libtommath's ECC support is, so possibly
>>> that could be a problem. 
>>>
>>> Cheers,
>>> Matt
>>>
>>> On Fri, Aug 12, 2011 at 10:37:54AM +0100, Ed W wrote:
>>>> Hi, What is required to extend dropbear to support ecdsa certificates -
>>>> I'm mainly interested in the client support, but server support would be
>>>> nice also?
>>>>
>>>> Thanks
>>>>
>>>> Ed W


From avnerf at web-silicon.com  Sun Oct 23 22:28:11 2011
From: avnerf at web-silicon.com (Avner Flesch)
Date: Sun, 23 Oct 2011 16:28:11 +0200
Subject: Long delay during login
In-Reply-To: <1318349101.3955.51.camel@avnerf-ThinkPad-SL510>
References: <200506131021.53380.srowe@cambridgebroadband.com>
	<20050622053521.GG14943@ucc.gu.uwa.edu.au>
	<loom.20110928T201806-539@post.gmane.org>
	<4E87634C.4010100@landley.net>
	<1318349101.3955.51.camel@avnerf-ThinkPad-SL510>
Message-ID: <1319380091.6626.20.camel@avnerf-ThinkPad-SL510>

Hi,

I used dropbear that was ported to tomsfastmath library(instead of
tommath).
I reduced the login delay on my machine (powerpc 8xx 50MHz) to 5
seconds!

I would like to reduce the delay more. Is anyone has any idea?

Thanks

Avner

-----Original Message-----
From: Avner Flesch <avnerf at web-silicon.com>
To: Rob Landley <rob at landley.net>
Cc: Gary <gmart at coinet.com>, dropbear at ucc.asn.au
Subject: Re: Long delay during login
Date: Tue, 11 Oct 2011 18:05:01 +0200

Hi,

I have also the same issue with dropbear version 0.53.1 on powerpc 50MHz
32bits the login took more then 30 seconds.
After I updated the libtomath library to version 0.42 and libtomcrypt
version to 1.17
I reduced the delay to 13 seconds.

But it still not enough - after a research I found that the delay is in
the routine "mp_exptmod_fast" from libtommath, there is a for(;;) loop
that take a while.
Is anyone know how can I overcome this issue?

Thanks

Avner

-----Original Message-----
From: Rob Landley <rob at landley.net>
To: Gary <gmart at coinet.com>
Cc: dropbear at ucc.asn.au
Subject: Re: Long delay during login
Date: Sat, 01 Oct 2011 14:00:28 -0500


On 09/28/2011 01:31 PM, Gary wrote:
> Matt Johnston <matt <at> ucc.asn.au> writes:
> 
> On Mon, Jun 13, 2005 at 10:21:53AM +0100, Simon Rowe wrote:
>> We're seeing a long delay when logging in using dropbear on to our embedded 
>> system (60MHz PowerPC). Looking at the debug from the client end it appears 
>> that the issue is the Diffie-Hellman key negotiation within dropbear
>>
>> debug1: expecting SSH2_MSG_KEXDH_REPLY
>>
>> [delay of about 8 seconds]
>>
>> Is there anything we can change to reduce this delay?
> 
> 
> Same problem here.  My bet is that it's blocking on the random 
> device.  For me ssh'ng to a busy machine is fast, ssh'ng to an
> idle machine almost always has a BIG delay.

Switch from /dev/random to /dev/urandom perhaps?

Rob




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20111023/3af68003/attachment.htm 

From rob at landley.net  Mon Oct 24 06:23:19 2011
From: rob at landley.net (Rob Landley)
Date: Sun, 23 Oct 2011 17:23:19 -0500
Subject: Long delay during login
In-Reply-To: <1319380091.6626.20.camel@avnerf-ThinkPad-SL510>
References: <200506131021.53380.srowe@cambridgebroadband.com>
	<20050622053521.GG14943@ucc.gu.uwa.edu.au>
	<loom.20110928T201806-539@post.gmane.org>
	<4E87634C.4010100@landley.net>
	<1318349101.3955.51.camel@avnerf-ThinkPad-SL510>
	<1319380091.6626.20.camel@avnerf-ThinkPad-SL510>
Message-ID: <4EA493D7.8060500@landley.net>

Where does one get such a port?  (Are there instructions?)

Rob

On 10/23/2011 09:28 AM, Avner Flesch wrote:
> Hi,
> 
> I used dropbear that was ported to tomsfastmath library(instead of tommath).
> I reduced the login delay on my machine (powerpc 8xx 50MHz) to 5 seconds!
> 
> I would like to reduce the delay more. Is anyone has any idea?
> 
> Thanks
> 
> Avner
> 
> -----Original Message-----
> *From*: Avner Flesch <avnerf at web-silicon.com
> <mailto:Avner%20Flesch%20%3cavnerf at web-silicon.com%3e>>
> *To*: Rob Landley <rob at landley.net
> <mailto:Rob%20Landley%20%3crob at landley.net%3e>>
> *Cc*: Gary <gmart at coinet.com <mailto:Gary%20%3cgmart at coinet.com%3e>>,
> dropbear at ucc.asn.au <mailto:dropbear at ucc.asn.au>
> *Subject*: Re: Long delay during login
> *Date*: Tue, 11 Oct 2011 18:05:01 +0200
> 
> Hi,
> 
> I have also the same issue with dropbear version 0.53.1 on powerpc 50MHz
> 32bits the login took more then 30 seconds.
> After I updated the libtomath library to version 0.42 and libtomcrypt
> version to 1.17
> I reduced the delay to 13 seconds.
> 
> But it still not enough - after a research I found that the delay is in
> the routine "mp_exptmod_fast" from libtommath, there is a for(;;) loop
> that take a while.
> Is anyone know how can I overcome this issue?
> 
> Thanks
> 
> Avner
> 
> -----Original Message-----
> *From*: Rob Landley <rob at landley.net
> <mailto:Rob%20Landley%20%3crob at landley.net%3e>>
> *To*: Gary <gmart at coinet.com <mailto:Gary%20%3cgmart at coinet.com%3e>>
> *Cc*: dropbear at ucc.asn.au <mailto:dropbear at ucc.asn.au>
> *Subject*: Re: Long delay during login
> *Date*: Sat, 01 Oct 2011 14:00:28 -0500
> 
> On 09/28/2011 01:31 PM, Gary wrote:
>> Matt Johnston <matt <at> ucc.asn.au> writes:
>> 
>> On Mon, Jun 13, 2005 at 10:21:53AM +0100, Simon Rowe wrote:
>>> We're seeing a long delay when logging in using dropbear on to our embedded 
>>> system (60MHz PowerPC). Looking at the debug from the client end it appears 
>>> that the issue is the Diffie-Hellman key negotiation within dropbear
>>>
>>> debug1: expecting SSH2_MSG_KEXDH_REPLY
>>>
>>> [delay of about 8 seconds]
>>>
>>> Is there anything we can change to reduce this delay?
>> 
>> 
>> Same problem here.  My bet is that it's blocking on the random 
>> device.  For me ssh'ng to a busy machine is fast, ssh'ng to an
>> idle machine almost always has a BIG delay.
> 
> Switch from /dev/random to /dev/urandom perhaps?
> 
> Rob
> 
> 
> 
> 


From peter at turczak.de  Tue Oct 25 21:38:51 2011
From: peter at turczak.de (Peter Turczak)
Date: Tue, 25 Oct 2011 15:38:51 +0200
Subject: Long delay during login
In-Reply-To: <4EA493D7.8060500@landley.net>
References: <200506131021.53380.srowe@cambridgebroadband.com>
	<20050622053521.GG14943@ucc.gu.uwa.edu.au>
	<loom.20110928T201806-539@post.gmane.org>
	<4E87634C.4010100@landley.net>
	<1318349101.3955.51.camel@avnerf-ThinkPad-SL510>
	<1319380091.6626.20.camel@avnerf-ThinkPad-SL510>
	<4EA493D7.8060500@landley.net>
Message-ID: <673F757D-6538-4FDB-BA09-1621CEFD723D@turczak.de>

Hi Rob,

a few years back in 2008 I did this port and announced it here. But it didn't seem to get much of a grip. You will find it's source here : http://peter.turczak.de/dropbear-tfm.tgz .

Maybe it may help out someone in dire need of a faster ssh-handshake ;).

Best regards,
  Peter

On Oct 24, 2011, at 12:23 AM, Rob Landley wrote:

> Where does one get such a port?  (Are there instructions?)
> 
> Rob
> 
> On 10/23/2011 09:28 AM, Avner Flesch wrote:
>> Hi,
>> 
>> I used dropbear that was ported to tomsfastmath library(instead of tommath).
>> I reduced the login delay on my machine (powerpc 8xx 50MHz) to 5 seconds!
>> 
>> I would like to reduce the delay more. Is anyone has any idea?
>> 
>> Thanks
>> 
>> Avner
>> 
>> -----Original Message-----
>> *From*: Avner Flesch <avnerf at web-silicon.com
>> <mailto:Avner%20Flesch%20%3cavnerf at web-silicon.com%3e>>
>> *To*: Rob Landley <rob at landley.net
>> <mailto:Rob%20Landley%20%3crob at landley.net%3e>>
>> *Cc*: Gary <gmart at coinet.com <mailto:Gary%20%3cgmart at coinet.com%3e>>,
>> dropbear at ucc.asn.au <mailto:dropbear at ucc.asn.au>
>> *Subject*: Re: Long delay during login
>> *Date*: Tue, 11 Oct 2011 18:05:01 +0200
>> 
>> Hi,
>> 
>> I have also the same issue with dropbear version 0.53.1 on powerpc 50MHz
>> 32bits the login took more then 30 seconds.
>> After I updated the libtomath library to version 0.42 and libtomcrypt
>> version to 1.17
>> I reduced the delay to 13 seconds.
>> 
>> But it still not enough - after a research I found that the delay is in
>> the routine "mp_exptmod_fast" from libtommath, there is a for(;;) loop
>> that take a while.
>> Is anyone know how can I overcome this issue?
>> 
>> Thanks
>> 
>> Avner
>> 
>> -----Original Message-----
>> *From*: Rob Landley <rob at landley.net
>> <mailto:Rob%20Landley%20%3crob at landley.net%3e>>
>> *To*: Gary <gmart at coinet.com <mailto:Gary%20%3cgmart at coinet.com%3e>>
>> *Cc*: dropbear at ucc.asn.au <mailto:dropbear at ucc.asn.au>
>> *Subject*: Re: Long delay during login
>> *Date*: Sat, 01 Oct 2011 14:00:28 -0500
>> 
>> On 09/28/2011 01:31 PM, Gary wrote:
>>> Matt Johnston <matt <at> ucc.asn.au> writes:
>>> 
>>> On Mon, Jun 13, 2005 at 10:21:53AM +0100, Simon Rowe wrote:
>>>> We're seeing a long delay when logging in using dropbear on to our embedded 
>>>> system (60MHz PowerPC). Looking at the debug from the client end it appears 
>>>> that the issue is the Diffie-Hellman key negotiation within dropbear
>>>> 
>>>> debug1: expecting SSH2_MSG_KEXDH_REPLY
>>>> 
>>>> [delay of about 8 seconds]
>>>> 
>>>> Is there anything we can change to reduce this delay?
>>> 
>>> 
>>> Same problem here.  My bet is that it's blocking on the random 
>>> device.  For me ssh'ng to a busy machine is fast, ssh'ng to an
>>> idle machine almost always has a BIG delay.
>> 
>> Switch from /dev/random to /dev/urandom perhaps?
>> 
>> Rob
>> 
>> 
>> 
>> 
> 


From lists at wildgooses.com  Wed Oct 26 03:09:42 2011
From: lists at wildgooses.com (Ed W)
Date: Tue, 25 Oct 2011 20:09:42 +0100
Subject: Long delay during login
In-Reply-To: <673F757D-6538-4FDB-BA09-1621CEFD723D@turczak.de>
References: <200506131021.53380.srowe@cambridgebroadband.com>
	<20050622053521.GG14943@ucc.gu.uwa.edu.au>
	<loom.20110928T201806-539@post.gmane.org>
	<4E87634C.4010100@landley.net>
	<1318349101.3955.51.camel@avnerf-ThinkPad-SL510>
	<1319380091.6626.20.camel@avnerf-ThinkPad-SL510>
	<4EA493D7.8060500@landley.net>
	<673F757D-6538-4FDB-BA09-1621CEFD723D@turczak.de>
Message-ID: <4EA70976.6020500@wildgooses.com>

On 25/10/2011 14:38, Peter Turczak wrote:
> Hi Rob,
>
> a few years back in 2008 I did this port and announced it here. But it didn't seem to get much of a grip. You will find it's source here : http://peter.turczak.de/dropbear-tfm.tgz .
>
> Maybe it may help out someone in dire need of a faster ssh-handshake ;).
>

Could you post it as a diff so that we can see what changed?

It's hard for me to know what your base version was?

Cheers

Ed W

From rob at landley.net  Wed Oct 26 06:15:58 2011
From: rob at landley.net (Rob Landley)
Date: Tue, 25 Oct 2011 17:15:58 -0500
Subject: Long delay during login
In-Reply-To: <4EA70976.6020500@wildgooses.com>
References: <200506131021.53380.srowe@cambridgebroadband.com>	<20050622053521.GG14943@ucc.gu.uwa.edu.au>	<loom.20110928T201806-539@post.gmane.org>	<4E87634C.4010100@landley.net>	<1318349101.3955.51.camel@avnerf-ThinkPad-SL510>	<1319380091.6626.20.camel@avnerf-ThinkPad-SL510>	<4EA493D7.8060500@landley.net>	<673F757D-6538-4FDB-BA09-1621CEFD723D@turczak.de>
	<4EA70976.6020500@wildgooses.com>
Message-ID: <4EA7351E.8070101@landley.net>

On 10/25/2011 02:09 PM, Ed W wrote:
> On 25/10/2011 14:38, Peter Turczak wrote:
>> Hi Rob,
>> 
>> a few years back in 2008 I did this port and announced it here. But
>> it didn't seem to get much of a grip. You will find it's source
>> here : http://peter.turczak.de/dropbear-tfm.tgz .
>> 
>> Maybe it may help out someone in dire need of a faster
>> ssh-handshake ;).
>> 
> 
> Could you post it as a diff so that we can see what changed?
> 
> It's hard for me to know what your base version was?

According to _MTN/revision the base version was:

  old_revision [f2c4b1b1304914efad934b368d3f6e4e8d91de99]

But I have no clue what that means.  Never used monotone, and it's not
worth learning for one project.  (I've already learned git, mercurial,
subversion, and some passign knowledge of bitkeeper.  I've been paid to
do cvs, rational, perforce, some internal IBM one with a four letter
acronym I'm blanking on right now which OS/2 was in, and now I have to
deal with accurev.  For various reasons I've had to install Bazaar and
Darcs but never actually used either as a source control system.)

There was some mention of porting this to mercurial, and I copied some
messages back and forth between the dropbear and mercurial mailing
lists, but that seems to have petered out.  (I haven't exactly been
following up either.  Todo list runneth over...)

Rob

From avnerf at web-silicon.com  Wed Oct 26 13:50:48 2011
From: avnerf at web-silicon.com (Avner Flesch)
Date: Wed, 26 Oct 2011 07:50:48 +0200
Subject: Long delay during login
In-Reply-To: <4EA7351E.8070101@landley.net>
References: <200506131021.53380.srowe@cambridgebroadband.com>
	<20050622053521.GG14943@ucc.gu.uwa.edu.au>
	<loom.20110928T201806-539@post.gmane.org>
	<4E87634C.4010100@landley.net>
	<1318349101.3955.51.camel@avnerf-ThinkPad-SL510>
	<1319380091.6626.20.camel@avnerf-ThinkPad-SL510>
	<4EA493D7.8060500@landley.net>
	<673F757D-6538-4FDB-BA09-1621CEFD723D@turczak.de>
	<4EA70976.6020500@wildgooses.com> <4EA7351E.8070101@landley.net>
Message-ID: <1319608248.29126.7.camel@avnerf-ThinkPad-SL510>

Hi,

Peter work based on dropbear version 0.52
libtomcrypt version 1.16
libtomsfastmath 0.10


-----Original Message-----
From: Rob Landley <rob at landley.net>
To: Ed W <lists at wildgooses.com>
Cc: dropbear at ucc.asn.au
Subject: Re: Long delay during login
Date: Tue, 25 Oct 2011 17:15:58 -0500


On 10/25/2011 02:09 PM, Ed W wrote:
> On 25/10/2011 14:38, Peter Turczak wrote:
>> Hi Rob,
>> 
>> a few years back in 2008 I did this port and announced it here. But
>> it didn't seem to get much of a grip. You will find it's source
>> here : http://peter.turczak.de/dropbear-tfm.tgz .
>> 
>> Maybe it may help out someone in dire need of a faster
>> ssh-handshake ;).
>> 
> 
> Could you post it as a diff so that we can see what changed?
> 
> It's hard for me to know what your base version was?

According to _MTN/revision the base version was:

  old_revision [f2c4b1b1304914efad934b368d3f6e4e8d91de99]

But I have no clue what that means.  Never used monotone, and it's not
worth learning for one project.  (I've already learned git, mercurial,
subversion, and some passign knowledge of bitkeeper.  I've been paid to
do cvs, rational, perforce, some internal IBM one with a four letter
acronym I'm blanking on right now which OS/2 was in, and now I have to
deal with accurev.  For various reasons I've had to install Bazaar and
Darcs but never actually used either as a source control system.)

There was some mention of porting this to mercurial, and I copied some
messages back and forth between the dropbear and mercurial mailing
lists, but that seems to have petered out.  (I haven't exactly been
following up either.  Todo list runneth over...)

Rob


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

From matt at ucc.asn.au  Wed Oct 26 23:57:18 2011
From: matt at ucc.asn.au (Matt Johnston)
Date: Wed, 26 Oct 2011 23:57:18 +0800
Subject: Passwordless user shouldn't prevent public/private key login.
In-Reply-To: <4E987289.5080803@landley.net>
References: <4E987289.5080803@landley.net>
Message-ID: <20111026155718.GN20075@ucc.gu.uwa.edu.au>

Hi,

Commenting out that code looks like a good idea - I think
it's from before pubkey auth was added to Dropbear. I've got
a separate but related patch to allow empty passwords if you
want, see attached.

PS, mercurial conversion is still planned, but I need to get
time to hack up the mercurial monotone converter to work on
my repository.

Cheers,
Matt

On Fri, Oct 14, 2011 at 12:34:01PM -0500, Rob Landley wrote:
> I'm using the attached horrible patch to allow users with no password to
> log in via public/private key.  (Note there's a _separate_ test in the
> actual password mechanism that vetos logins that way.)
> 
> This lets me switch systems from telnet to dropbear even when /etc is on
> a read only filesystem.
> 
> Rob
> 

> No password is no reason to prevent key-based logins.
> 
> diff -ru dropbear.new/svr-auth.c dropbear/svr-auth.c
> --- dropbear.new/svr-auth.c	2011-10-11 09:50:22.047129393 -0500
> +++ dropbear/svr-auth.c	2011-03-02 07:23:36.000000000 -0600
> @@ -249,7 +249,7 @@
>  		return DROPBEAR_FAILURE;
>  	}
>  
> -	/* check for an empty password */
> +	/* check for an empty password
>  	if (ses.authstate.pw_passwd[0] == '\0') {
>  		TRACE(("leave checkusername: empty pword"))
>  		dropbear_log(LOG_WARNING, "User '%s' has blank password, rejected",
> @@ -257,6 +257,7 @@
>  		send_msg_userauth_failure(0, 1);
>  		return DROPBEAR_FAILURE;
>  	}
> +*/
>  
>  	TRACE(("shell is %s", ses.authstate.pw_shell))
>  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dropbear-blank-pw.diff
Type: text/x-diff
Size: 3856 bytes
Desc: not available
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20111026/54e17b8c/attachment.diff 

From 0x90 at phocean.net  Sun Nov  6 01:01:13 2011
From: 0x90 at phocean.net (phocean)
Date: Sat, 05 Nov 2011 18:01:13 +0100
Subject: [solaris] library -lc: not found
Message-ID: <4EB56BD9.90802@phocean.net>

Hi all,

I am trying to compile scp on Solaris 11.

So far I faced the same issue as Antony with u_int64_t, but the
workaround was easy.

Now it fails like this :

$ make PROGRAMS="scp" STATIC=1
gcc -L/usr/local/lib -R/usr/local/lib -static -o scp scp.o
progressmeter.o atomicio.o scpmisc.o compat.o
ld: fatal: library -lc: not found
ld: fatal: file processing errors. No output written to scp
collect2: ld returned 1 exit status
make: *** [scp] Erreur 1

Obviously /usr/lib is not the correct path, but what is this library it
is complaining about?
I tried in vain to adjust this path to /usr/lib and /lib.
Any idea?

Sadly I know little about Solaris and programming stuff...

Thank you in advance,

Best regards,
-- 
phocean

From 0x90 at phocean.net  Sun Nov  6 01:02:54 2011
From: 0x90 at phocean.net (phocean)
Date: Sat, 05 Nov 2011 18:02:54 +0100
Subject: [solaris] library -lc: not found
In-Reply-To: <4EB56BD9.90802@phocean.net>
References: <4EB56BD9.90802@phocean.net>
Message-ID: <4EB56C3E.4080304@phocean.net>

Sorry, I forgot the link about Antony's issues with Solaris :
http://comments.gmane.org/gmane.network.ssh.dropbear/1043

Le 05/11/2011 18:01, phocean a ?crit :
> Hi all,
> 
> I am trying to compile scp on Solaris 11.
> 
> So far I faced the same issue as Antony with u_int64_t, but the
> workaround was easy.
> 
> Now it fails like this :
> 
> $ make PROGRAMS="scp" STATIC=1
> gcc -L/usr/local/lib -R/usr/local/lib -static -o scp scp.o
> progressmeter.o atomicio.o scpmisc.o compat.o
> ld: fatal: library -lc: not found
> ld: fatal: file processing errors. No output written to scp
> collect2: ld returned 1 exit status
> make: *** [scp] Erreur 1
> 
> Obviously /usr/lib is not the correct path, but what is this library it
> is complaining about?
> I tried in vain to adjust this path to /usr/lib and /lib.
> Any idea?
> 
> Sadly I know little about Solaris and programming stuff...
> 
> Thank you in advance,
> 
> Best regards,


-- 
phocean

From rob at landley.net  Sun Nov  6 09:24:31 2011
From: rob at landley.net (Rob Landley)
Date: Sat, 05 Nov 2011 20:24:31 -0500
Subject: [solaris] library -lc: not found
In-Reply-To: <4EB56BD9.90802@phocean.net>
References: <4EB56BD9.90802@phocean.net>
Message-ID: <4EB5E1CF.4020904@landley.net>

On 11/05/2011 12:01 PM, phocean wrote:
> Now it fails like this :
> 
> $ make PROGRAMS="scp" STATIC=1
> gcc -L/usr/local/lib -R/usr/local/lib -static -o scp scp.o
> progressmeter.o atomicio.o scpmisc.o compat.o
> ld: fatal: library -lc: not found
> ld: fatal: file processing errors. No output written to scp
> collect2: ld returned 1 exit status
> make: *** [scp] Erreur 1
> 
> Obviously /usr/lib is not the correct path, but what is this library it
> is complaining about?

That would be the C library.  libc.  I.E. the library containign
standard C functions like printf.  When you build "hello world", it
links against libc.

Your bug report boils down to "my toolchain is so broken it can't build
hello world".  This is not a dropbear issue.

Why are you building a program for solaris, didn't Sun go out of
business and oracle terminate their abandonware version?

Rob

From matt at ucc.asn.au  Sun Nov  6 14:20:13 2011
From: matt at ucc.asn.au (Matt Johnston)
Date: Sun, 6 Nov 2011 14:20:13 +0800
Subject: [solaris] library -lc: not found
In-Reply-To: <4EB56BD9.90802@phocean.net>
References: <4EB56BD9.90802@phocean.net>
Message-ID: <20111106062013.GZ20075@ucc.gu.uwa.edu.au>

I think you cannot build static programs on Solaris. From the
cc manpage

  Note: Many system libraries, such as libc, are only
  available as dynamic libraries in the Solaris 64-bit
  compilation environment. Therefore, do not use -Bstatic
  as the last toggle on the command line.

I guess it's similar to Linux except glibc will link then fail at runtime :)

Antony mentioned needing the realtime library for nanosleep,
but to me it looks like it's in the main libc on Solaris 11.
Did you need to change that?

Cheers,
Matt

On Sat, Nov 05, 2011 at 06:01:13PM +0100, phocean wrote:
> Hi all,
> 
> I am trying to compile scp on Solaris 11.
> 
> So far I faced the same issue as Antony with u_int64_t, but the
> workaround was easy.
> 
> Now it fails like this :
> 
> $ make PROGRAMS="scp" STATIC=1
> gcc -L/usr/local/lib -R/usr/local/lib -static -o scp scp.o
> progressmeter.o atomicio.o scpmisc.o compat.o
> ld: fatal: library -lc: not found
> ld: fatal: file processing errors. No output written to scp
> collect2: ld returned 1 exit status
> make: *** [scp] Erreur 1
> 
> Obviously /usr/lib is not the correct path, but what is this library it
> is complaining about?
> I tried in vain to adjust this path to /usr/lib and /lib.
> Any idea?
> 
> Sadly I know little about Solaris and programming stuff...
> 
> Thank you in advance,
> 
> Best regards,
> -- 
> phocean

From ska-dietlibc at skarnet.org  Sun Nov  6 21:27:09 2011
From: ska-dietlibc at skarnet.org (Laurent Bercot)
Date: Sun, 6 Nov 2011 14:27:09 +0100
Subject: [solaris] library -lc: not found
In-Reply-To: <4EB56BD9.90802@phocean.net>
References: <4EB56BD9.90802@phocean.net>
Message-ID: <20111106132709.GA11664@skarnet.org>

> $ make PROGRAMS="scp" STATIC=1
> gcc -L/usr/local/lib -R/usr/local/lib -static -o scp scp.o
> progressmeter.o atomicio.o scpmisc.o compat.o
> ld: fatal: library -lc: not found

 As Matt said, you cannot make static programs on Solaris.
 Solaris does not ship with a libc.a, only a libc.so.

 This would be an excellent reason to change operating systems and
use something less braindead and obsolete.

 But if you're hell-bent on using Solaris, just remove the STATIC=1
part of your command line and dropbear should compile without trouble,
it will simply use dynamic libraries.

-- 
 Laurent

From 0x90 at phocean.net  Mon Nov  7 00:33:45 2011
From: 0x90 at phocean.net (phocean)
Date: Sun, 06 Nov 2011 17:33:45 +0100
Subject: [solaris] library -lc: not found
In-Reply-To: <4EB5E1CF.4020904@landley.net>
References: <4EB56BD9.90802@phocean.net> <4EB5E1CF.4020904@landley.net>
Message-ID: <4EB6B6E9.8030401@phocean.net>

Le 06/11/2011 02:24, Rob Landley a ?crit :
> On 11/05/2011 12:01 PM, phocean wrote:
>> Now it fails like this :
>>
>> $ make PROGRAMS="scp" STATIC=1
>> gcc -L/usr/local/lib -R/usr/local/lib -static -o scp scp.o
>> progressmeter.o atomicio.o scpmisc.o compat.o
>> ld: fatal: library -lc: not found
>> ld: fatal: file processing errors. No output written to scp
>> collect2: ld returned 1 exit status
>> make: *** [scp] Erreur 1
>>
>> Obviously /usr/lib is not the correct path, but what is this library it
>> is complaining about?
> 
> That would be the C library.  libc.  I.E. the library containign
> standard C functions like printf.  When you build "hello world", it
> links against libc.
> 
> Your bug report boils down to "my toolchain is so broken it can't build
> hello world".  This is not a dropbear issue.
> 
> Why are you building a program for solaris, didn't Sun go out of
> business and oracle terminate their abandonware version?
> 
> Rob

Oracle abandonned OpenSolaris, not Solaris which is at version 11 now.
And unfortunately, I still have a bunch of industrial devices running
various versions of Solaris to deal with a few more years...

-- 
phocean

From 0x90 at phocean.net  Mon Nov  7 00:41:10 2011
From: 0x90 at phocean.net (phocean)
Date: Sun, 06 Nov 2011 17:41:10 +0100
Subject: [solaris] library -lc: not found
In-Reply-To: <20111106062013.GZ20075@ucc.gu.uwa.edu.au>
References: <4EB56BD9.90802@phocean.net>
	<20111106062013.GZ20075@ucc.gu.uwa.edu.au>
Message-ID: <4EB6B8A6.70805@phocean.net>

I think you are right, an issue with nanosleep would make a lot of sense.

I did not need to make the change for nanosleep, and that would mean it
is in the libc... which fails to build statically.

I am going to find out a previous version of Solaris or OpenSolaris to
test it out.

Thanks.

Le 06/11/2011 07:20, Matt Johnston a ?crit :
> I think you cannot build static programs on Solaris. From the
> cc manpage
> 
>   Note: Many system libraries, such as libc, are only
>   available as dynamic libraries in the Solaris 64-bit
>   compilation environment. Therefore, do not use -Bstatic
>   as the last toggle on the command line.
> 
> I guess it's similar to Linux except glibc will link then fail at runtime :)
> 
> Antony mentioned needing the realtime library for nanosleep,
> but to me it looks like it's in the main libc on Solaris 11.
> Did you need to change that?
> 
> Cheers,
> Matt
> 
> On Sat, Nov 05, 2011 at 06:01:13PM +0100, phocean wrote:
>> Hi all,
>>
>> I am trying to compile scp on Solaris 11.
>>
>> So far I faced the same issue as Antony with u_int64_t, but the
>> workaround was easy.
>>
>> Now it fails like this :
>>
>> $ make PROGRAMS="scp" STATIC=1
>> gcc -L/usr/local/lib -R/usr/local/lib -static -o scp scp.o
>> progressmeter.o atomicio.o scpmisc.o compat.o
>> ld: fatal: library -lc: not found
>> ld: fatal: file processing errors. No output written to scp
>> collect2: ld returned 1 exit status
>> make: *** [scp] Erreur 1
>>
>> Obviously /usr/lib is not the correct path, but what is this library it
>> is complaining about?
>> I tried in vain to adjust this path to /usr/lib and /lib.
>> Any idea?
>>
>> Sadly I know little about Solaris and programming stuff...
>>
>> Thank you in advance,
>>
>> Best regards,
>> -- 
>> phocean


-- 
phocean

From 0x90 at phocean.net  Mon Nov  7 00:44:12 2011
From: 0x90 at phocean.net (phocean)
Date: Sun, 06 Nov 2011 17:44:12 +0100
Subject: [solaris] library -lc: not found
In-Reply-To: <20111106132709.GA11664@skarnet.org>
References: <4EB56BD9.90802@phocean.net> <20111106132709.GA11664@skarnet.org>
Message-ID: <4EB6B95C.8040409@phocean.net>

Le 06/11/2011 14:27, Laurent Bercot a ?crit :
>> $ make PROGRAMS="scp" STATIC=1
>> gcc -L/usr/local/lib -R/usr/local/lib -static -o scp scp.o
>> progressmeter.o atomicio.o scpmisc.o compat.o
>> ld: fatal: library -lc: not found
> 
>  As Matt said, you cannot make static programs on Solaris.
>  Solaris does not ship with a libc.a, only a libc.so.
> 
>  This would be an excellent reason to change operating systems and
> use something less braindead and obsolete.
> 
>  But if you're hell-bent on using Solaris, just remove the STATIC=1
> part of your command line and dropbear should compile without trouble,
> it will simply use dynamic libraries.
> 

If only I could... But believe me, you can't change an industrial device
easily !

The reason why I want it to build it statically, is that I wanted it to
run on several versions of Solaris, without messing up with library
issues (though I can't compile anything directly on such devices).

-- 
phocean

From antony at pavlenko.net  Mon Nov  7 05:33:11 2011
From: antony at pavlenko.net (Antony Pavlenko)
Date: Mon, 7 Nov 2011 01:33:11 +0400
Subject: [solaris] library -lc: not found
In-Reply-To: <4EB6B95C.8040409@phocean.net>
References: <4EB56BD9.90802@phocean.net> <20111106132709.GA11664@skarnet.org>
	<4EB6B95C.8040409@phocean.net>
Message-ID: <CAFq5PkVN=jFNnLwMZJz1Yn-1LNsGM5r1Spz1+0QCjQ0cvhCaMA@mail.gmail.com>

First of all there is a great article from linker guru Rod Evans about
static linking :
https://blogs.oracle.com/rie/entry/static_linking_where_did_it
I have created a package with  dynamically linked executables. As it
doesn't depend from any external packages ( libs ) it can be easily
installed at any Solaris system.  I have installed it at hundreds of
servers ( thank you Matt for a great piece of code! ) with out of any
problems. I will be happy to help you, if you will have any problems.

Wbr,
Antony Pavlenko

On Sun, Nov 6, 2011 at 8:44 PM, phocean <0x90 at phocean.net> wrote:

> Le 06/11/2011 14:27, Laurent Bercot a ?crit :
> >> $ make PROGRAMS="scp" STATIC=1
> >> gcc -L/usr/local/lib -R/usr/local/lib -static -o scp scp.o
> >> progressmeter.o atomicio.o scpmisc.o compat.o
> >> ld: fatal: library -lc: not found
> >
> >  As Matt said, you cannot make static programs on Solaris.
> >  Solaris does not ship with a libc.a, only a libc.so.
> >
> >  This would be an excellent reason to change operating systems and
> > use something less braindead and obsolete.
> >
> >  But if you're hell-bent on using Solaris, just remove the STATIC=1
> > part of your command line and dropbear should compile without trouble,
> > it will simply use dynamic libraries.
> >
>
> If only I could... But believe me, you can't change an industrial device
> easily !
>
> The reason why I want it to build it statically, is that I wanted it to
> run on several versions of Solaris, without messing up with library
> issues (though I can't compile anything directly on such devices).
>
> --
> phocean
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20111107/5bea5b9b/attachment.htm 

From 0x90 at phocean.net  Mon Nov  7 06:05:09 2011
From: 0x90 at phocean.net (phocean)
Date: Sun, 06 Nov 2011 23:05:09 +0100
Subject: [solaris] library -lc: not found
In-Reply-To: <CAFq5PkVN=jFNnLwMZJz1Yn-1LNsGM5r1Spz1+0QCjQ0cvhCaMA@mail.gmail.com>
References: <4EB56BD9.90802@phocean.net> <20111106132709.GA11664@skarnet.org>
	<4EB6B95C.8040409@phocean.net>
	<CAFq5PkVN=jFNnLwMZJz1Yn-1LNsGM5r1Spz1+0QCjQ0cvhCaMA@mail.gmail.com>
Message-ID: <4EB70495.40605@phocean.net>

Thank you Antony. It is a nice article indeed, very instructive.

I see now my understanding of static linking was terribly bad and I was
taking the wrong path.

So, I just compiled scp dynamically and will test it out soon on
production machines.

But with this :
$ ldd ./scp
libc.so.1 =>     /lib/libc.so.1
libm.so.2 =>     /lib/libm.so.2

... I guess there should not be any issue...

I will give a short update here soon.

Thanks again to all of you for nice support.

-- 
phocean

Le 06/11/2011 22:33, Antony Pavlenko a ?crit :
> First of all there is a great article from linker guru Rod Evans about
> static linking :
> https://blogs.oracle.com/rie/entry/static_linking_where_did_it
> I have created a package with  dynamically linked executables. As it
> doesn't depend from any external packages ( libs ) it can be easily
> installed at any Solaris system.  I have installed it at hundreds of
> servers ( thank you Matt for a great piece of code! ) with out of any
> problems. I will be happy to help you, if you will have any problems.
> 
> Wbr,
> Antony Pavlenko
> 
> On Sun, Nov 6, 2011 at 8:44 PM, phocean <0x90 at phocean.net
> <mailto:0x90 at phocean.net>> wrote:
> 
>     Le 06/11/2011 14:27, Laurent Bercot a ?crit :
>     >> $ make PROGRAMS="scp" STATIC=1
>     >> gcc -L/usr/local/lib -R/usr/local/lib -static -o scp scp.o
>     >> progressmeter.o atomicio.o scpmisc.o compat.o
>     >> ld: fatal: library -lc: not found
>     >
>     >  As Matt said, you cannot make static programs on Solaris.
>     >  Solaris does not ship with a libc.a, only a libc.so.
>     >
>     >  This would be an excellent reason to change operating systems and
>     > use something less braindead and obsolete.
>     >
>     >  But if you're hell-bent on using Solaris, just remove the STATIC=1
>     > part of your command line and dropbear should compile without trouble,
>     > it will simply use dynamic libraries.
>     >
> 
>     If only I could... But believe me, you can't change an industrial device
>     easily !
> 
>     The reason why I want it to build it statically, is that I wanted it to
>     run on several versions of Solaris, without messing up with library
>     issues (though I can't compile anything directly on such devices).
> 
>     --
>     phocean
> 
> 

From rob at landley.net  Mon Nov  7 01:16:48 2011
From: rob at landley.net (Rob Landley)
Date: Sun, 06 Nov 2011 11:16:48 -0600
Subject: [solaris] library -lc: not found
In-Reply-To: <20111106062013.GZ20075@ucc.gu.uwa.edu.au>
References: <4EB56BD9.90802@phocean.net>
	<20111106062013.GZ20075@ucc.gu.uwa.edu.au>
Message-ID: <4EB6C100.7000503@landley.net>

On 11/06/2011 01:20 AM, Matt Johnston wrote:
> I think you cannot build static programs on Solaris. From the
> cc manpage
> 
>   Note: Many system libraries, such as libc, are only
>   available as dynamic libraries in the Solaris 64-bit
>   compilation environment. Therefore, do not use -Bstatic
>   as the last toggle on the command line.
> 
> I guess it's similar to Linux except glibc will link then fail at runtime :)

It fails at build time on Linux in the toolchains I've tried.  Some
distros have the static libraries in a separate package.  This came up
with Wolfgang Denk tested my build system a couple years ago, and this
was one of the many, many ways the cross compiling part broke for him:

  http://landley.net/notes-2010.html#13-03-2010

Rob

From matt at ucc.asn.au  Tue Nov  8 00:09:33 2011
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue, 8 Nov 2011 00:09:33 +0800
Subject: Converting dropbear to mercurial.
In-Reply-To: <4E6C1A5A.9050904@landley.net>
References: <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97A8E@MCHP057A.global-ad.net>
	<4E66A2FF.5080707@gentoo.org>
	<8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97ABF@MCHP057A.global-ad.net>
	<4E66AF1F.2080106@gentoo.org>
	<20110907105848.GS1128@ucc.gu.uwa.edu.au>
	<4E6C1A5A.9050904@landley.net>
Message-ID: <20111107160933.GG20075@ucc.gu.uwa.edu.au>

On Sat, Sep 10, 2011 at 09:18:02PM -0500, Rob Landley wrote:

> Have you tried http://mercurial.selenic.com/wiki/ConvertExtension ?
> 
> I don't know the state of monotone support in mercurial, but I've never
> used monotone, so...

I've finally converted the Dropbear repository to Mercurial
using "convert". I had to hack out the rename tracking to
use something simpler (just looking at before/after manifests).

https://secure.ucc.asn.au/hg/dropbear/ is the repository
URL, the conversion looks OK to me. I'm hoping to bundle up
a release shortly, I think most patches have now been
applied.

Cheers,
Matt

From matt at ucc.asn.au  Tue Nov  8 21:09:24 2011
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue, 8 Nov 2011 21:09:24 +0800
Subject: Dropbear 2011.54 released
Message-ID: <20111108130924.GM20075@ucc.gu.uwa.edu.au>

Hi all,

A new version 2011.54 of Dropbear SSH is available from
https://matt.ucc.asn.au/dropbear/dropbear.html

Changes are listed below. Note the new version numbering
scheme. Source is now stored with Mercurial at
https://secure.ucc.asn.au/hg/dropbear/

Cheers,
Matt

2011.54 - Tuesday 8 November 2011

- Building statically works again, broke in 0.53 and 0.53.1

- Fix crash when forwarding with -R

- Fixed various leaks found by Klocwork analysis software, thanks to them for
  running it

- Set IPTOS_LOWDELAY for IPv6, thanks to Dave Taht

- Bind to sockets with IPV6_V6ONLY so that it works properly on systems
  regardless of the system-wide setting

- Added ALLOW_BLANK_PASSWORD option. Dropbear also now allows public key logins
  to accounts with a blank password. Thanks to Rob Landley

- Fixed case where "-K 1" keepalive for dbclient would cause a SSH_MSG_IGNORE
  packet to be sent

- Avoid some memory allocations in big number maths routines, improves
  performance slightly

- Fix symlink target for installdropbearmulti with DESTDIR set, thanks to
  Scottie Shore

- When requesting server allocated remote ports (-R 0:host:port) print a
  message informing what the port is, thanks to Ali Onur Uyar.

- New version numbering scheme.

Source repository has now migrated to Mercurial at 
https://secure.ucc.asn.au/hg/dropbear/graph/default

From fabriziobertocci at gmail.com  Tue Nov  8 23:47:43 2011
From: fabriziobertocci at gmail.com (Fabrizio Bertocci)
Date: Tue, 8 Nov 2011 10:47:43 -0500
Subject: Dropbear 2011.54 released
In-Reply-To: <20111108130924.GM20075@ucc.gu.uwa.edu.au>
References: <20111108130924.GM20075@ucc.gu.uwa.edu.au>
Message-ID: <CADtzkx62_pAUAEAQURW11vxQE690GZU74c3eQTnDg3E6WaDyLg@mail.gmail.com>

I'm sure you have received plenty of emails like this, but I'm just adding
to the choir:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
  Big thank you very much for the incredible effort you are putting on
Dropbear!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

We are a small start-up and we are using dropbear (I'm two version behind
now, but that is very stable and working great for us) for maintaining a
secure, persistent connection (with two tunnels) between our embedded
devices and our data center (I think I found the problem related to the
keep-alive and liveliness)
I might consider migrating to the newest version in our next major version
(our current version requires patching the source code).

Regards,
Fabrizio Bertocci

On Tue, Nov 8, 2011 at 8:09 AM, Matt Johnston <matt at ucc.asn.au> wrote:

> Hi all,
>
> A new version 2011.54 of Dropbear SSH is available from
> https://matt.ucc.asn.au/dropbear/dropbear.html
>
> Changes are listed below. Note the new version numbering
> scheme. Source is now stored with Mercurial at
> https://secure.ucc.asn.au/hg/dropbear/
>
> Cheers,
> Matt
>
> 2011.54 - Tuesday 8 November 2011
>
> - Building statically works again, broke in 0.53 and 0.53.1
>
> - Fix crash when forwarding with -R
>
> - Fixed various leaks found by Klocwork analysis software, thanks to them
> for
>  running it
>
> - Set IPTOS_LOWDELAY for IPv6, thanks to Dave Taht
>
> - Bind to sockets with IPV6_V6ONLY so that it works properly on systems
>  regardless of the system-wide setting
>
> - Added ALLOW_BLANK_PASSWORD option. Dropbear also now allows public key
> logins
>  to accounts with a blank password. Thanks to Rob Landley
>
> - Fixed case where "-K 1" keepalive for dbclient would cause a
> SSH_MSG_IGNORE
>  packet to be sent
>
> - Avoid some memory allocations in big number maths routines, improves
>  performance slightly
>
> - Fix symlink target for installdropbearmulti with DESTDIR set, thanks to
>  Scottie Shore
>
> - When requesting server allocated remote ports (-R 0:host:port) print a
>  message informing what the port is, thanks to Ali Onur Uyar.
>
> - New version numbering scheme.
>
> Source repository has now migrated to Mercurial at
> https://secure.ucc.asn.au/hg/dropbear/graph/default
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20111108/4e22ec8b/attachment.htm 

From gustavo at zacarias.com.ar  Wed Nov  9 23:35:53 2011
From: gustavo at zacarias.com.ar (Gustavo Zacarias)
Date: Wed, 09 Nov 2011 12:35:53 -0300
Subject: [PATCH] Fix non-IPv6 compilation for 2011.54
Message-ID: <09b0a29d146381846747bb4ddd76d27d@zacarias.com.ar>

This patch allows the recent 2011.54 release to build on non-IPv6 
enabled toolchains.
Since IPPROTO_IPV6 is defined even if the toolchain is not IPv6-enabled 
(uClibc 0.9.32) then just depend on IPV6_TCLASS for sockopt instead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dropbear-2011.54-no-ipv6.patch
Type: text/x-diff
Size: 507 bytes
Desc: not available
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20111109/2ffcc2bc/attachment.patch 

From v.tolstov at selfip.ru  Thu Nov 10 00:30:55 2011
From: v.tolstov at selfip.ru (Vasiliy Tolstov)
Date: Wed, 9 Nov 2011 20:30:55 +0400
Subject: Dropbear 2011.54 released
In-Reply-To: <20111108130924.GM20075@ucc.gu.uwa.edu.au>
References: <20111108130924.GM20075@ucc.gu.uwa.edu.au>
Message-ID: <CACaajQsfJ6t_OQUwcwMGfuqS7uoLPwu9GV-5m1crTPPerjt6HQ@mail.gmail.com>

2011/11/8 Matt Johnston <matt at ucc.asn.au>:
> Hi all,
>
> A new version 2011.54 of Dropbear SSH is available from
> https://matt.ucc.asn.au/dropbear/dropbear.html
>
> Changes are listed below. Note the new version numbering
> scheme. Source is now stored with Mercurial at
> https://secure.ucc.asn.au/hg/dropbear/


Great! Does it possible to run dropbear via xinetd? (i need it for
busybox and for normal mode under systemd =))

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov at selfip.ru
jabber: vase at selfip.ru

From matt at ucc.asn.au  Thu Nov 10 06:52:45 2011
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu, 10 Nov 2011 06:52:45 +0800
Subject: Dropbear 2011.54 released
In-Reply-To: <CACaajQsfJ6t_OQUwcwMGfuqS7uoLPwu9GV-5m1crTPPerjt6HQ@mail.gmail.com>
References: <20111108130924.GM20075@ucc.gu.uwa.edu.au>
	<CACaajQsfJ6t_OQUwcwMGfuqS7uoLPwu9GV-5m1crTPPerjt6HQ@mail.gmail.com>
Message-ID: <11a50850-6ade-461f-aed4-05922927ce81@email.android.com>

Yep, it's on the webpage feature list. 

Matt 

Vasiliy Tolstov <v.tolstov at selfip.ru> wrote:

2011/11/8 Matt Johnston <matt at ucc.asn.au>:
> Hi all,
>
> A new version 2011.54 of Dropbear SSH is available from
> https://matt.ucc.asn.au/dropbear/dropbear.html
>
> Changes are listed below. Note the new version numbering
> scheme. Source is now stored with Mercurial at
> https://secure.ucc.asn.au/hg/dropbear/


Great! Does it possible to run dropbear via xinetd? (i need it for
busybox and for normal mode under systemd =))

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov at selfip.ru
jabber: vase at selfip.ru

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

From ocelot1985 at 163.com  Mon Nov 14 09:21:00 2011
From: ocelot1985 at 163.com (ocelot1985)
Date: Mon, 14 Nov 2011 09:21:00 +0800 (CST)
Subject: dropbear's environment variables
Message-ID: <4f21a77e.c604.1339fa9bb4d.Coremail.ocelot1985@163.com>

 Hi, guys:

In my job, I need to use quicksshd which is android app  as my sshd service,  and quicksshd is based on dropbear.
The problem is : when I use the command " ssh host_ip 'cmd'  ", It cannot be executed  because  the envionment variables is different with the situation when i use ssh to login to the host which is running dropbear.

So is there a way to reset the default environment variables when using the command " ssh  host_ip 'cmd'  " on termianl ?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20111114/e699590b/attachment.htm 

From matt at ucc.asn.au  Tue Nov 15 19:55:00 2011
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue, 15 Nov 2011 19:55:00 +0800
Subject: dropbear's environment variables
In-Reply-To: <4f21a77e.c604.1339fa9bb4d.Coremail.ocelot1985@163.com>
References: <4f21a77e.c604.1339fa9bb4d.Coremail.ocelot1985@163.com>
Message-ID: <20111115115500.GS20075@ucc.gu.uwa.edu.au>

It sounds like there are settings in ~/.bash_login or
similar, which only gets evaluated when you get an
interactive login shell (not when you run a command).

You could try moving the commands to ~/.bashrc (or similar,
I don't know what shell you are using). 

Alternative you you could run 

ssh host_ip 'env var=value var2=val2 cmd'

Which will should the variables you require. Another
approach might be to run bash --login -c 'cmd' as your
command (I'm assuming bash, other shells probably have
similar files and arguments to set).

Cheers,
Matt

On Mon, Nov 14, 2011 at 09:21:00AM +0800, ocelot1985 wrote:
>  Hi, guys:
> 
> In my job, I need to use quicksshd which is android app  as my sshd service,  and quicksshd is based on dropbear.
> The problem is : when I use the command " ssh host_ip 'cmd'  ", It cannot be executed  because  the envionment variables is different with the situation when i use ssh to login to the host which is running dropbear.
> 
> So is there a way to reset the default environment variables when using the command " ssh  host_ip 'cmd'  " on termianl ?
> 
> Thanks!

From spenser309 at gmail.com  Sat Nov 19 09:37:36 2011
From: spenser309 at gmail.com (Spenser Gilliland)
Date: Fri, 18 Nov 2011 19:37:36 -0600
Subject: Github
Message-ID: <CA+appbOTYA98QH-73efZkep7uA7nzj9Nq4dnyAX3xj=bTTxNkg@mail.gmail.com>

Hi,

I have a script (below) which updates my github clone of the monotone
repo weekly.  Is the monotone repo still the best place to get the
head of development?  I read about a mercurial server being set up in
a previous email.

Thanks,
Spenser

#!/bin/bash

# This Script copies the montone repo for dropbear to github.
cd /tmp
mtn -d dropbear.db db init
mtn -d dropbear.db pull monotone.ucc.asn.au "au.asn.ucc.matt.dropbear*"

# Get rid of the following tags as they cannot propogate to git.
mtn -d dropbear.db -b au.asn.ucc.matt.dropbear co dropbear
cd dropbear
mtn db kill_tag_locally t:ltc-0.95-db-merge1
mtn db kill_tag_locally t:ltc-0.95-orig
mkdir ../dropbear.git
cd ../dropbear.git
git init
mtn --db ../dropbear.db git_export | git fast-import
git branch -M au.asn.ucc.matt.dropbear master
git remote add origin git at github.com:Spenser309/dropbear
git push --mirror
rm -rf /tmp/dropbear*

-- 
Spenser Gilliland
Computer Engineer
Illinois Institute of Technology

From matt at ucc.asn.au  Sat Nov 19 19:57:49 2011
From: matt at ucc.asn.au (Matt Johnston)
Date: Sat, 19 Nov 2011 19:57:49 +0800
Subject: Github
In-Reply-To: <CA+appbOTYA98QH-73efZkep7uA7nzj9Nq4dnyAX3xj=bTTxNkg@mail.gmail.com>
References: <CA+appbOTYA98QH-73efZkep7uA7nzj9Nq4dnyAX3xj=bTTxNkg@mail.gmail.com>
Message-ID: <20111119115749.GH21256@ucc.gu.uwa.edu.au>

Hi,

The new development repository is
https://secure.ucc.asn.au/hg/dropbear

That has all the old monotone history imported, with branch
names changed. I'm not quite sure the best way for you to
switch to that server.

I only noticed your github conversion after getting the
Mercurial repository going (with a fair bit of hassle) -
when I tried using monotone's git export a while ago it
didn't seem to export proper branch history. It all looks
fine in Github there though. (Or perhaps it was that
git->mercurial conversion didn't preserve branch history, I
forget).

Cheers,
Matt

On Fri, Nov 18, 2011 at 07:37:36PM -0600, Spenser Gilliland wrote:
> Hi,
> 
> I have a script (below) which updates my github clone of the monotone
> repo weekly.  Is the monotone repo still the best place to get the
> head of development?  I read about a mercurial server being set up in
> a previous email.
> 
> Thanks,
> Spenser
> 
> #!/bin/bash
> 
> # This Script copies the montone repo for dropbear to github.
> cd /tmp
> mtn -d dropbear.db db init
> mtn -d dropbear.db pull monotone.ucc.asn.au "au.asn.ucc.matt.dropbear*"
> 
> # Get rid of the following tags as they cannot propogate to git.
> mtn -d dropbear.db -b au.asn.ucc.matt.dropbear co dropbear
> cd dropbear
> mtn db kill_tag_locally t:ltc-0.95-db-merge1
> mtn db kill_tag_locally t:ltc-0.95-orig
> mkdir ../dropbear.git
> cd ../dropbear.git
> git init
> mtn --db ../dropbear.db git_export | git fast-import
> git branch -M au.asn.ucc.matt.dropbear master
> git remote add origin git at github.com:Spenser309/dropbear
> git push --mirror
> rm -rf /tmp/dropbear*
> 
> -- 
> Spenser Gilliland
> Computer Engineer
> Illinois Institute of Technology

From matt at ucc.asn.au  Mon Nov 28 21:20:11 2011
From: matt at ucc.asn.au (Matt Johnston)
Date: Mon, 28 Nov 2011 21:20:11 +0800
Subject: Converting dropbear to mercurial.
In-Reply-To: <9A8E6319-D781-4969-B5CF-E1F57143A4BD@gmail.com>
References: <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97A8E@MCHP057A.global-ad.net>
	<4E66A2FF.5080707@gentoo.org>
	<8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97ABF@MCHP057A.global-ad.net>
	<4E66AF1F.2080106@gentoo.org>
	<20110907105848.GS1128@ucc.gu.uwa.edu.au>
	<4E6C1A5A.9050904@landley.net>
	<3C66135B-0909-49C5-B87F-7DDB09FA2CA1@gmail.com>
	<20110911134830.GF1128@ucc.gu.uwa.edu.au>
	<9A8E6319-D781-4969-B5CF-E1F57143A4BD@gmail.com>
Message-ID: <20111128132011.GC14214@ucc.gu.uwa.edu.au>

Hi,

In your converted repository did it end up with a "demos"
directory and "changes" file in the top level of the tip of
au.asn.ucc.matt.dropbear branch? That indicates that the
conversion didn't work correctly.

I ended up converting my repository with the attached patch
- there isn't too much rename history that I care about, so
it purely looks at manifests revision-by-revision.

The converted repository now lives at
https://secure.ucc.asn.au/hg/dropbear/

Thanks,
Matt

On Mon, Nov 21, 2011 at 09:01:03AM -0600, Augie Fackler wrote:
> I just got a chance to take a look at this, and the cut down repo you provided converted without a hitch. Should I try it on the full-size repository? I don't see any obviously related changesets in hgext.convert's recent history.
> 
> 
> On Sep 11, 2011, at 8:48 AM, Matt Johnston wrote:
> 
> > On Sat, Sep 10, 2011 at 10:07:49PM -0500, Augie Fackler wrote:
> >>> Have you tried http://mercurial.selenic.com/wiki/ConvertExtension ?
> >>> 
> >>> I don't know the state of monotone support in mercurial, but I've never
> >>> used monotone, so...
> >> 
> >> Convert should work. If not, feel encouraged to give me the right mtn spell to get a clone of your mtn and I'll gladly poke it to see what's wrong.
> > 
> > The monotone converter gets confused by me doing 
> > rename "" -> "libtomcrypt" on one side of the merge in
> > revision fdf4a7a3b97ae5046139915de7e40399cceb2c01. That
> > happens via monotone's "merge_into_dir" command - I moved
> > the root directory of the ...ltc.dropbear  branch into a
> > subdirectory of the main dropbear branch.
> > 
> > The end result is that an old version of "changes" appears
> > in the toplevel directory of au.asn.ucc.matt.dropbear
> > branch, as well as the correct version at
> > "libtomcrypt/changes". (The same happens for various other
> > files there too).
> > 
> > Looking at the code in montone.py's getchanges() I can't see
> > how it would work correctly. It's iterating over all
> > renames/adds/deletes, but in a merge each operation will be
> > relative a particular parent revision denoted by the
> > "old_revision" lines.  See
> > http://matt.ucc.asn.au/dropbear/test/fdf4a7a-merge_into_dir.txt
> > for the Monotone revision (from "mtn automate
> > get_revision").
> > 
> > I've tried a few different tweaks but none seemed to 
> > improve things. Unfortunately a simple synthetic testcase
> > doesn't hit the same problem either :(
> > I might try making a simpler getchanges() version that
> > ignores renames and just uses mtn automate's get_manifest_of
> > to figure out the files - my repository I can live without
> > rename/copy tracking.
> > 
> > If you want to look at it I also needed the following for
> > the empty fromdir case to avoid paths with a leading slash.
> > 
> > if fromdir == "":
> >    renamed[tofile] = fromdir + tofile[len(todir)+1:]
> > else:
> >    renamed[tofile] = fromdir + tofile[len(todir):]
> > 
> > I also had to comment out the mercurial_source in convcmd.py
> > - otherwise it would abort before the monotone source was
> > tried. I'll report that one as a separate bug, I assume it
> > would affect any converter below mercurial_source.
> > 
> > I've put a cut down repository at
> > http://matt.ucc.asn.au/dropbear/test/small-dropbear.mtn
> > 
> > Cheers,
> > Matt
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hg-monotone.py.diff
Type: text/x-diff
Size: 3285 bytes
Desc: not available
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20111128/250ad382/attachment.diff 

From christopher.barry at rackwareinc.com  Tue Nov 29 03:09:55 2011
From: christopher.barry at rackwareinc.com (Christopher Barry)
Date: Mon, 28 Nov 2011 14:09:55 -0500
Subject: Converting dropbear to mercurial.
In-Reply-To: <20111128132011.GC14214@ucc.gu.uwa.edu.au>
References: <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97A8E@MCHP057A.global-ad.net>
	<4E66A2FF.5080707@gentoo.org>
	<8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97ABF@MCHP057A.global-ad.net>
	<4E66AF1F.2080106@gentoo.org> <20110907105848.GS1128@ucc.gu.uwa.edu.au>
	<4E6C1A5A.9050904@landley.net>
	<3C66135B-0909-49C5-B87F-7DDB09FA2CA1@gmail.com>
	<20110911134830.GF1128@ucc.gu.uwa.edu.au>
	<9A8E6319-D781-4969-B5CF-E1F57143A4BD@gmail.com>
	<20111128132011.GC14214@ucc.gu.uwa.edu.au>
Message-ID: <1322507395.4734.4.camel@monolith.infinux.org>

On Mon, 2011-11-28 at 21:20 +0800, Matt Johnston wrote:
> Hi,
> 
> In your converted repository did it end up with a "demos"
> directory and "changes" file in the top level of the tip of
> au.asn.ucc.matt.dropbear branch? That indicates that the
> conversion didn't work correctly.
> 
> I ended up converting my repository with the attached patch
> - there isn't too much rename history that I care about, so
> it purely looks at manifests revision-by-revision.
> 
> The converted repository now lives at
> https://secure.ucc.asn.au/hg/dropbear/
> 
> Thanks,
> Matt

forgive my ignorance, but why the move to mercurial as opposed to say
git? Is there a technical reason, or is it simply a personal preference?

Thanks,
-C



From matt at ucc.asn.au  Tue Nov 29 19:30:46 2011
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue, 29 Nov 2011 19:30:46 +0800
Subject: Converting dropbear to mercurial.
In-Reply-To: <1322507395.4734.4.camel@monolith.infinux.org>
References: <4E66A2FF.5080707@gentoo.org>
	<8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97ABF@MCHP057A.global-ad.net>
	<4E66AF1F.2080106@gentoo.org>
	<20110907105848.GS1128@ucc.gu.uwa.edu.au>
	<4E6C1A5A.9050904@landley.net>
	<3C66135B-0909-49C5-B87F-7DDB09FA2CA1@gmail.com>
	<20110911134830.GF1128@ucc.gu.uwa.edu.au>
	<9A8E6319-D781-4969-B5CF-E1F57143A4BD@gmail.com>
	<20111128132011.GC14214@ucc.gu.uwa.edu.au>
	<1322507395.4734.4.camel@monolith.infinux.org>
Message-ID: <20111129113046.GM14214@ucc.gu.uwa.edu.au>

On Mon, Nov 28, 2011 at 02:09:55PM -0500, Christopher Barry wrote:
> 
> forgive my ignorance, but why the move to mercurial as opposed to say
> git? Is there a technical reason, or is it simply a personal preference?

Personal preference mostly. With Mercurial I've found it
easier to get things done without having to poke around in
manpages etc. I guess coming from Monotone might help there
since it seems closer to Mercurial.

Matt

From rob at landley.net  Sun Dec 11 03:29:47 2011
From: rob at landley.net (Rob Landley)
Date: Sat, 10 Dec 2011 13:29:47 -0600
Subject: Converting dropbear to mercurial.
In-Reply-To: <20111129113046.GM14214@ucc.gu.uwa.edu.au>
References: <4E66A2FF.5080707@gentoo.org>	<8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97ABF@MCHP057A.global-ad.net>	<4E66AF1F.2080106@gentoo.org>	<20110907105848.GS1128@ucc.gu.uwa.edu.au>	<4E6C1A5A.9050904@landley.net>	<3C66135B-0909-49C5-B87F-7DDB09FA2CA1@gmail.com>	<20110911134830.GF1128@ucc.gu.uwa.edu.au>	<9A8E6319-D781-4969-B5CF-E1F57143A4BD@gmail.com>	<20111128132011.GC14214@ucc.gu.uwa.edu.au>	<1322507395.4734.4.camel@monolith.infinux.org>
	<20111129113046.GM14214@ucc.gu.uwa.edu.au>
Message-ID: <4EE3B32B.4020402@landley.net>

On 11/29/2011 05:30 AM, Matt Johnston wrote:
> On Mon, Nov 28, 2011 at 02:09:55PM -0500, Christopher Barry wrote:
>>
>> forgive my ignorance, but why the move to mercurial as opposed to say
>> git? Is there a technical reason, or is it simply a personal preference?
> 
> Personal preference mostly. With Mercurial I've found it
> easier to get things done without having to poke around in
> manpages etc. I guess coming from Monotone might help there
> since it seems closer to Mercurial.
> 
> Matt
> 

Coming from _anything_, tracking source history is easier in mercurial
than git.  The user interface of git is epically horrid and constructed
entirely out of magic special cases.

(Alas, it's what the linux kernel uses, so as with windows and the flash
plugin you just sort of have to put up with it.)

Rob