Leonid Bloch | 28 Jul 17:19 2013
Picon

Private key encryption

Hi,
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?

Thanks,
Leonid.
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!

Thanks,
Dave
Catalin Patulea | 25 Jul 03:21 2013
Picon
Picon

implementing eow <at> openssh.com

eow <at> openssh.com 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> openssh.com channel request to server
- sshd handles eow <at> openssh.com by closing read side of its pipe
- 'cat /etc/urandom' itself tries to write(), sees EPIPE and is killed
by SIGPIPE

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

eow <at> openssh.com is specified here:
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=HEAD;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> openssh.com 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.

thx 
Hans

Peter Meerwald | 15 Jul 14:41 2013
Picon

background later?

Hello,

I want to use dropbear just to setup port forwarding and then drop to the 
background, e.g. like so

ssh -f -N -T -y -K 20 -I 7200 -R 22222:localhost:22 remote.host.com

the problem is that the code to background dropbear (in cli-session.c, 
line 253) is before the setup of the port forwarding (just a few lines 
down)

so in case port forwarding setup fails, the caller of ssh has no way to 
find out that port forwarding failed by checking the exit code

I think the code to background dropbear should be be delayed until local 
and remote port forwarding has succedded (esp. in -N is given)

for remote connection this is somewhat tricky as the remote host has to 
open the ports and confirm back; so the backgrounding would need to go 
into cli_recv_msg_request_success() after having processed the last remote 
forward port in the list

regards, p.

--

-- 

Peter Meerwald
+43-664-2444418 (mobile)

Catalin Patulea | 13 Jul 11:31 2013
Picon
Picon

dbclient half-close?

Hi,

I'm seeing a difference in how dbclient handles EOF on input compared
to openssh client. openssh client propagates input EOF to the remote
command, but continues pumping command stdout. dbclient seems to abort
before flushing the stdout buffer.

In the following examples, 1.2.3.4 is an openwrt router running
dropbear server. The remote command is designed to wait for EOF, then
output something to stdout.

openssh client:
$ ssh root <at> 1.2.3.4 'cat; echo foo'
^D
foo

dbclient:
$ ./dbclient root <at> 1.2.3.4 'cat; echo foo'
^D
<no output>

I build dropbear with DEBUG_TRACE and these are the last few lines:
TRACE (...): empty queue dequeing
^D
TRACE (...): send normal readfd
TRACE (...): enter send_msg_channel_data
TRACE (...): enter send_msg_channel_data isextended 0 fd 0
TRACE (...): maxlen 16375
TRACE (...): CLOSE some fd 0
TRACE (...): leave send_msg_channel_data: len 0 read err 17 or EOF for fd 0
TRACE (...): enter send_msg_channel_eof
TRACE (...): leave send_msg_channel_eof
TRACE (...): sending close, readfd is closed
TRACE (...): enter send_msg_channel_close 0xcbfdc0
TRACE (...): enter cli_tty_cleanup
TRACE (...): leave cli_tty_cleanup: not in raw mode
TRACE (...): CLOSE some fd -1
TRACE (...): CLOSE some fd 2

I tried reading through the relevant sections of channel-common.c but
I could use some guidance/background. Is this behaviour intentional?

Catalin

Valliappan Muthiah | 26 Jun 08:53 2013

scp to always accept unknown remote hostkey

Hi,

We are using dropbear in our product. The version is
# dropbearmulti -v
Dropbear multi-purpose version 0.52
Make a symlink pointing at this binary with one of the following names:
'dropbear' - the Dropbear server
'dbclient' or 'ssh' - the Dropbear client
'dropbearkey' - the key generator
'dropbearconvert' - the key converter
'scp' - secure copy

I am tryin to scp files to my remote server. I would like to always accept unknown remote hostkey for my connection to server.
I did this successfully using "ssh -y" option, but i cannot use this switch when i do scp directly.

May i know if its possible to have this option in scp itself?
 
Thanks in advance.
Lluís Batlle i Rossell | 18 Jun 22:11 2013

-lcrypt as dependency in Makefile? (CRYPTLIB)

Hello,

the configure script sets up CRYPTLIB="-lcrypt".

Then, Makefile.in has something like:
dropbearobjs=$(COMMONOBJS) $(CLISVROBJS) $(SVROBJS)  <at> CRYPTLIB <at>  
dropbear: $(dropbearobjs)

How is this expected to work? I can't build dropbear due to GNU make not
finding the dependency "-lcrypt".

Regards,
Lluís.

Lluís Batlle i Rossell | 17 Jun 21:21 2013

Fixing crash on -J (proxycmd)

Hello,

since 0.53 (at least), using -J crashes on mips. With valgrind, I tracked this
down to a bad free.

Here is the patch attached that should fix it. At least, valgrind doesn't
complain. I'll test it with mips later.

Regards,
Lluís.
diff -r 5ba19d00da08 cli-runopts.c
--- a/cli-runopts.c	Sun May 26 18:43:00 2013 +0800
+++ b/cli-runopts.c	Mon Jun 17 19:19:12 2013 +0000
 <at>  <at>  -383,6 +383,13  <at>  <at> 
 		exit(EXIT_FAILURE);
 	}

+#ifdef ENABLE_CLI_PROXYCMD
+    if (cli_opts.proxycmd) {
+        /* To match the common path of m_freeing it */
+        cli_opts.proxycmd = m_strdup(cli_opts.proxycmd);
+    }
+#endif
+
 	if (cli_opts.remoteport == NULL) {
 		cli_opts.remoteport = "22";
 	}
William Welch | 24 May 23:42 2013
Picon

slow logins -- some data for comparison

Greetings,

First -- thank you for dropbear!  I have enjoyed using dropbear on various smallish systems for years now!

But I have a problem with a specific system -- admittedly it is rather slow -- only 50 BogoMips according to the linux kernel. It is a Microblaze.

I use the Buildroot system for many different routers and other small systems here.  I have compared different versions of dropbear, against openssh.

My issue is with the server mode -- sshd --  I note that on dropbear 0.52 (which I happen to run on other routers here), I can connect from my ubuntu or mac, to dropbear sshd, in about 45 seconds.  This is having disabled the RSA host key, and already generated the DSS host key.   But on more recent versions of dropbear, e.g. 2013.58, several minutes elapse without a connection.   

In contrast, switching to openssh in buildroot, and also disabling the RSA host key, connection time is 5 to 10 seconds!  Unfortunately, the openssh has a huge 'footprint' in the flash filesystem that I would rather avoid.

The issue seems to be in the key exchange ( I can watch this by doing 'ssh -v ' from my client connection).  Meanwhile, running 'top' on my Microblaze shows near 100% cpu used.  the debug message is: expecting SSH2_MSG_KEXDH_REPLY

Buildroot has the gnu cross tool chain set to 'optimize for size' in all cases.

Suggestions welcome!

thank you,

William

Christopher Meng | 20 May 08:18 2013
Picon

Re: Google Authenticator

This hinge on the configure step I think.

./configure with --enable-pam.

But I don't know your os packager's doing.

Gmane