Catalin Patulea | 14 Oct 23:31 2013

[PATCH] dropbear: add mirror, provided by dropbear maintainer

Signed-off-by: Catalin Patulea <cat <at>>
 package/network/services/dropbear/Makefile |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/network/services/dropbear/Makefile b/package/network/services/dropbear/Makefile
index f025c4d..02be761 100644
--- a/package/network/services/dropbear/Makefile
+++ b/package/network/services/dropbear/Makefile
 <at>  <at>  -13,7 +13,8  <at>  <at>  PKG_RELEASE:=1

+ \


Mike Frysinger | 12 Oct 22:37 2013

fix bundled libtom configure flag

the current flag treats --disable-bundled-libtom like enable.  this patch fixes it.

diff -r 93e04b9ff676
--- a/	Wed Oct 09 22:24:39 2013 +0800
+++ b/	Sat Oct 12 16:36:07 2013 -0400
 <at>  <at>  -365,9 +365,15  <at>  <at>  AC_CHECK_FUNCS(logout updwtmp logwtmp)

 	[  --enable-bundled-libtom       Use bundled libtomcrypt/libtommath even if a system version exists],
-	[ 
-		AC_MSG_NOTICE(Forcing bundled libtom*)
+	[
+		if test "x$enableval" = "xyes"; then
+			AC_MSG_NOTICE(Forcing bundled libtom*)
+		else
+			AC_CHECK_LIB(tomcrypt, register_cipher, , BUNDLED_LIBTOM=1)
+			AC_CHECK_LIB(tommath, mp_exptmod, , BUNDLED_LIBTOM=1)
+		fi
Steve Newcomb | 4 Oct 18:31 2013

autossh incompatibility with dropbear -y

I'm using OpenWRT.  My router, whose IP address changes unpredictably,
makes its ssh-listening port available on another host running at a
stable IP address, using autossh/dropbear to create a reverse channel.

Sometimes the host's key changes from time to time, which can stop the
autossh process at a prompt (to nobody) to decide what to do about the

Ordinary OpenSSH has a StrictHostKeyChecking option which can be used to
bypass the so-called "ask" prompt and just make the connection regardless.

By reading the source, I learned that Dropbear's ssh client evidently
has a similar feature, the "-y" invocation option.  But I can't pass the
-y to it via autossh because autossh doesn't approve of it.  Dropbear's
ssh client also does not offer a config file utility, AFAIK.
Dropbear evidently ignores all -o options, too; they wind up in a bit
bucket called something like "dummy".

Does anybody know the answer, short of editing/recompiling autossh so it
won't be so persnickety and just get out of the way?

Steve Newcomb

Matt Johnston | 4 Oct 16:38 2013

Dropbear 2013.59

Hi all,

Dropbear 2013.59 has been released. It fixes a number of
bugs, including two security issues affecting prior

- The Dropbear server could be made to consume large amounts
of memory because decompressed packet sizes weren't checked.
Depending on the OS and hardware this might be a denial of

- Valid users could be identified due to timing variations.

As usual you can download it from


2013.59 - Friday 4 October 2013

- Fix crash from -J command 
  Thanks to LluĂ­s Batlle i Rossell and Arnaud Mouiche for patches

- Avoid reading too much from /proc/net/rt_cache since that causes
  system slowness. 

- Improve EOF handling for half-closed connections
  Thanks to Catalin Patulea

(Continue reading)

peterpawn | 28 Aug 15:48 2013

[PATCH] ssh client can't be compiled without interactive authentication

Compiling dropbear without ENABLE_CLI_INTERACT_AUTH results in an error ...
 a needed member of "clientsession" structure from session.h isn't included.
Because I can't see a direct coherence between "no interactive
authentication" and "unencrypted connection", my proposed change is to
declare "cipher_none_after_auth" in any case (a simple #endif has to move
one line up).

--- 2013-04-18 16:58:14.000000000 +0200
+++ session.h 2013-08-28 15:32:36.000000000 +0200
 <at>  <at>  -270,9 +270,9  <at>  <at> 

info request from the server for

interactive auth.*/

        int cipher_none_after_auth; /* Set to 1 if the user requested "none"
                                                                   auth */
        sign_key *lastprivkey;

        int retval; /* What the command exit status was - we emulate it */

Thomas Vajzovic | 21 Aug 16:34 2013

dropbear ssh server with vfork and no fork


I am interested in running dropbear ssh server under uClinux on an embedded blackfin platform (using the
buildroot distribution).

This platform does not have a full MMU, so fork() is not available.

I notice that in one or two places in dropbear, fork() has been replaced with vfork() if the macro
__uClinux__ is defined.

In scp.c, there are comments about the requirement to call exec immediately in the child after vfork
returns, and this is done.

In other places some of the things that are done after vfork but before exec are quite big, eg:

* writing to stack data
* writing to global data
 * closing and dup-ing file descriptors
 * changing signal handlers
 * writing to the login record
 * malloc-ing memory
 * setting environment variables
 * setuid/setgid

In svr-chansession.c the code commented "wipe the hostkey" is not performed if vfork was used, so
presumably that bit was found to not work, but what about the rest?

Are people running the dropbear server on no-MMU systems and it just happens to work for them, or has someone
verified that it will always work?

(Continue reading)

aaron mcmanus | 30 Jul 02:55 2013


Sent from Yahoo hey ! Mail on Android

Leonid Bloch | 28 Jul 17:19 2013

Private key encryption

Since Dropbear does not support encrypted keys, I was wondering if using gpg to encrypt the key could be a solution. I mean some script like that:

KEY=$(gpg < key.gpg)
ssh -i $KEY server "some_command_to_server"

When encrypted key ("key.gpg") is generated using:
gpg -c key

So is this a secure/viable solution, or I'm totally missing something?

David Henderson | 26 Jul 17:22 2013

documentation installation

Good morning everyone!  I'm currently trying to compile and install dropbear to a staging directory for packing on a Linux distro.  The compiling and installation actually works like a charm, but the one thing that has me baffled is that the documentation isn't being installed!  I've tried searching online and looking through the source files, but can't find anything that indicates how to install the documentation!  Any help would greatly be appreciated!

Catalin Patulea | 25 Jul 03:21 2013

implementing eow <at>

eow <at> is an extension that allows EPIPE to propagate through
SSH sessions. For example:
ssh localhost cat /dev/urandom | /bin/true
will very quickly exit because /bin/true does not consume its stdin.

The mechanism is:
- /bin/true calls exit(0), closing the last remaining ref to its stdin pipe
- ssh tries to write() and gets EPIPE
- ssh sends eow <at> channel request to server
- sshd handles eow <at> by closing read side of its pipe
- 'cat /etc/urandom' itself tries to write(), sees EPIPE and is killed

dropbear doesn't implement this, so
./dbclient localhost cat /dev/urandom | /bin/true
runs forever.

eow <at> is specified here:;content-type=text/plain
(section 2.1)

I have a draft implementation of this in dropbear (attached), but
there is one significant issue:

In cli-session.c, stdin, stdout and stderr are dup()'ed in order to be
able to restore file flags at the end of the session. This means that
if the client gets eow <at> from the server and close(0), this
is actually not the last outstanding ref to the pipe. There's still an
fd 4 or so, which means the writer actually doesn't see EPIPE. So a
case like this is still broken:
<producer> | ./dbclient <host> <remote command that closes stdin>

On my ubuntu dev machine I could just comment the dup()/flags hack
out, which made this work. But I'm not sure whether this is really
still needed at all.

What is the history behind this? The comment says:
/* We store std{in,out,err}'s flags, so we can set them back on exit
 * (otherwise busybox's ash isn't happy */

but that's not much detail and I'm not sure if it's really still needed.
Attachment (dropbear-eow.patch): application/octet-stream, 8 KiB
Hans Harder | 15 Jul 20:03 2013

Problems when connecting to dropbear server running as non-root

I am trying to connect using ssh: -v -i privkey -p 7000 hans <at> host hostname
And I get:

debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: hostname
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
[28924] Jul 15 17:40:24 Exit (hans): Couldn't change user as non-root
TRACE  (28924) 1373910024.524936: enter session_cleanup
TRACE  (28924) 1373910024.525004: enter chancleanup
TRACE  (28924) 1373910024.525021: channel 0 closing
TRACE  (28924) 1373910024.525037: enter remove_channel
TRACE  (28924) 1373910024.525050: channel index is 0

Dropbear is running on the host as a non-root user hans with  dropbear -v -F -P 7000  and gives (small part)

TRACE  (28923) 1373910024.518919: enter recv_msg_channel_request 0x82ca4e8
TRACE  (28923) 1373910024.518942: enter chansessionrequest
TRACE  (28923) 1373910024.518961: type is exec
TRACE  (28923) 1373910024.519100: enter sessioncommand
TRACE  (28923) 1373910024.519138: enter noptycommand
TRACE  (28923) 1373910024.519370: setnonblocking: 8
TRACE  (28923) 1373910024.519411: leave setnonblocking
TRACE  (28923) 1373910024.519429: setnonblocking: 7
TRACE  (28923) 1373910024.519451: leave setnonblocking
TRACE  (28923) 1373910024.519475: setnonblocking: 10
TRACE  (28923) 1373910024.519497: leave setnonblocking
TRACE  (28924) 1373910024.519758: back to normal sigchld
TRACE  (28923) 1373910024.525685: enter sigchld handler
TRACE  (28923) 1373910024.525735: sigchld handler: pid 28924
TRACE  (28923) 1373910024.525761: using lastexit
TRACE  (28923) 1373910024.525811: leave sigchld handler
TRACE  (28923) 1373910024.525836: parent side: lastexitpid is 28924
TRACE  (28923) 1373910024.525857: found match for lastexitpid
TRACE  (28923) 1373910024.525876: leave noptycommand
TRACE  (28923) 1373910024.525905: leave chansessionrequest
TRACE  (28923) 1373910024.525925: leave recv_msg_channel_request
TRACE  (28923) 1373910024.525945: sesscheckclose, pid is 28924
TRACE  (28923) 1373910024.525999: sesscheckclose, pid is 28924
TRACE  (28923) 1373910024.526022: might send data, flushing
TRACE  (28923) 1373910024.526041: send data readfd
TRACE  (28923) 1373910024.526060: enter send_msg_channel_data
TRACE  (28923) 1373910024.526080: enter send_msg_channel_data isextended 0 fd 8
TRACE  (28923) 1373910024.526104: maxlen 16375
TRACE  (28923) 1373910024.526127: CLOSE some fd 8
TRACE  (28923) 1373910024.526154: leave send_msg_channel_data: len 0 read err 4 or EOF for fd 8
TRACE  (28923) 1373910024.526183: send data errfd
TRACE  (28923) 1373910024.526202: enter send_msg_channel_data
TRACE  (28923) 1373910024.526220: enter send_msg_channel_data isextended 1 fd 10
TRACE  (28923) 1373910024.526245: maxlen 16371
TRACE  (28923) 1373910024.526269: send_msg_channel_data: len 761 fd 10
TRACE  (28923) 1373910024.526338: closing from channel, flushing out.
TRACE  (28923) 1373910024.526360: CLOSE some fd 10

On 2 other boxes it works perfectly, so there is something on this host which is breaking it...

Anybody got a hint where to look for.