From rogle at css1.net  Fri Jul 15 04:12:57 2016
From: rogle at css1.net (Rob Ogle)
Date: Thu, 14 Jul 2016 16:12:57 -0400
Subject: Dropbear FIPS 104.2
Message-ID: <00b301d1de0c$1cf3d250$56db76f0$@css1.net>

I'm trying to figure out if dropbear is FIPS 104.2 compliant. 
Does anyone know? 

 


From matt at ucc.asn.au  Fri Jul 15 21:39:09 2016
From: matt at ucc.asn.au (Matt Johnston)
Date: Fri, 15 Jul 2016 21:39:09 +0800
Subject: Dropbear FIPS 104.2
In-Reply-To: <00b301d1de0c$1cf3d250$56db76f0$@css1.net>
References: <00b301d1de0c$1cf3d250$56db76f0$@css1.net>
Message-ID: <A1E89012-65B3-47B1-AFA7-B9DCD95EEDA2@ucc.asn.au>

Hi Rob,

I haven't heard of anyone getting FIPS certification for Dropbear.

Cheers,
Matt

> On Fri 15/7/2016, at 4:12 am, Rob Ogle <rogle at css1.net> wrote:
> 
> I'm trying to figure out if dropbear is FIPS 104.2 compliant. 
> Does anyone know? 
> 
> 
> 


From matt at ucc.asn.au  Thu Jul 21 23:31:40 2016
From: matt at ucc.asn.au (Matt Johnston)
Date: Thu, 21 Jul 2016 23:31:40 +0800
Subject: Dropbear 2016.74, security updates
Message-ID: <20160721153140.GI23300@ucc.gu.uwa.edu.au>

Hi all,

Dropbear 2016.74 is released. This includes fixes for a few
security issues. Further details will be published by Beyond
Security in a week or so, I will update CVE numbers when available.

Downloads are at https://matt.ucc.asn.au/dropbear/dropbear.html

I strongly advise upgrading any systems where dbclient or
dropbearkey is used with arguments/input provided from external
sources, or systems where Unix usernames can be chosen
arbitrarily. The release also includes a fix for a
TCP forwarding issue that has affected quite a few people.

Cheers,
Matt

2016.74 - 21 July 2016

- Security: Message printout was vulnerable to format string injection.

  If specific usernames including "%" symbols can be created on a system
  (validated by getpwnam()) then an attacker could run arbitrary code as root
  when connecting to Dropbear server.

  A dbclient user who can control username or host arguments could potentially
  run arbitrary code as the dbclient user. This could be a problem if scripts
  or webpages pass untrusted input to the dbclient program.

- Security: dropbearconvert import of OpenSSH keys could run arbitrary code as
  the local dropbearconvert user when parsing malicious key files

- Security: dbclient could run arbitrary code as the local dbclient user if
  particular -m or -c arguments are provided. This could be an issue where
  dbclient is used in scripts.

- Security: dbclient or dropbear server could expose process memory to the
  running user if compiled with DEBUG_TRACE and running with -v

  The security issues were reported by an anonymous researcher working with
  Beyond Security's SecuriTeam Secure Disclosure www.beyondsecurity.com/ssd.html

- Fix port forwarding failure when connecting to domains that have both
  IPv4 and IPv6 addresses. The bug was introduced in 2015.68

- Fix 100% CPU use while waiting for rekey to complete. Thanks to Zhang Hui P
  for the patch

From andbain at microsoft.com  Tue Jul 26 17:43:33 2016
From: andbain at microsoft.com (Andrew Bainbridge)
Date: Tue, 26 Jul 2016 09:43:33 +0000
Subject: Building with Musl
Message-ID: <b18a9c56cd204f6aa50ef74ac45e01c6@DB3PR30MB026.064d.mgd.msft.net>

Hi all

Are there any instructions on how to build Dropbear with Musl (an alternative libc)? There's a brief mention of it on the Dropbear homepage, but nothing in INSTALL.

I'm building on a Raspberry Pi 3, running Raspbian 8 (Jesse). I'm attempting to build a dbclient that will run on a slightly odd Qualcomm Snapdragon based embedded Linux device. Both the Pi and the Snapdragon use the ARMv7 instruction set, so this should be easy.

Here's what I've tried...

Got https://www.musl-libc.org/releases/musl-1.1.15.tar.gz.
./configure and then make install. All good.

Got http://zlib.net/zlib-1.2.8.tar.xz.
export PATH="$PATH:/usr/local/musl/bin"
export CC=musl-gcc
./configure --static. make. All good.

Got https://matt.ucc.asn.au/dropbear/releases/dropbear-2016.73.tar.bz2.
export CFLAGS="-I ../zlib-1.2.8"
export LDFLAGS="-L ../zlib-1.2.8"
./configure
make PROGRAMS="dbclient" STATIC=1
Not all good :-(

Lots of stuff built. I've got libtommath.a and libtomcrypt.a. But make dies saying:

musl-gcc -I ../zlib-1.2.8 -I./libtomcrypt/src/headers/ -I. -I.  -I../zlib-1.2.8 -DDROPBEAR_CLIENT   -c -o dbutil.o dbutil.c
In file included from dbutil.c:64:0:
includes.h:160:25: fatal error: linux/types.h: No such file or directory
#include <linux/types.h>
                         ^
compilation terminated.
<builtin>: recipe for target 'dbutil.o' failed
make: *** [dbutil.o] Error 1

I?m pretty sure a Musl build should even try to #include linux/types.h. Any ideas?

Thanks,
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20160726/fda8f0c5/attachment-0001.htm 

From annulen at yandex.ru  Tue Jul 26 17:48:20 2016
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Tue, 26 Jul 2016 12:48:20 +0300
Subject: Building with Musl
In-Reply-To: <b18a9c56cd204f6aa50ef74ac45e01c6@DB3PR30MB026.064d.mgd.msft.net>
References: <b18a9c56cd204f6aa50ef74ac45e01c6@DB3PR30MB026.064d.mgd.msft.net>
Message-ID: <506521469526500@web11j.yandex.ru>



26.07.2016, 12:46, "Andrew Bainbridge" <andbain at microsoft.com>:
> Hi all
>
> Are there any instructions on how to build Dropbear with Musl (an alternative libc)? There's a brief mention of it on the Dropbear homepage, but nothing in INSTALL.
>
> I'm building on a Raspberry Pi 3, running Raspbian 8 (Jesse). I'm attempting to build a dbclient that will run on a slightly odd Qualcomm Snapdragon based embedded Linux device. Both the Pi and the Snapdragon use the ARMv7 instruction set, so this should be easy.
>
> Here's what I've tried...
>
> Got https://www.musl-libc.org/releases/musl-1.1.15.tar.gz.
>
> ./configure and then make install. All good.
>
> Got http://zlib.net/zlib-1.2.8.tar.xz.
>
> export PATH="$PATH:/usr/local/musl/bin"
>
> export CC=musl-gcc
>
> ./configure --static. make. All good.
>
> Got https://matt.ucc.asn.au/dropbear/releases/dropbear-2016.73.tar.bz2.
>
> export CFLAGS="-I ../zlib-1.2.8"
>
> export LDFLAGS="-L ../zlib-1.2.8"
>
> ./configure
>
> make PROGRAMS="dbclient" STATIC=1
>
> Not all good :-(
>
> Lots of stuff built. I've got libtommath.a and libtomcrypt.a. But make dies saying:
>
> musl-gcc -I ../zlib-1.2.8 -I./libtomcrypt/src/headers/ -I. -I.? -I../zlib-1.2.8 -DDROPBEAR_CLIENT?? -c -o dbutil.o dbutil.c
>
> In file included from dbutil.c:64:0:
>
> includes.h:160:25: fatal error: linux/types.h: No such file or directory
>
> #include <linux/types.h>
>
> ???????????????????????? ^
>
> compilation terminated.
>
> <builtin>: recipe for target 'dbutil.o' failed
>
> make: *** [dbutil.o] Error 1
>
> I?m pretty sure a Musl build should even try to #include linux/types.h. Any ideas?

Kernel headers are not installed, or compiler does not pick them up.

>
> Thanks,
>
> Andy


-- 
Regards,
Konstantin

From andbain at microsoft.com  Tue Jul 26 18:56:00 2016
From: andbain at microsoft.com (Andrew Bainbridge)
Date: Tue, 26 Jul 2016 10:56:00 +0000
Subject: Building with Musl
In-Reply-To: <506521469526500@web11j.yandex.ru>
References: <b18a9c56cd204f6aa50ef74ac45e01c6@DB3PR30MB026.064d.mgd.msft.net>
	<506521469526500@web11j.yandex.ru>
Message-ID: <ca1cfdda93a24f6297cb58efea90a081@DB3PR30MB026.064d.mgd.msft.net>

Konstantin Tokarev wrote:
>  Kernel headers are not installed, or compiler does not pick them up.

Ah that was the clue I needed, thanks. I'm new at any kind of non-standard compiling on Linux. I didn't know linux/types.h was a kernel header. That tells me that my hope of building on a Pi running a random Linux kernel is not necessarily going to create a binary that works on my embedded device running a different kernel version. It seems I need to do "proper" cross compiling after all.

From andbain at microsoft.com  Tue Jul 26 19:20:01 2016
From: andbain at microsoft.com (Andrew Bainbridge)
Date: Tue, 26 Jul 2016 11:20:01 +0000 (UTC)
Subject: Building with Musl
References: <b18a9c56cd204f6aa50ef74ac45e01c6@DB3PR30MB026.064d.mgd.msft.net>
	<506521469526500@web11j.yandex.ru>
	<ca1cfdda93a24f6297cb58efea90a081@DB3PR30MB026.064d.mgd.msft.net>
Message-ID: <loom.20160726T125925-529@post.gmane.org>

Andrew Bainbridge <andbain <at> microsoft.com> writes:

My embedded device is running Linux 3.4.0. I couldn't find 
a package of kernel 3.4.0 kernel headers available on 
Raspbian package manager, so I installed the nearest, which
was linux-headers-3.6-trunk-rpi. Already, I can see myself 
falling into a rabbit hole.

Then I found lots more compile errors failing to find more
headers. So I ended up with an include path like this:

export CFLAGS="-I ../zlib-1.2.8 -I /usr/src/linux-headers-3.6
-trunk-common/include -I /usr/src/linux-headers-3.6-trunk-
common/arch/arm/include -I /usr/include/arm-linux-gnueabihf"

But then I end up with a error message from line 30 of 
/usr/include/arm-linux-gnueabihf/bits/types.h. The compiler 
complains about the keyword "typedef". The previous line was
#include <bits/wordsize.h>, so presumably that file left the
compiler in a bad state. 

At this point I gave up and removed #includes of 
linux/types.h and linux/pkt_sched.h from dropbear's 
includes.h. Then the only thing that failed to compile was a
couple of places that wanted definitions of 
TC_PRIO_INTERACTIVE_BULK and TC_PRIO_INTERACTIVE. Grepping
the 3.6 kernel headers I installed, I saw that they are
defined as 4 and 6 respectively, so I just pasted those 
values in as literals. This is entirely not cool. I'm 
ashamed. However, the code now compiles and works on the 
embedded device.

I guess me learning how to cross compile properly is
off-topic for this mailing list.


From nsz at port70.net  Tue Jul 26 20:34:46 2016
From: nsz at port70.net (Szabolcs Nagy)
Date: Tue, 26 Jul 2016 14:34:46 +0200
Subject: Building with Musl
In-Reply-To: <loom.20160726T125925-529@post.gmane.org>
References: <b18a9c56cd204f6aa50ef74ac45e01c6@DB3PR30MB026.064d.mgd.msft.net>
	<506521469526500@web11j.yandex.ru>
	<ca1cfdda93a24f6297cb58efea90a081@DB3PR30MB026.064d.mgd.msft.net>
	<loom.20160726T125925-529@post.gmane.org>
Message-ID: <20160726123446.GS19691@port70.net>

* Andrew Bainbridge <andbain at microsoft.com> [2016-07-26 11:20:01 +0000]:
> Andrew Bainbridge <andbain <at> microsoft.com> writes:
> 
> My embedded device is running Linux 3.4.0. I couldn't find 
> a package of kernel 3.4.0 kernel headers available on 
> Raspbian package manager, so I installed the nearest, which
> was linux-headers-3.6-trunk-rpi. Already, I can see myself 
> falling into a rabbit hole.
> 
> Then I found lots more compile errors failing to find more
> headers. So I ended up with an include path like this:
> 
> export CFLAGS="-I ../zlib-1.2.8 -I /usr/src/linux-headers-3.6
> -trunk-common/include -I /usr/src/linux-headers-3.6-trunk-
> common/arch/arm/include -I /usr/include/arm-linux-gnueabihf"
> 
> But then I end up with a error message from line 30 of 
> /usr/include/arm-linux-gnueabihf/bits/types.h. The compiler 
> complains about the keyword "typedef". The previous line was
> #include <bits/wordsize.h>, so presumably that file left the
> compiler in a bad state. 
> 
> At this point I gave up and removed #includes of 
> linux/types.h and linux/pkt_sched.h from dropbear's 
> includes.h. Then the only thing that failed to compile was a
> couple of places that wanted definitions of 
> TC_PRIO_INTERACTIVE_BULK and TC_PRIO_INTERACTIVE. Grepping
> the 3.6 kernel headers I installed, I saw that they are
> defined as 4 and 6 respectively, so I just pasted those 
> values in as literals. This is entirely not cool. I'm 
> ashamed. However, the code now compiles and works on the 
> embedded device.
> 
> I guess me learning how to cross compile properly is
> off-topic for this mailing list.

note that there are several musl libc based linux distros
that package dropbear e.g.
http://git.alpinelinux.org/cgit/aports/plain/main/dropbear/

some of them cross compile like openwrt so you might want
to look at their patches.

that said i dont remember running into issues when i last
built dropbear with musl.

From post at lespocky.de  Tue Jul 26 21:17:56 2016
From: post at lespocky.de (Alexander Dahl)
Date: Tue, 26 Jul 2016 15:17:56 +0200
Subject: Building with Musl
In-Reply-To: <20160726123446.GS19691@port70.net>
References: <b18a9c56cd204f6aa50ef74ac45e01c6@DB3PR30MB026.064d.mgd.msft.net>
	<506521469526500@web11j.yandex.ru>
	<ca1cfdda93a24f6297cb58efea90a081@DB3PR30MB026.064d.mgd.msft.net>
	<loom.20160726T125925-529@post.gmane.org>
	<20160726123446.GS19691@port70.net>
Message-ID: <c6ac066df821432302c56099d3ac3552@idefix.lespocky.dyndns.org>

Hei hei,

Am 2016-07-26 14:34, schrieb Szabolcs Nagy:
> note that there are several musl libc based linux distros
> that package dropbear e.g.
> http://git.alpinelinux.org/cgit/aports/plain/main/dropbear/

Which does not cross compile AFAIK. ;-)

> some of them cross compile like openwrt so you might want
> to look at their patches.
> 
> that said i dont remember running into issues when i last
> built dropbear with musl.

You can choose musl on buildroot [1] and it has no patches on current
master, but recently bumped the used dropbear version to 2016.74.

LEDE [2] is about to switch to musl, but I'm not sure if they use
patches, haven't looked into the tree recently.

ptxdist [3] cross compiles a recent dropbear without patches, but does
not use musl. ^^

HTH & Greets
Alex

[1] https://buildroot.org/
[2] https://www.lede-project.org/
[3] http://www.ptxdist.org/

-- 
?With the first link, the chain is forged. The first speech censured,
the first thought forbidden, the first freedom denied, chains us all
irrevocably.? (Jean-Luc Picard, quoting Judge Aaron Satie)
*** GnuPG-FP: C28E E6B9 0263 95CF 8FAF  08FA 34AD CD00 7221 5CC6 ***

From matt at ucc.asn.au  Tue Jul 26 22:01:06 2016
From: matt at ucc.asn.au (Matt Johnston)
Date: Tue, 26 Jul 2016 22:01:06 +0800
Subject: Building with Musl
In-Reply-To: <loom.20160726T125925-529@post.gmane.org>
References: <b18a9c56cd204f6aa50ef74ac45e01c6@DB3PR30MB026.064d.mgd.msft.net>
	<506521469526500@web11j.yandex.ru>
	<ca1cfdda93a24f6297cb58efea90a081@DB3PR30MB026.064d.mgd.msft.net>
	<loom.20160726T125925-529@post.gmane.org>
Message-ID: <5D74A8F2-7E39-4B4D-B6EA-88DB542225DC@ucc.asn.au>

Hi Andrew,

I suspect Dropbear itself needs fixing, your workaround sounds fine for now. The configure script should probably just test for HAVE_LINUX_TYPES_H or similar and the required #defines. I'll look at it.

Cheers,
Matt

#ifdef SO_PRIORITY
#include <linux/types.h>
#include <linux/pkt_sched.h>
#endif




> On Tue 26/7/2016, at 7:20 pm, Andrew Bainbridge <andbain at microsoft.com> wrote:
> 
> Andrew Bainbridge <andbain <at> microsoft.com> writes:
> 
> My embedded device is running Linux 3.4.0. I couldn't find 
> a package of kernel 3.4.0 kernel headers available on 
> Raspbian package manager, so I installed the nearest, which
> was linux-headers-3.6-trunk-rpi. Already, I can see myself 
> falling into a rabbit hole.
> 
> Then I found lots more compile errors failing to find more
> headers. So I ended up with an include path like this:
> 
> export CFLAGS="-I ../zlib-1.2.8 -I /usr/src/linux-headers-3.6
> -trunk-common/include -I /usr/src/linux-headers-3.6-trunk-
> common/arch/arm/include -I /usr/include/arm-linux-gnueabihf"
> 
> But then I end up with a error message from line 30 of 
> /usr/include/arm-linux-gnueabihf/bits/types.h. The compiler 
> complains about the keyword "typedef". The previous line was
> #include <bits/wordsize.h>, so presumably that file left the
> compiler in a bad state. 
> 
> At this point I gave up and removed #includes of 
> linux/types.h and linux/pkt_sched.h from dropbear's 
> includes.h. Then the only thing that failed to compile was a
> couple of places that wanted definitions of 
> TC_PRIO_INTERACTIVE_BULK and TC_PRIO_INTERACTIVE. Grepping
> the 3.6 kernel headers I installed, I saw that they are
> defined as 4 and 6 respectively, so I just pasted those 
> values in as literals. This is entirely not cool. I'm 
> ashamed. However, the code now compiles and works on the 
> embedded device.
> 
> I guess me learning how to cross compile properly is
> off-topic for this mailing list.
> 


From andbain at microsoft.com  Wed Jul 27 17:51:54 2016
From: andbain at microsoft.com (Andrew Bainbridge)
Date: Wed, 27 Jul 2016 09:51:54 +0000 (UTC)
Subject: Building with Musl
References: <b18a9c56cd204f6aa50ef74ac45e01c6@DB3PR30MB026.064d.mgd.msft.net>
	<506521469526500@web11j.yandex.ru>
	<ca1cfdda93a24f6297cb58efea90a081@DB3PR30MB026.064d.mgd.msft.net>
	<loom.20160726T125925-529@post.gmane.org>
	<20160726123446.GS19691@port70.net>
	<c6ac066df821432302c56099d3ac3552@idefix.lespocky.dyndns.org>
Message-ID: <loom.20160727T114939-91@post.gmane.org>

Alexander Dahl <post <at> lespocky.de> writes:
> You can choose musl on buildroot [1] and it has no patches on current
> master, but recently bumped the used dropbear version to 2016.74.

I didn't know about buildroot. It's a useful tool. Thanks for the link.


From nsz at port70.net  Wed Jul 27 19:30:03 2016
From: nsz at port70.net (Szabolcs Nagy)
Date: Wed, 27 Jul 2016 13:30:03 +0200
Subject: Building with Musl
In-Reply-To: <loom.20160726T125925-529@post.gmane.org>
References: <b18a9c56cd204f6aa50ef74ac45e01c6@DB3PR30MB026.064d.mgd.msft.net>
	<506521469526500@web11j.yandex.ru>
	<ca1cfdda93a24f6297cb58efea90a081@DB3PR30MB026.064d.mgd.msft.net>
	<loom.20160726T125925-529@post.gmane.org>
Message-ID: <20160727113002.GT19691@port70.net>

* Andrew Bainbridge <andbain at microsoft.com> [2016-07-26 11:20:01 +0000]:
> But then I end up with a error message from line 30 of 
> /usr/include/arm-linux-gnueabihf/bits/types.h. The compiler 
> complains about the keyword "typedef". The previous line was

this is your problem:
you are using a glibc based cross compiler.
use a musl cross compiler (arm-linux-musleabihf).
or make sure that the glibc headers are not
in the include path at all.

the simplest way to get a musl cross compiler is

git clone https://github.com/richfelker/musl-cross-make
cd musl-cross-make
# optionally edit config.mak
make -j8 TARGET=arm-linux-musleabihf install

From hans at atbas.org  Thu Aug  4 01:56:35 2016
From: hans at atbas.org (Hans Harder)
Date: Wed, 3 Aug 2016 19:56:35 +0200
Subject: wrong definition in default_options.h
Message-ID: <CAKzsc6eEPc_05Qd9Wq4dCnPCSR3KRRG+4hDCmzW6mSfQjj0w1Q@mail.gmail.com>

I see that localoptions.h now can be used to enable/disable options which
are in default_options.h and sysoptions.h... nice

There is a wrong definition in the default_options.h
/* Whether to support "-c" and "-m" flags to choose ciphers/MACs at runtime
*/
#ifndef ENABLE_USER_ALGO_LIST
#define ENABLE_USER_ALGO_LIST 1
#endif

Should be
/* Whether to support "-c" and "-m" flags to choose ciphers/MACs at runtime
*/
#ifndef DROPBEAR_USER_ALGO_LIST
#define DROPBEAR_USER_ALGO_LIST 1
#endif


Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20160803/207a963b/attachment.htm 

From hans at atbas.org  Thu Aug  4 02:34:33 2016
From: hans at atbas.org (Hans Harder)
Date: Wed, 3 Aug 2016 20:34:33 +0200
Subject: wrong definition in default_options.h
In-Reply-To: <CAKzsc6eEPc_05Qd9Wq4dCnPCSR3KRRG+4hDCmzW6mSfQjj0w1Q@mail.gmail.com>
References: <CAKzsc6eEPc_05Qd9Wq4dCnPCSR3KRRG+4hDCmzW6mSfQjj0w1Q@mail.gmail.com>
Message-ID: <CAKzsc6dE8oUrzr+NjRHbCvMS+-aQBagm9Dgj7bzwWOxyV50AXQ@mail.gmail.com>

Currently some settings are checked with  #ifdef  instead of #if :

INETD_MODE and NON_INETD_MODE  in svr-main.c
DO_MOTD   in svr-chansession.c and svr-runopts.c
DROPBEAR_RSA and DROPBEAR_DSS  in keyimport.c
DROPBEAR_CLI_PUBKEY_AUTH  in cli-runopts.c

Hans



On Wed, Aug 3, 2016 at 7:56 PM, Hans Harder <hans at atbas.org> wrote:

> I see that localoptions.h now can be used to enable/disable options which
> are in default_options.h and sysoptions.h... nice
>
> There is a wrong definition in the default_options.h
> /* Whether to support "-c" and "-m" flags to choose ciphers/MACs at
> runtime */
> #ifndef ENABLE_USER_ALGO_LIST
> #define ENABLE_USER_ALGO_LIST 1
> #endif
>
> Should be
> /* Whether to support "-c" and "-m" flags to choose ciphers/MACs at
> runtime */
> #ifndef DROPBEAR_USER_ALGO_LIST
> #define DROPBEAR_USER_ALGO_LIST 1
> #endif
>
>
> Hans
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20160803/eff22134/attachment.htm 

From hans at atbas.org  Sun Aug  7 04:42:10 2016
From: hans at atbas.org (Hans Harder)
Date: Sat, 6 Aug 2016 22:42:10 +0200
Subject: PATCH: minimum set of trace messages in dbclient
Message-ID: <CAKzsc6czDW7L4RvYQYKVU2q3MFSdF2KB=nZ+_mYtUwn_B7ZSTw@mail.gmail.com>

I changed the DEBUG_TRACE functionality and added a DEBUG_LEVEL setting
which allows you to add only a minimum number of messages to dbclient only.
By specifying 1 or more -v options you will increase verbosity.
1x -v  will show connection, remoteid and auth methods
2x -v  will show choosen algos
3x -v  will show avalable algos
This functionality will increase a static dbclient binary approx with 4kb

example:
dev32:~/git/dropbear# ./dbclient -v -v  192.168.1.150
TRACE  (13755) 0.000000: user='root' host='192.168.1.150' port='22'
TRACE  (13755) 0.000108: enter session_init
TRACE  (13755) 0.010916: remoteident: SSH-2.0-dropbear_2016.74
TRACE  (13755) 0.011120: kex algo curve25519-sha256 at libssh.org
TRACE  (13755) 0.011201: hostkey algo ssh-rsa
TRACE  (13755) 0.011294: enc  c2s is aes128-ctr
TRACE  (13755) 0.011354: enc  s2c is aes128-ctr
TRACE  (13755) 0.011486: hmac c2s is hmac-sha1
TRACE  (13755) 0.011518: hmac s2c is hmac-sha1
TRACE  (13755) 0.011561: comp c2s is zlib at openssh.com
TRACE  (13755) 0.011585: comp s2c is zlib at openssh.com
TRACE  (13755) 0.107063: enter cli_auth_getmethods
TRACE  (13755) 0.107875: Methods (len 18): 'publickey,password'
TRACE  (13755) 0.107948: auth method 'publickey' valid
TRACE  (13755) 0.108013: enter cli_auth_try
TRACE  (13755) 0.108096: try  auth method publickey
TRACE  (13755) 0.108132: skip auth method password (not enabled)
TRACE  (13755) 0.108150: skip auth method interact (not enabled)
TRACE  (13755) 0.108199: cli_auth_try lastauthtype 2
TRACE  (13755) 0.108248: leave cli_auth_try failure
TRACE  (13755) 0.108313: enter session_cleanup
dbclient: Connection to root at 192.168.1.150:22 exited: No auth methods could
be used.
dev32:~/git/dropbear#

patch against latest git version attached..

Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20160806/48bb692f/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DEBUGLEVEL.patch
Type: application/octet-stream
Size: 9416 bytes
Desc: not available
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20160806/48bb692f/attachment-0001.obj 

From yan at seiner.com  Sun Aug  7 19:29:20 2016
From: yan at seiner.com (Yan Seiner)
Date: Sun, 7 Aug 2016 07:29:20 -0400
Subject: ssh tunnel unattended
Message-ID: <2e16c52a-3d48-5184-e36c-12162998a246@seiner.com>

I have a remote node that I want to administer.  I want to run an ssh 
tunnel from that node to my router.

If I start it from the command line with

/usr/bin/ssh  -R 1022:localhost:22 uuu at example.com -p 23

everything works fine.

But if I try to run it from inittab or /etc/rc.local, it never connects. 
  I've tried

/usr/bin/ssh  -N -T -R 1022:localhost:22 uuu at example.com -p 23
/usr/bin/ssh  -N -R 1022:localhost:22 uuu at example.com -p 23

nothing seems to work.  How do I run a tunnel automatically from an 
embedded box?

Thanks.

From yan at seiner.com  Sun Aug  7 20:03:36 2016
From: yan at seiner.com (Yan Seiner)
Date: Sun, 7 Aug 2016 08:03:36 -0400
Subject: ssh tunnel unattended
In-Reply-To: <2e16c52a-3d48-5184-e36c-12162998a246@seiner.com>
References: <2e16c52a-3d48-5184-e36c-12162998a246@seiner.com>
Message-ID: <3f9e03cf-0489-9273-dac9-0c493504df1c@seiner.com>



On 08/07/2016 07:29 AM, Yan Seiner wrote:
> I have a remote node that I want to administer.  I want to run an ssh 
> tunnel from that node to my router.
>
> If I start it from the command line with
>
> /usr/bin/ssh  -R 1022:localhost:22 uuu at example.com -p 23
>
> everything works fine.
>
> But if I try to run it from inittab or /etc/rc.local, it never 
> connects.  I've tried
>
> /usr/bin/ssh  -N -T -R 1022:localhost:22 uuu at example.com -p 23
> /usr/bin/ssh  -N -R 1022:localhost:22 uuu at example.com -p 23
>
> nothing seems to work.  How do I run a tunnel automatically from an 
> embedded box?

To clarify this:

The tunnel connects, tcpdump sees packets going back and forth, but 
netstat on the local doesn't show the port.


From fabriziobertocci at gmail.com  Sun Aug  7 20:18:11 2016
From: fabriziobertocci at gmail.com (Fabrizio Bertocci)
Date: Sun, 7 Aug 2016 08:18:11 -0400
Subject: ssh tunnel unattended
In-Reply-To: <3f9e03cf-0489-9273-dac9-0c493504df1c@seiner.com>
References: <2e16c52a-3d48-5184-e36c-12162998a246@seiner.com>
	<3f9e03cf-0489-9273-dac9-0c493504df1c@seiner.com>
Message-ID: <CADtzkx47J3yqvTwiqNbJJMOzpLr9uFoF7K5fdnChHkZUxHWaug@mail.gmail.com>

Yan,
Try to provide an input stream to the process. I remember seeing a similar
problem.
/usr/bin/ssh  -N -T -R 1022:localhost:22 uuu at example.com -p 23 < /dev/null

See this post:
http://stackoverflow.com/questions/19955260/what-is-dev-null-in-bash

Regards,
Fabrizio


On Sun, Aug 7, 2016 at 8:03 AM, Yan Seiner <yan at seiner.com> wrote:

>
>
> On 08/07/2016 07:29 AM, Yan Seiner wrote:
>
>> I have a remote node that I want to administer.  I want to run an ssh
>> tunnel from that node to my router.
>>
>> If I start it from the command line with
>>
>> /usr/bin/ssh  -R 1022:localhost:22 uuu at example.com -p 23
>>
>> everything works fine.
>>
>> But if I try to run it from inittab or /etc/rc.local, it never connects.
>> I've tried
>>
>> /usr/bin/ssh  -N -T -R 1022:localhost:22 uuu at example.com -p 23
>> /usr/bin/ssh  -N -R 1022:localhost:22 uuu at example.com -p 23
>>
>> nothing seems to work.  How do I run a tunnel automatically from an
>> embedded box?
>>
>
> To clarify this:
>
> The tunnel connects, tcpdump sees packets going back and forth, but
> netstat on the local doesn't show the port.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20160807/67d655e0/attachment.htm 

From yan at seiner.com  Sun Aug  7 21:07:08 2016
From: yan at seiner.com (Yan Seiner)
Date: Sun, 7 Aug 2016 09:07:08 -0400
Subject: ssh tunnel unattended
In-Reply-To: <CADtzkx47J3yqvTwiqNbJJMOzpLr9uFoF7K5fdnChHkZUxHWaug@mail.gmail.com>
References: <2e16c52a-3d48-5184-e36c-12162998a246@seiner.com>
	<3f9e03cf-0489-9273-dac9-0c493504df1c@seiner.com>
	<CADtzkx47J3yqvTwiqNbJJMOzpLr9uFoF7K5fdnChHkZUxHWaug@mail.gmail.com>
Message-ID: <ee5fbaf8-0084-8ec3-c9d2-608ed3c3532c@seiner.com>

No joy.  I've now tried various combinations of -N -t -T and < /dev/null 
and tcpdump shows the remote making the connection, but the forwarded 
port never appears.  :(  Starting it from inittab or rc.local seems to 
interfere with it being able to forward. I'm not that familiar with the 
startup process so what is missing at that point?


On 08/07/2016 08:18 AM, Fabrizio Bertocci wrote:
> Yan,
> Try to provide an input stream to the process. I remember seeing a 
> similar problem.
> /usr/bin/ssh  -N -T -R 1022:localhost:22 uuu at example.com 
> <mailto:uuu at example.com> -p 23 < /dev/null
>
> See this post:
> http://stackoverflow.com/questions/19955260/what-is-dev-null-in-bash
>
> Regards,
> Fabrizio
>
>
> On Sun, Aug 7, 2016 at 8:03 AM, Yan Seiner <yan at seiner.com 
> <mailto:yan at seiner.com>> wrote:
>
>
>
>     On 08/07/2016 07:29 AM, Yan Seiner wrote:
>
>         I have a remote node that I want to administer.  I want to run
>         an ssh tunnel from that node to my router.
>
>         If I start it from the command line with
>
>         /usr/bin/ssh  -R 1022:localhost:22 uuu at example.com
>         <mailto:uuu at example.com> -p 23
>
>         everything works fine.
>
>         But if I try to run it from inittab or /etc/rc.local, it never
>         connects.  I've tried
>
>         /usr/bin/ssh  -N -T -R 1022:localhost:22 uuu at example.com
>         <mailto:uuu at example.com> -p 23
>         /usr/bin/ssh  -N -R 1022:localhost:22 uuu at example.com
>         <mailto:uuu at example.com> -p 23
>
>         nothing seems to work.  How do I run a tunnel automatically
>         from an embedded box?
>
>
>     To clarify this:
>
>     The tunnel connects, tcpdump sees packets going back and forth,
>     but netstat on the local doesn't show the port.
>
>

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

From annulen at yandex.ru  Mon Aug  8 01:43:54 2016
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Sun, 07 Aug 2016 20:43:54 +0300
Subject: ssh tunnel unattended
In-Reply-To: <ee5fbaf8-0084-8ec3-c9d2-608ed3c3532c@seiner.com>
References: <2e16c52a-3d48-5184-e36c-12162998a246@seiner.com>
	<3f9e03cf-0489-9273-dac9-0c493504df1c@seiner.com>
	<CADtzkx47J3yqvTwiqNbJJMOzpLr9uFoF7K5fdnChHkZUxHWaug@mail.gmail.com>
	<ee5fbaf8-0084-8ec3-c9d2-608ed3c3532c@seiner.com>
Message-ID: <177951470591834@web6h.yandex.ru>

I'm running dbclient from init script with arguments -y -NT -R $PORT:localhost:22 -i $KEY 

07.08.2016, 16:09, "Yan Seiner" <yan at seiner.com>:
> No joy.? I've now tried various combinations of -N -t -T and < /dev/null and tcpdump shows the remote making the connection, but the forwarded port never appears.? :(? Starting it from inittab or rc.local seems to interfere with it being able to forward. I'm not that familiar with the startup process so what is missing at that point?
>
> On 08/07/2016 08:18 AM, Fabrizio Bertocci wrote:
>> Yan,
>> Try to provide an input stream to the process. I remember seeing a similar problem.
>> /usr/bin/ssh ?-N -T -R 1022:localhost:22 uuu at example.com -p 23 < /dev/null
>>
>> See this post:
>> http://stackoverflow.com/questions/19955260/what-is-dev-null-in-bash
>>
>> Regards,
>> Fabrizio
>>
>> On Sun, Aug 7, 2016 at 8:03 AM, Yan Seiner <yan at seiner.com> wrote:
>>> On 08/07/2016 07:29 AM, Yan Seiner wrote:
>>>> I have a remote node that I want to administer.? I want to run an ssh tunnel from that node to my router.
>>>>
>>>> If I start it from the command line with
>>>>
>>>> /usr/bin/ssh? -R 1022:localhost:22 uuu at example.com -p 23
>>>>
>>>> everything works fine.
>>>>
>>>> But if I try to run it from inittab or /etc/rc.local, it never connects.? I've tried
>>>>
>>>> /usr/bin/ssh? -N -T -R 1022:localhost:22 uuu at example.com -p 23
>>>> /usr/bin/ssh? -N -R 1022:localhost:22 uuu at example.com -p 23
>>>>
>>>> nothing seems to work.? How do I run a tunnel automatically from an embedded box?
>>>
>>> To clarify this:
>>>
>>> The tunnel connects, tcpdump sees packets going back and forth, but netstat on the local doesn't show the port.


-- 
Regards,
Konstantin

From hans at atbas.org  Wed Aug 10 23:59:55 2016
From: hans at atbas.org (Hans Harder)
Date: Wed, 10 Aug 2016 17:59:55 +0200
Subject: Bad hostkey signature when compiling without ECDSA
Message-ID: <CAKzsc6c+fzULnELHJzDLxviGe832N6QqJ38vSNJ05wEYABG1=A@mail.gmail.com>

When I compile dbclient without ECDSA support I get underneath error.
However same source compiled with ECDSA the same connection works.




part of the debug output, added some extra output in kexdh_init and
kexdh_reply
to see what values where given
Seems that something goes wrong in buf_rsa_verify.

Compiled with  #define DROPBEAR_ECDSA 0


TRACE  (32763) 0.008984: send_msg_kexdh_init()
init : 0
init = normal_DH
TRACE  (32763) 0.009065: enter gen_kexdh_vals
TRACE  (32763) 0.208185: leave cli_sessionloop: done with KEXINIT_RCVD
TRACE  (32763) 0.208220: enter set_connect_fds
TRACE  (32763) 0.208305: process_packet: packet type = 31,  len 567
TRACE  (32763) 0.208368: got expected packet 31 during kexinit
TRACE  (32763) 0.208421: enter recv_msg_kexdh_reply
TRACE  (32763) 0.208453: type is 0
TRACE  (32763) 0.208776: checkpubkey: base64_decode success
TRACE  (32763) 0.208847: good matching key
TRACE  (32763) 0.208886: enter buf_get_rsa_pub_key
TRACE  (32763) 0.209013: leave buf_get_rsa_pub_key: success
reply = NORMAL_DH
TRACE  (32763) 0.406192: enter buf_put_rsa_pub_key
TRACE  (32763) 0.406592: leave buf_put_rsa_pub_key
TRACE  (32763) 0.408458: enter buf_verify
TRACE  (32763) 0.408546: enter buf_rsa_verify
TRACE  (32763) 0.409296: leave buf_rsa_verify: ret -1
TRACE  (32763) 0.409367: enter session_cleanup
TRACE  (32763) 0.409392: enter chancleanup
TRACE  (32763) 0.409426: leave chancleanup
TRACE  (32763) 0.409477: enter cli_tty_cleanup
TRACE  (32763) 0.409538: leave cli_tty_cleanup: not in raw mode
TRACE  (32763) 0.409621: empty queue dequeing
TRACE  (32763) 0.409822: leave session_cleanup

dbclient: Connection to test at 192.168.1.51:22 exited: Bad hostkey signature


Compiled with  #define DROPBEAR_ECDSA 1

TRACE  (651) 0.009374: send_msg_kexdh_init()
init : 0
init = normal_DH
TRACE  (651) 0.009419: enter gen_kexdh_vals
TRACE  (651) 0.204902: leave cli_sessionloop: done with KEXINIT_RCVD
TRACE  (651) 0.204943: enter set_connect_fds
TRACE  (651) 0.205012: maybe_empty_reply_queue - no data allowed
TRACE  (651) 0.205078: enter handle_connect_fds
TRACE  (651) 0.205103: leave handle_connect_fds - end iter
TRACE  (651) 0.205274: empty queue dequeing
TRACE  (651) 0.205309: leave cli_sessionloop: kex_state != KEX_NOTHING
TRACE  (651) 0.205356: enter set_connect_fds
TRACE  (651) 0.267174: process_packet: packet type = 31,  len 567
TRACE  (651) 0.267236: got expected packet 31 during kexinit
TRACE  (651) 0.267277: enter recv_msg_kexdh_reply
TRACE  (651) 0.267355: type is 0
TRACE  (651) 0.267643: checkpubkey: base64_decode success
TRACE  (651) 0.267685: good matching key
TRACE  (651) 0.267722: enter buf_get_rsa_pub_key
TRACE  (651) 0.267820: leave buf_get_rsa_pub_key: success
reply = NORMAL_DH
TRACE  (651) 0.462904: enter buf_put_rsa_pub_key
TRACE  (651) 0.463227: leave buf_put_rsa_pub_key
TRACE  (651) 0.465734: enter buf_verify
TRACE  (651) 0.465765: enter buf_rsa_verify
TRACE  (651) 0.466463: success!
TRACE  (651) 0.466526: leave buf_rsa_verify: ret 0
TRACE  (651) 0.466593: enter send_msg_newkeys
TRACE  (651) 0.466709: enter gen_new_keys
TRACE  (651) 0.467408: leave gen_new_keys
TRACE  (651) 0.467438: switch_keys trans
TRACE  (651) 0.467701: leave send_msg_newkeys
..
..
dbclient: Connection to test at 192.168.1.51:22 exited: No auth methods could
be used.


I cannot seem to find a reason for that...   anybody ?

Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20160810/093a156a/attachment.htm 

From jorton at tehamawireless.com  Thu Aug 11 13:30:33 2016
From: jorton at tehamawireless.com (Jim Orton)
Date: Wed, 10 Aug 2016 22:30:33 -0700
Subject: Tunnels timing out in 2016.74
Message-ID: <57AC0D79.3030700@tehamawireless.com>

Hi,

I've been using Dropbear for many years to establish tunnels to a relay 
server.  I recently updated my Linux server which upgraded Dropbear from 
2015.67 to 2016.74.  Now all connections to the server drop after the 
idle_timeout period set by the -I parameter.  All clients use dbclient 
and initiate the tunnel with a -K keep-alive value set to about 1/3 the 
idle_timeout, which in 2015.67 (and 2013.60 before that) would keep the 
tunnel alive, even if unused, until manually killed.

dropbear server parameters:
     dropbear -p 1234 -w -a -I 650

dbclient call:
     dbclient user at server -p 1234 -R 54321:localhost:2345 -K 200 -g -f 
-N -i ~/.ssh/id_rsa


I don't see anything in the release notes  that would seem to affect 
these setting.   What am I missing?  Unfortunately there is no simple 
downgrade of Dropbear in my server's package manager; I can build a 
downrev if necessary but hope to avoid that if this is just a subtle 
change in the parameter handling.

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

From rocklee_104 at outlook.com  Mon Sep 12 17:08:09 2016
From: rocklee_104 at outlook.com (Lee Rock)
Date: Mon, 12 Sep 2016 09:08:09 +0000
Subject: the use of dropbear_rsa_host_key 
Message-ID: <HK2PR01MB1012E3BC8EBA50B309AD1C3FCFFF0@HK2PR01MB1012.apcprd01.prod.exchangelabs.com>

Hi, guys:
	Dropbear doesn't even launch when /etc/dropbear/dropbear_rsa_host_key missing. 
I use passwd as login method and there is no need to use rsa|dss keys. Why dropbear still need these keys?

From rob at landley.net  Wed Sep 14 05:22:09 2016
From: rob at landley.net (Rob Landley)
Date: Tue, 13 Sep 2016 16:22:09 -0500
Subject: the use of dropbear_rsa_host_key
In-Reply-To: <HK2PR01MB1012E3BC8EBA50B309AD1C3FCFFF0@HK2PR01MB1012.apcprd01.prod.exchangelabs.com>
References: <HK2PR01MB1012E3BC8EBA50B309AD1C3FCFFF0@HK2PR01MB1012.apcprd01.prod.exchangelabs.com>
Message-ID: <6c512ba4-ed29-9fba-43b3-b2e012601367@landley.net>

On 09/12/2016 04:08 AM, Lee Rock wrote:
> Hi, guys:
> 	Dropbear doesn't even launch when /etc/dropbear/dropbear_rsa_host_key missing. 
> I use passwd as login method and there is no need to use rsa|dss keys. Why dropbear still need these keys?

The host key identifies the server. The login key identifies the user.
You need both to do ssh. (The point of the host key is to prevent man in
the middle attacks.)

Rob

From HMayer6 at gmx.net  Sat Sep 17 00:24:42 2016
From: HMayer6 at gmx.net (Hans Mayer)
Date: Fri, 16 Sep 2016 18:24:42 +0200
Subject: Issues behind NAT
Message-ID: <251a63f0-a56c-f185-9815-a160bbe907b2@gmx.net>

Hello,

Are there known issues/pitfalls for dropbear behind NAT ?

I run it pre-boot on ubuntu 16.04 to unlock disks. It runs pefectly
inside the network and after booting openssh works flawlessly as well.

Links would be very appreciated.



From u-pwhy at aetey.se  Mon Sep 19 02:56:56 2016
From: u-pwhy at aetey.se (u-pwhy at aetey.se)
Date: Sun, 18 Sep 2016 20:56:56 +0200
Subject: patch: a deficiency in pam support
Message-ID: <20160918185656.GY16436@example.net>

Hello,

[While configuring dropbear-2016.74 for use with pam_krb5] I found
a deficiency, the lack of pam_setcred(), and suggest a fix as follows:

sed -i.orig '
/\/\* successful authentication \*\//i\
        if ((rc = pam_setcred(pamHandlep, 0)) != PAM_SUCCESS) {\
                dropbear_log(LOG_WARNING, "pam_setcred() failed, rc=%d, %s",\
                                rc, pam_strerror(pamHandlep, rc));\
                send_msg_userauth_failure(0, 1);\
                goto cleanup;\
        }\

' svr-authpam.c

It is not complete to be able to use the Kerberos tickets after login,
the KRB5CCNAME variable needs to be passed from pam to the user environment.

Thus, conditionally passing KRB5CCNAME would be a useful feature.

NFSv4/Kerberos finds the user tickets on its own, because of this
the above change _is_ sufficient for accessing NFSv4 home directories.

It also improves the conformance to the pam API.

Regards,
Rune


From Joakim.Tjernlund at infinera.com  Mon Sep 19 18:46:21 2016
From: Joakim.Tjernlund at infinera.com (Joakim Tjernlund)
Date: Mon, 19 Sep 2016 10:46:21 +0000
Subject: patch: a deficiency in pam support
In-Reply-To: <20160918185656.GY16436@example.net>
References: <20160918185656.GY16436@example.net>
Message-ID: <1474282001.3549.174.camel@infinera.com>

On Sun, 2016-09-18 at 20:56 +0200, u-pwhy at aetey.se wrote:
> Hello,
> 
> [While configuring dropbear-2016.74 for use with pam_krb5] I found
> a deficiency, the lack of pam_setcred(), and suggest a fix as follows:

This reminds me, I have several fix to pam / expired passwd handling.
I just (dry) ported them to:
https://github.com/joakim-tjernlund/dropbear/commits/expired_passwd
Hopefully these can be added to dropbear.

You might want to build kerberos upon that

?Jocke

> 
> sed -i.orig '
> /\/\* successful authentication \*\//i\
> ????????if ((rc = pam_setcred(pamHandlep, 0)) != PAM_SUCCESS) {\
> ????????????????dropbear_log(LOG_WARNING, "pam_setcred() failed, rc=%d, %s",\
> ????????????????????????????????rc, pam_strerror(pamHandlep, rc));\
> ????????????????send_msg_userauth_failure(0, 1);\
> ????????????????goto cleanup;\
> ????????}\
> 
> ' svr-authpam.c
> 
> It is not complete to be able to use the Kerberos tickets after login,
> the KRB5CCNAME variable needs to be passed from pam to the user environment.
> 
> Thus, conditionally passing KRB5CCNAME would be a useful feature.
> 
> NFSv4/Kerberos finds the user tickets on its own, because of this
> the above change _is_ sufficient for accessing NFSv4 home directories.
> 
> It also improves the conformance to the pam API.
> 
> Regards,
> Rune
>