Re: dropbear still requires password when password is blank

[Matt Johnston]

Hi,

Somehow I missed this patch and also a similar one from
Chris Metcalf in 2010 :( Sorry about that.

Anyway, I've now committed the same functionality for the
next release (in Mercurial now).

Cheers,
Matt

On Thu, Apr 26, 2012 at 11:54:28AM -0400, Paul Smith wrote:
> On Thu, 2012-04-26 at 15:33 +, Grant Edwards wrote:
> > I'm trying to switch from the openssh server to dropbear's server on
> > an embedded system, and I've run into one snag.  I've enabled the
> > "allow blank password" feature, but dropbear still prompts for a
> > password on accounts that have blank passwords.  That's "wrong" -- or
> > at least it's different than what openssh, telnetd, login do.
> 
> I've not been following dropbear development but a number of years ago,
> dropbear didn't support no-password login (as root for sure).  I created
> a patch and submitted it to the dropbear list.  Not sure if it (or
> something like it) was integrated.
> 
> If it helps your investigation here's a link to the mailing list post
> with my patch although this was 3 years ago so not sure if/how much the
> code has changed:
> 
> http://permalink.gmane.org/gmane.network.ssh.dropbear/845
> 
> 

Re: Dropbear and PAM auth.

[Matt Johnston]

It should work ok with any module that just prompts for a username and 
password, which gets mapped to SSH's password authentication mode. It doesn't 
support more complex challenge/response type modes (which would use SSH's 
keyboard-interactive mode IIRC). If the username/password prompt doesn't match 
what's normal, take a look at svr-authpam.c for the comparison strings.

The limitation is because PAM doesn't have a way to use it asynchronously 
without using threads or subprocesses, at least for most modules and 
implementations I've seen. 

Matt

Avner Flesch  wrote:

>Hi,
>
>According to the note in options.h file, PAM auth. Support only simple
>modules.
>Is that mean that for example RADIUS authentication can't be supported?
>
>Thanks
>
>Avner

Re: Dropbear and libtommath

[Matt Johnston]

I made a start on this in a mercurial branch (on the public server) but got 
sidetracked trying to get tomsfastmath working on MacOS. I can't remember what 
state it's in, though I think the dropbear code changes are done but untested. 
The tomsfastmath directory mightn't be in a good state though.

Cheers,
Matt

Avner Flesch  wrote:

>Hi,
>
>Has someone did porting of math lib to tomsfastmath (instead of
>libtommath)?
>I am using dropbear 0.52 with such a porting, and it is really reducing
> the login time (I have platform with PPC 75Mhz)
>But I am looking for such a porting for the new dropbear version.
>
>Thanks
>
>Avner

Re: Passphrase keys?

[Matt Johnston]

Hi,

Currently keys can't be encrypted. It would probably be
worth adding - I guess just supporting OpenSSH format would
be most convenient (and also for non-encrypted keys, though
I think they have a different format).

You can use OpenSSH's ssh-agent with Dropbear as an
alternative to encrypted keys, that's what I do on my own
systems.

CHeers,
Matt

On Sat, Jun 30, 2012 at 09:43:47PM -0400, Kyle Evans wrote:
> Hello, I do not see any mention of creating keys with a passphrase.
> If it is somehow possible, please inform. Otherwise, has there been
> any thought of adding the support? I do not feel comfortable having
> a free and clear login key on an android device, which I would like
> to use to connect to and openSSH server.
> 
> Thanks,
> Kyle Evans
> 

Re: forwarding problems

[Matt Johnston]

Ah right. Is the server-side sshd/dropbear process still
running? I guess something hasn't noticed that the client
has gone away, though I'm not really sure what you can do.

Is the embedded device sending icmp port unreachable (or
similar?) packets out, or does it just silently drop the
stale connection's packets?

Matt

On Mon, Jul 23, 2012 at 03:10:12PM +0200, Maris, Rob wrote:
> Thanks for instant answering,
> 
> I was still aware of SO_REUSEADDR in dbutil.c, but could not quickly
> determine whether this also applies to forwarding channels. In any
> case, reconnect goes OK when the embedded system gets a reboot prior
> to poweroff (as could be expected).
> 
> In the problem case, the host netstat shows up
> tcp0  0 localhost.localdo:51225 localhost.localdo:10526
> CLOSE_WAIT
> 
> BTW: I'm using 0.52 on a blackfin platform.
> 
> Regarding strace: Must be prepared. Is not yet built into the root
> file system. I'll return later to it.
> 
> Rob
> 
> Note: I also noticed
> http://comments.gmane.org/gmane.network.ssh.dropbear/962
> before, and the suggestions in that thread will probably be realised
> after the current problem has been solved.
> 
> 
> 
> Am 23.07.2012, 14:32 Uhr, schrieb Matt Johnston :
> 
> >Hi,
> >
> >Dropbear already does SO_REUSEADDR for all listening
> >sockets, see
> >https://secure.ucc.asn.au/hg/dropbear/file/983a817f8e41/dbutil.c#l254
> >
> >Can you run strace on dbclient to see what's failing? Does
> >the server log anything?
> >
> >Cheers,
> >Matt
> >
> >On Mon, Jul 23, 2012 at 02:13:05PM +0200, Maris, Rob wrote:
> >>Use case:
> >>- embedded system running dbclient with server connection that
> >>includes a port forwarding.
> >>- system is powered off, and powered on again
> >>- upon next boot, the following message is given:
> >>dbclient: Remote TCP forward request failed (port 10526 -> 127.0.0.1:22)
> >>
> >>I'd believe that doing a SO_REUSEADDR via setsockopt() would resolve
> >>this issue.
> >>However, I'm not sure and where to implement this (in cli_tcpfwd.c?)
> >>
> >>Thanks for any suggestions.
> >>
> >>Rob

Re: forwarding problems

[Matt Johnston]

When you kill a process the OS will close its TCP connections by sending a 
reset packet to the other side. If the whole machine turns off those packets 
can't be sent.

After it reboots, the OS should reject packets from the stale connections and 
reset them then. But that'll only happen when data or a TCP keepalive is 
transferred (I think).

Matt

"Maris, Rob"  wrote:

>Am 23.07.2012, 17:16 Uhr, schrieb Matt Johnston :
>
>> Ah right. Is the server-side sshd/dropbear process still
>> running? I guess something hasn't noticed that the client
>> has gone away, though I'm not really sure what you can do.
>
>Hm, are you implicitly suggesting that SO_REUSEADDR woudn't help at
>all?
>
>> Is the embedded device sending icmp port unreachable (or
>> similar?) packets out, or does it just silently drop the
>> stale connection's packets?
>
>Well, to just address another point of view: I have never had problems
>in  
>a test phase, where I used two linux desktops or notebooks for
>experiments  
>with communication via two forwarders to one middleman server. Of
>course,  
>any kill of running processes yield a proper closing of tcp channels.
>And  
>I don't brutally switch off my notebook. I didn't try it out (but I
>will  
>do), what its happening, if I brutally power-off my notebook, and see
>what  
>happens when I reestablish a connection with the same forwarder.
>
>Such power cycling is (of course) the natural thing with embedded
>systems.  
>When I then connect to another port - no problem.
>
>Rob
>
>>
>> Matt
>>
>> On Mon, Jul 23, 2012 at 03:10:12PM +0200, Maris, Rob wrote:
>>> Thanks for instant answering,
>>>
>>> I was still aware of SO_REUSEADDR in dbutil.c, but could not quickly
>>> determine whether this also applies to forwarding channels. In any
>>> case, reconnect goes OK when the embedded system gets a reboot prior
>>> to poweroff (as could be expected).
>>>
>>> In the problem case, the host netstat shows up
>>> tcp0  0 localhost.localdo:51225 localhost.localdo:10526
>>> CLOSE_WAIT
>>>
>>> BTW: I'm using 0.52 on a blackfin platform.
>>>
>>> Regarding strace: Must be prepared. Is not yet built into the root
>>> file system. I'll return later to it.
>>>
>>> Rob
>>>
>>> Note: I also noticed
>>> http://comments.gmane.org/gmane.network.ssh.dropbear/962
>>> before, and the suggestions in that thread will probably be realised
>>> after the current problem has been solved.
>>>
>>>
>>>
>>> Am 23.07.2012, 14:32 Uhr, schrieb Matt Johnston :
>>>
>>> >Hi,
>>> >
>>> >Dropbear already does SO_REUSEADDR for all listening
>>> >sockets, see
>>>
>>https://secure.ucc.asn.au/hg/dropbear/file/983a817f8e41/dbutil.c#l254
>>> >
>>> >Can you run strace on dbclient to see what's failing? Does
>>> >the server log anything?
>>> >
>>> >Cheers,
>>> >Matt
>>> >
>>> >On Mon, Jul 23, 2012 at 02:13:05PM +0200, Maris, Rob wrote:
>>> >>Use case:
>>> >>- embedded system running dbclient with server connection that
>>> >>includes a port forwarding.
>>> >>- system is powered off, and powered on again
>>> >>- upon next boot, the following message is given:
>>> >>dbclient: Remote TCP forward request failed (port 10526 ->  
>>> 127.0.0.1:22)
>>> >>
>>> >>I'd believe that doing a SO_REUSEADDR via setsockopt() would
>resolve
>>> >>this issue.
>>> >>However, I'm not sure and where to implement this (in
>cli_tcpfwd.c?)
>>> >>
>>> >>Thanks for any suggestions.
>>> >>
>>> >>Rob

Re: DropBear on Android

[Matt Johnston]

Hi,

There are a few patches at
http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2012q1/001251.html 
I'll probably incorporate those into the next release.

Modifications to QuickSSHD's Dropbear are at
https://github.com/barryk/android_external_dropbear , or see
http://teslacoilsw.com/dropbear

I can't think of much relevant that would have changed in
Dropbear since QuickSSHD's 0.52. You could see if building
that works on your system?

Cheers,
Matt


On Mon, Aug 27, 2012 at 06:05:35PM +0300, Leonid Bloch wrote:
> Hello,
> 
> Has anyone successfully compiled and tested the latest Dropbear on Android?
> If so, can you please share your modifications?
> 
> After few changes that seemed reasonable to me, I still get various error
> messages, and nothing works:
> I've tried logging in with a random user, as well as the user that belongs
> to my terminal emulator app, then the error of the server was:
> "Login attempt for nonexistent user from "
> When I patched further, in the spirit of what is written here:
> http://roycormier.net/2010/11/02/cross-compiling-dropbear-sshd-for-android
> I got something about "shell is missing for the user "
> 
> When tried to run dbclient, the error was:
> "dbclient: Exited: Unknown own user"
> 
> The error in scp was:
> "unknown user 10118"
> 
> I'd appreciate any ideas or instructions.
> 
> 
> Best regards,
> Leonid.

Re: Dropbear calling my own command-line parser than /bin/sh

[Matt Johnston]

Hi,

Take a look at
https://secure.ucc.asn.au/hg/dropbear/rev/0edf08895a33 - it
sends "success" for the first auth request.

Matt

On Tue, Sep 25, 2012 at 04:39:26PM +0800, chinna obireddy wrote:
> Dear All,
> 
> As per the thread
> http://thread.gmane.org/gmane.network.ssh.dropbear/68/focus=75 I was
> successfully made changes to launch CLI application with dropbear ssh.
> 
> But Putty(SSH client) is still asking for Login name, though this is not
> going to be used It looks weird for user asking user name twice. Since the
> CLI application has it's own authentication method.
> 
> Suggest me how can I completely ignore Authentication packets in the server
> side.
> 
> --Reddy.

Re: Dropbear calling my own command-line parser than /bin/sh

[Matt Johnston]

Hi,

I don't think you can avoid it - the best you can do is to
put "something@192.168.14.1" in the host field so it'll send
a username without prompting.

The SSH protocol requires a username in all authentication
requests, so PuTTY assumes it's going to be necessary.

Cheers,
Matt

On Wed, Sep 26, 2012 at 09:51:55AM +0800, chinna obireddy wrote:
> Hey Matt,
> 
> I was able to make it work for any username login return authentication
> success. But the problem is that Putty(Windows) asks for user name, though
> any username will do actually. I don't want the ssh client ask the user to
> enter username at all. How could I achieve that ??
> 
> SSH client:
> 
> Login as: press enter -- shouldn't prompt at all
> username:xxx(CLI auth)
> password:xxx(CLI auth)
> 
> Reddy
> 
> On Tue, Sep 25, 2012 at 8:49 PM, Matt Johnston  wrote:
> 
> > Hi,
> >
> > Take a look at
> > https://secure.ucc.asn.au/hg/dropbear/rev/0edf08895a33 - it
> > sends "success" for the first auth request.
> >
> > Matt
> >
> > On Tue, Sep 25, 2012 at 04:39:26PM +0800, chinna obireddy wrote:
> > > Dear All,
> > >
> > > As per the thread
> > > http://thread.gmane.org/gmane.network.ssh.dropbear/68/focus=75 I was
> > > successfully made changes to launch CLI application with dropbear ssh.
> > >
> > > But Putty(SSH client) is still asking for Login name, though this is not
> > > going to be used It looks weird for user asking user name twice. Since
> > the
> > > CLI application has it's own authentication method.
> > >
> > > Suggest me how can I completely ignore Authentication packets in the
> > server
> > > side.
> > >
> > > --Reddy.
> >

Re: Support to port number in known hosts

[Matt Johnston]

Hi,

That's a good idea. I actually thought Dropbear was already
doing it, I meant to add it a long time ago. I'll try and
get it done in the next release.

Cheers,
Matt

On Thu, Nov 08, 2012 at 07:17:59AM -0300, Salatiel Filho wrote:
> Would it be possible to add support to port numbers in known_hosts
> lines created by dbclient just like openssh ?
> I ask this because if i have multiples ssh servers behind the same
> fqdn in different ports ( port forwarding to different servers)
> dbclient will complain about bad key every time i try to connect at a
> different port in the same fqdn.
> 
> Thanks!
> 
> 
> []'s
> Salatiel

Re: [PATCH] IPv6 bracket notation for listen addresses in -p

[Matt Johnston]

Hi,

Thanks for that, I'll make sure it makes the next release.

Cheers,
Matt

On Tue, Dec 11, 2012 at 12:11:45AM -0500, Ben Jencks wrote:
> Updates parsing of the -p option to handle [2001:dba::]:22 style IPv6
> addresses. This allows binding to specific IPv6 addresses, rather than
> having to bind to all addresses in order to get any IPv6 support. For
> example, you can now listen on IPv6 only with -p [::]:22.
> 
> This has been done before at [1], but I thought that patch
> was kind of ugly so I wrote my own.
> 
> Please CC me on responses as I'm not subscribed to the list.
> 
> [1]
> https://lists.openwrt.org/pipermail/openwrt-devel/2009-May/004299.html
> 
> diff -ur dropbear-2012.55.orig/svr-runopts.c dropbear-2012.55/svr-runopts.c
> --- dropbear-2012.55.orig/svr-runopts.c   2012-02-23 08:47:06.0 
> -0500
> +++ dropbear-2012.55/svr-runopts.c2012-12-10 23:17:28.496729985 -0500
> @@ -324,8 +324,23 @@
>   /* We don't free it, it becomes part of the runopt state */
>   myspec = m_strdup(spec);
>  
> - /* search for ':', that separates address and port */
> - svr_opts.ports[svr_opts.portcount] = strchr(myspec, ':');
> + if (myspec[0] == '[') {
> + myspec++;
> + svr_opts.ports[svr_opts.portcount] = strchr(myspec, 
> ']');
> + if (svr_opts.ports[svr_opts.portcount] == NULL) {
> + /* Unmatched [ -> exit */
> + dropbear_exit("Bad listen address");
> + }
> + svr_opts.ports[svr_opts.portcount][0] = '\0'; 
> + svr_opts.ports[svr_opts.portcount]++;
> + if (svr_opts.ports[svr_opts.portcount][0] != ':') {
> + /* Missing port -> exit */
> + dropbear_exit("Missing port");
> + }
> + } else {
> + /* search for ':', that separates address and port */
> + svr_opts.ports[svr_opts.portcount] = strchr(myspec, 
> ':');
> + }
>  
>   if (svr_opts.ports[svr_opts.portcount] == NULL) {
>   /* no ':' -> the whole string specifies just a port */

Re: Issues after Update from 0.52 to 2012.55; login time; password auth

[Matt Johnston]

Hi,

7 seconds seems slow. Where said that it's a common problem?
I get around 1 second to SSH to a raspberry pi (700mhz "ARMv6").
Was it built with the same compiler and compile options?
Leaving optimisation off could make that difference.

I can't see how it wouldn't ask for a password unless
there's -g or -s on the commandline. Does "ssh -v" show just
"Authentications that can continue: publickey", not
"publickey,password" ?

Cheers,
Matt


On Thu, Jan 03, 2013 at 12:10:51PM +0100, dbext...@gmx.de wrote:
> Hello!
> 
> I'm using dropbear on an embedded System with uCLinux. It works great. And 
> first I want to thank all of you for the work you put in it.
> 
> After reading about the security fix I updated the dropbear from a (very 
> stable and fast) 0.52 to the new 2012.55.
> 
> After the update two things changed. The login time increased a lot. From 
> next to nothing to about 7s (on a 600MHz CPU). I read that this is a common 
> problem, and that my 7s are still quite good. I'm just surprised about he 
> increase. 
> 
> Secondly the dropbear does not allow password login anymore (the server only 
> gives back "pubkey" as available option). The according defines in the 
> options.h are still active though. And the dropbear is started without -s. 
> I'm out of ideas what to try to enable it again. When I just replace the 
> dropbear executable with the 0.52 version it works again.
> 
> Any thoughts and advide is highly appreciated. Tank you in advance.
> 
> Grüße
> Sebastian
> 

Re: RFC: PATCH: Allow configuring "allow blank password option" at runtime

[Matt Johnston]

Hi Paul,

Thanks for that, I've committed it for the next release.

Cheers,
Matt

On Wed, Feb 20, 2013 at 04:51:14PM +, Paul Eggleton wrote:
> Hi there,
> 
> Attached is a patch we've developed for dropbear within the Yocto Project to 
> avoid the need to rebuild dropbear when we wish to disable the ability to log 
> into accounts that have a blank password set. It removes the compile-time 
> option and adds a -B command-line option which enables the functionality.
> 
> We'd really like to see this (or something like it) upstream. If an 
> alternative implementation would be preferred please let me know.
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre   

> # HG changeset patch
> # User Paul Eggleton 
> # Date 1360684377 0
> # Node ID 92aea57140965ca60e40f99d485c14f0425afd90
> # Parent  63f8d6c469cf51624c9a48dbac1f2ae9b4cd82b6
> Allow configuring "allow blank password option" at runtime
> 
> Changes this from a compile-time switch to a command-line option.
> 
> Signed-off-by: Paul Eggleton 
> 
> diff -r 63f8d6c469cf -r 92aea5714096 options.h
> --- a/options.h   Thu May 17 00:26:12 2012 +0800
> +++ b/options.h   Tue Feb 12 15:52:57 2013 +
> @@ -180,11 +180,6 @@
>  #define ENABLE_SVR_PUBKEY_OPTIONS
>  #endif
>  
> -/* Define this to allow logging in to accounts that have no password 
> specified.
> - * Public key logins are allowed for blank-password accounts regardless of 
> this
> - * setting. */
> -/* #define ALLOW_BLANK_PASSWORD */
> -
>  #define ENABLE_CLI_PASSWORD_AUTH
>  #define ENABLE_CLI_PUBKEY_AUTH
>  #define ENABLE_CLI_INTERACT_AUTH
> diff -r 63f8d6c469cf -r 92aea5714096 runopts.h
> --- a/runopts.h   Thu May 17 00:26:12 2012 +0800
> +++ b/runopts.h   Tue Feb 12 15:52:57 2013 +
> @@ -89,6 +89,7 @@
>  
>   int noauthpass;
>   int norootpass;
> + int allowblankpass;
>  
>  #ifdef ENABLE_SVR_REMOTETCPFWD
>   int noremotetcp;
> diff -r 63f8d6c469cf -r 92aea5714096 svr-auth.c
> --- a/svr-auth.c  Thu May 17 00:26:12 2012 +0800
> +++ b/svr-auth.c  Tue Feb 12 15:52:57 2013 +
> @@ -154,8 +154,8 @@
>   strncmp(methodname, AUTH_METHOD_NONE,
>   AUTH_METHOD_NONE_LEN) == 0) {
>   TRACE(("recv_msg_userauth_request: 'none' request"))
> -#ifdef ALLOW_BLANK_PASSWORD
> - if (!svr_opts.noauthpass 
> + if (svr_opts.allowblankpass
> + && !svr_opts.noauthpass
>   && !(svr_opts.norootpass && 
> ses.authstate.pw_uid == 0) 
>   && ses.authstate.pw_passwd[0] == '\0') 
>   {
> @@ -167,7 +167,6 @@
>   goto out;
>   }
>   else
> -#endif
>   {
>   send_msg_userauth_failure(0, 0);
>   goto out;
> diff -r 63f8d6c469cf -r 92aea5714096 svr-authpasswd.c
> --- a/svr-authpasswd.cThu May 17 00:26:12 2012 +0800
> +++ b/svr-authpasswd.cTue Feb 12 15:52:57 2013 +
> @@ -29,6 +29,7 @@
>  #include "buffer.h"
>  #include "dbutil.h"
>  #include "auth.h"
> +#include "runopts.h"
>  
>  #ifdef ENABLE_SVR_PASSWORD_AUTH
>  
> diff -r 63f8d6c469cf -r 92aea5714096 svr-runopts.c
> --- a/svr-runopts.c   Thu May 17 00:26:12 2012 +0800
> +++ b/svr-runopts.c   Tue Feb 12 15:52:57 2013 +
> @@ -63,6 +63,7 @@
>  #if defined(ENABLE_SVR_PASSWORD_AUTH) || defined(ENABLE_SVR_PAM_AUTH)
>   "-s Disable password 
> logins\n"
>   "-g Disable password logins 
> for root\n"
> + "-B Allow blank password 
> logins\n"
>  #endif
>  #ifdef ENABLE_SVR_LOCALTCPFWD
>   "-j Disable local port 
> forwarding\n"
> @@ -115,6 +116,7 @@
>   svr_opts.norootlogin = 0;
>   svr_opts.noauthpass = 0;
>   svr_opts.norootpass = 0;
> + svr_opts.allowblankpass = 0;
>   svr_opts.inetdmode = 0;
>   svr_opts.portcount = 0;
>   svr_opts.hostkey = NULL;
> @@ -234,6 +236,9 @@
>   case 'g':
>   svr_opts.norootpass = 1;
>   break;
> + case 'B':
> + svr_opts.allowblankpass = 1;
> + break;
>  #endif
>   case 'h':
>   printhelp(argv[0]);

Re: Problem with Dropbear/dbclient as SFTP client

[Matt Johnston]

Hi,

Dropbear doesn't have its own sftp client, but you can use
it with the OpenSSH sftp client:

sftp -S dbclient user@host

Cheers,
Matt

On Thu, Feb 28, 2013 at 05:39:27PM +0100, Alexis-externe DAVOUX wrote:
> Hi,
> 
> I have some trouble with dropbear used as SFTP client.
> 
> I've set up a SFTP server on my machine, which works fine. I've tested the 
> connection to the server with Filezilla client.
> I've tried connecting to the SFTP server with dropbear using the command:
> 
> dbclient -s user@host sftp
> 
> I can authenticate successfully, and I get the welcome message, but after 
> that I can't do anything: it seems that dbclient is waiting for some 
> command but nothing seems to work. I've tried entering 'ls', 'cd /test', 
> 'get test.txt', 'pwd',... but nothing happens when I validate with enter.
> 
> How can I use dbclient as SFTP client ? What is the correct syntax ?
> 
> Thanks in advance,
> Best regards,
> 
> Alexis

Re: Problem with Dropbear/dbclient as SFTP client

[Matt Johnston]

On Fri, Mar 01, 2013 at 02:47:05PM +0100, Alexis-externe DAVOUX wrote:
> Hi Matt,
> 
> Thanks for your quick answer.
> If I understand correctly, the dbclient establishes the underlying SSH 
> connection with the SFTP server, but does not implement a whole SFTP 
> client.
> So I have to use a separate sftp client (such as sftp from OpenSSH), which 
> can rely on Dropbear to establish the SSH connection with the server.

Yes, that's right.

> OK, this is clearer now, thanks. I think that a mention of this on your 
> website or in the Readme file could be useful.

That's a good point, I've mentioned it in the manpage now.

Cheers,
Matt

Dropbear 2013.56 released

[Matt Johnston]

Hi all,

Dropbear 2013.56 is now released, with a mix of features and
bug fixes. Download as usual at
https://matt.ucc.asn.au/dropbear/dropbear.html

I've also set up a github mirror of the Dropbear mercurial
repository at https://github.com/mkj/dropbear . It'll be
read-only but might be of use to the various forks.

Cheers,
Matt

2013.56 - Thursday 21 March 2013

- Allow specifying cipher (-c) and MAC (-m) lists for dbclient

- Allow using 'none' cipher or MAC (off by default, use options.h). Encryption
  is used during authentication then disabled, similar to OpenSSH HPN mode

- Allow a user in immediately if the account has a blank password and blank
  passwords are enabled

- Include a few extra sources of entropy from /proc on Linux, hash private keys
  as well. Dropbear will also write gathered entropy back into /dev/urandom

- Added hmac-sha2-256 and hmac-sha2-512 support (off by default, use options.h)

- Don't sent bad address "localhost" for -R forward connections, 
  reported by Denis Bider

- Add "-B" runtime option to allow blank passwords

- Allow using IPv6 bracket notation for addresses in server "-p" option, from 
Ben Jencks

- A few improvements for Android from Reimar Döffinger

- Fix memory leak for TCP forwarded connections to hosts that timed out,
  reported by Norbert Benczúr. Appears to be a very long-standing bug.

- Fix "make clean" for out of tree builds

- Fix compilation when ENABLE_{SVR,CLI}_AGENTFWD are unset

Re: Dropbear 2013.56 released

[Matt Johnston]

Hg-Git, http://hg-git.github.com/

Matt

Rob Landley  wrote:

>On 03/21/2013 10:40:46 AM, Matt Johnston wrote:
>> Hi all,
>> 
>> Dropbear 2013.56 is now released, with a mix of features and
>> bug fixes. Download as usual at
>> https://matt.ucc.asn.au/dropbear/dropbear.html
>> 
>> I've also set up a github mirror of the Dropbear mercurial
>> repository at https://github.com/mkj/dropbear . It'll be
>> read-only but might be of use to the various forks.
>
>What are you using to mirror it?
>
>Rob

Re: Timeout dead connections

[Matt Johnston]

Hi,

At the very least if there is traffic on the connection
(which -K will ensure) then TCP should timeout and the
connection should eventually (a minute or so?) close. 

Can you get a packet capture with tcpdump?

Cheers,
Matt

On Wed, Mar 27, 2013 at 04:24:27PM +0100, Mattias Walström wrote:
> Hi!
> I am running dropbear 2013.56, connecting to the server with a PC but
> not performing a clean close (I pulled my ethernet cable), this caused
> dropbear to never drop its connection.
> 
> Looking at the utmp entries, I could see that the connection never got 
> dropped,
> the utmp entries was kept forever, and running with debug indicates that also.
> Tried to use -K to send keepalive, but it just keeps sending keepalives to 
> the peer,
> even it is no longer there, and not possible to reach. Shouldn't
> the connection be dropped if the keepalive does not reach its destination?
> 
> I know there is the -I option, but that does not really do what I want,
> I want the connection to be tear down when the peer is unreachable, not
> when the user has been idle for a while.
> 
> Regards
>  Mattias

Re: Timeout dead connections

[Matt Johnston]

I thought those were fixed in 0.53 or perhaps 2011.54:

2011.54 - Tuesday 8 November 2011
- Fixed case where "-K 1" keepalive for dbclient would cause a SSH_MSG_IGNORE
  packet to be sent
0.53 - Thurs 24 February 2011
- Make -K (keepalive) and -I (idle timeout) work together sensibly in the 
client.
  The idle timeout is no longer reset by SSH_MSG_IGNORE packets.

If the network cable has been pulled out, shouldn't the OS send a TCP RST
packet eventually after some traffic and close the connection?

Cheers,
Matt


On Wed, Mar 27, 2013 at 11:41:40AM -0400, Fabrizio Bertocci wrote:
> I remember reporting this problem and sending a patch long time ago (for
> version 0.52).
> 
> The problem with the keep-alive (if I remember correctly) was that every
> time dropbear was sending the keep-alive message, it was also resetting the
> timeout counter... so dropbear or dbclient never detect the dropped
> connection.
> Here is an extract from my old email sent on 9/29/2010:
> 
> Hope this help,
> Regards,
> Fabrizio
> 
> 
> 
> First Issue: When keep-alive messages are sent, they reset the idle timeout
> counter. (-I counter).
> I would expect that SENT messages (in particular keep-alive packets) do not
> affect the idle timeout...
> This is in function write_packet() (file packet.c)
> When a message is written, it stores the current time in both the registers
> for the last packet transmitted *AND* last packet (for the idle timeout):
> ses.last_trx_packet_time = time(NULL);
> ses.last_packet_time = time(NULL);
> 
> (beside that, this cause two system calls, to read the time, when only one
> would be needed... just optimizing :) )
> This is a little unexpected because I would think that the idle timeout
> works only on received packets, not about sent packets.
> Basically if I start dropbear with -I and -K options, the idle timeout will
> never kick in... because the keepalive will always reset the timer even if
> the connection is dead.
> 
> I'm proposing to simply remove the line:
> ses.last_packet_time = time(NULL);
> So the idle timeout does not get reset when any packet is sent.
> 
> Watch out: after this change, the semantic of the argument -I is different
> than before, as it only consider received packets... but at least it makes
> more sense.
> Here is a scenario WITHOUT this modification:
> 1. Start the server with: dropbear -K 15 -I 20  [...]
> 2. Start the client with dbclient -K 15 [...]
> 3. On my device, start a program that sends data over one tunneled port
> Everything works fine, connection is up and data is exchanging.
> Now...
> 4. Unplug my embedded device (the one running dbclient)
> -> The server does not detect the connection is down. Any attempt to access
> a tunneled port cause the caller to hang.
> 
> now, after this change, with the same scenario, after I unplug my box, the
> server detects it after 20 seconds and closes the connection.
> 
> 
> Second Issue: When a keepalive message is received, the idle timeout timer
> (for received packets) is NOT updated.
> I'm referring here to the function 'process_packet()' in file
> 'process-packet.c'.
> Here the timer update:
> ses.last_packet_time = time(NULL);
> is performed AFTER the first switch where we check for SSH_MSG_IGNORE,
> SSH_MSG_DEBUG, SSH_MSG_UNIMPLEMENTED, and SSH_MSG_DISCONNECT.
> So, in few words: although a keep-alive message (that is a message of type
> SSH_MSG_IGNORE) is correctly ignored, but the timer is not reset.
> 
> Here is what happen:
> 1. Start my server again with dropbear -I 20 [...]
> 2. Start my client with dropbear -K 15 [...]
> (this time I'm not starting my application to send data over a tunneled
> port)
> 
> Without doing anything, the server will close the connection after 20
> seconds. No matter if the client have sent the keep-alivemessages...
> 
> After moving that statement:
> ses.last_packet_time = time(NULL);
> BEFORE the first switch(), now a keep-alive message cause the idle timer to
> reset, and the previous test case works as expected (server does't
> disconnect).
> 
> So, in conclusion, as you see, these two small changes are critical for my
> situation, and I believe they could also benefit others with similar needs.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Mar 27, 2013 at 11:24 AM, Mattias Walström <
> mattias.walst...@westermo.se> wrote:
> 
> > Hi!
> > I am running dropbear 2013.56, connecting to the server with a PC but
> > not performing a clean close (I pulled my ethernet cable), this caused
> > dropbear to never drop its connection.
> >
> > Looking at the utmp entries, I could see that the connection never got
> > dropped,
> > the utmp entries was kept forever, and running with debug indicates that
> > also.
> >  Tried to use -K to send keepalive, but it just keeps sending keepalives
> > to the

Re: Timeout dead connections

[Matt Johnston]

I think that -K on the server should be enough. On the
server can you run "tcpdump -i eth0 -w cap1.cap port 22",
get a ssh session going, pull out the cable, wait 10
minutes, then send me the capture?

Could you also check that the Dropbear process for the
connection is still running after the connection should have
been finished. It's possible that the process is exiting but
the session cleanup code isn't working correctly. The whole
debug log might give me an idea what's going on.

Cheers,
Matt

On Thu, Mar 28, 2013 at 09:56:02AM +0100, Mattias Walström wrote:
> Thanks for your responses, all your suggestions imply that you should do 
> something
> in the client (set keepalive on client end), but shouldn't the server itself 
> be able to
> decide if a client is dead (can't OpenSSH do this?).
> 
> If I do the -K 15 -I 20 on the server end only, this will close the 
> connection when
> the OpenSSH client has not sent any characters in 20s. I expected the 
> keepalive to be
> two way, that the server got responses on these packages as well, is that not 
> the case?
> 
> Regards
>  Mattias

> >>On Wed, Mar 27, 2013 at 11:24 AM, Mattias Walström <
> >>mattias.walst...@westermo.se> wrote:
> >>
> >>>Hi!
> >>>I am running dropbear 2013.56, connecting to the server with a PC but
> >>>not performing a clean close (I pulled my ethernet cable), this caused
> >>>dropbear to never drop its connection.
> >>>
> >>>Looking at the utmp entries, I could see that the connection never got
> >>>dropped,
> >>>the utmp entries was kept forever, and running with debug indicates that
> >>>also.
> >>>  Tried to use -K to send keepalive, but it just keeps sending keepalives
> >>>to the peer,
> >>>even it is no longer there, and not possible to reach. Shouldn't
> >>>the connection be dropped if the keepalive does not reach its destination?
> >>>
> >>>I know there is the -I option, but that does not really do what I want,
> >>>I want the connection to be tear down when the peer is unreachable, not
> >>>when the user has been idle for a while.
> >>>
> >>>Regards
> >>>  Mattias
> >>>
> 

Re: scp issue in 0.56

[Matt Johnston]

Hi,

Thanks for pointing that out, I'll fix it in the next
release.

Cheers,
Matt

On Thu, Mar 28, 2013 at 05:51:58PM +0100, Frank Van Uffelen wrote:
> Hello, I think I've found a problem in the scp implementation in 0.56:
> lines 233-235 of scp.c say:
> 
> #ifdef USE_VFORK
> arg_setup(host, remuser, cmd);
> #endif
> 
> and IMO it should be
> 
> #ifndef USE_VFORK
> arg_setup(host, remuser, cmd);
> #endif
> 
> which would correspond to the logic in previous releases.  As it is now,
> dbclient will complain and show its help because arg_setup is never
> executed on systems using a regular fork() call.
> 
> Do you agree?
> 
> Best regards,
> 
> 
> Frank Van Uffelen

Re: Timeout dead connections

[Matt Johnston]

Hi,

The attached attached patch against 2013.56 should fix it, or
https://secure.ucc.asn.au/hg/dropbear/rev/70811267715c

Dropbear wasn't running cleanup handlers when it exited due
to the TCP connection being closed.

Matt

On Thu, Mar 28, 2013 at 07:24:55PM +0800, Matt Johnston wrote:
> I think that -K on the server should be enough. On the
> server can you run "tcpdump -i eth0 -w cap1.cap port 22",
> get a ssh session going, pull out the cable, wait 10
> minutes, then send me the capture?
> 
> Could you also check that the Dropbear process for the
> connection is still running after the connection should have
> been finished. It's possible that the process is exiting but
> the session cleanup code isn't working correctly. The whole
> debug log might give me an idea what's going on.
> 
> Cheers,
> Matt
> 
> On Thu, Mar 28, 2013 at 09:56:02AM +0100, Mattias Walström wrote:
> > Thanks for your responses, all your suggestions imply that you should do 
> > something
> > in the client (set keepalive on client end), but shouldn't the server 
> > itself be able to
> > decide if a client is dead (can't OpenSSH do this?).
> > 
> > If I do the -K 15 -I 20 on the server end only, this will close the 
> > connection when
> > the OpenSSH client has not sent any characters in 20s. I expected the 
> > keepalive to be
> > two way, that the server got responses on these packages as well, is that 
> > not the case?
> > 
> > Regards
> >  Mattias
> 
> > >>On Wed, Mar 27, 2013 at 11:24 AM, Mattias Walström <
> > >>mattias.walst...@westermo.se> wrote:
> > >>
> > >>>Hi!
> > >>>I am running dropbear 2013.56, connecting to the server with a PC but
> > >>>not performing a clean close (I pulled my ethernet cable), this caused
> > >>>dropbear to never drop its connection.
> > >>>
> > >>>Looking at the utmp entries, I could see that the connection never got
> > >>>dropped,
> > >>>the utmp entries was kept forever, and running with debug indicates that
> > >>>also.
> > >>>  Tried to use -K to send keepalive, but it just keeps sending keepalives
> > >>>to the peer,
> > >>>even it is no longer there, and not possible to reach. Shouldn't
> > >>>the connection be dropped if the keepalive does not reach its 
> > >>>destination?
> > >>>
> > >>>I know there is the -I option, but that does not really do what I want,
> > >>>I want the connection to be tear down when the peer is unreachable, not
> > >>>when the user has been idle for a while.
> > >>>
> > >>>Regards
> > >>>  Mattias
> > >>>
> > 

Re: Timeout dead connections

[Matt Johnston]

And the patch actually attached here.

On Mon, Apr 01, 2013 at 11:01:42PM +0800, Matt Johnston wrote:
> Hi,
> 
> The attached attached patch against 2013.56 should fix it, or
> https://secure.ucc.asn.au/hg/dropbear/rev/70811267715c
> 
> Dropbear wasn't running cleanup handlers when it exited due
> to the TCP connection being closed.
> 
> Matt
> 
> On Thu, Mar 28, 2013 at 07:24:55PM +0800, Matt Johnston wrote:
> > I think that -K on the server should be enough. On the
> > server can you run "tcpdump -i eth0 -w cap1.cap port 22",
> > get a ssh session going, pull out the cable, wait 10
> > minutes, then send me the capture?
> > 
> > Could you also check that the Dropbear process for the
> > connection is still running after the connection should have
> > been finished. It's possible that the process is exiting but
> > the session cleanup code isn't working correctly. The whole
> > debug log might give me an idea what's going on.
> > 
> > Cheers,
> > Matt
> > 
> > On Thu, Mar 28, 2013 at 09:56:02AM +0100, Mattias Walström wrote:
> > > Thanks for your responses, all your suggestions imply that you should do 
> > > something
> > > in the client (set keepalive on client end), but shouldn't the server 
> > > itself be able to
> > > decide if a client is dead (can't OpenSSH do this?).
> > > 
> > > If I do the -K 15 -I 20 on the server end only, this will close the 
> > > connection when
> > > the OpenSSH client has not sent any characters in 20s. I expected the 
> > > keepalive to be
> > > two way, that the server got responses on these packages as well, is that 
> > > not the case?
> > > 
> > > Regards
> > >  Mattias
> > 
> > > >>On Wed, Mar 27, 2013 at 11:24 AM, Mattias Walström <
> > > >>mattias.walst...@westermo.se> wrote:
> > > >>
> > > >>>Hi!
> > > >>>I am running dropbear 2013.56, connecting to the server with a PC but
> > > >>>not performing a clean close (I pulled my ethernet cable), this caused
> > > >>>dropbear to never drop its connection.
> > > >>>
> > > >>>Looking at the utmp entries, I could see that the connection never got
> > > >>>dropped,
> > > >>>the utmp entries was kept forever, and running with debug indicates 
> > > >>>that
> > > >>>also.
> > > >>>  Tried to use -K to send keepalive, but it just keeps sending 
> > > >>> keepalives
> > > >>>to the peer,
> > > >>>even it is no longer there, and not possible to reach. Shouldn't
> > > >>>the connection be dropped if the keepalive does not reach its 
> > > >>>destination?
> > > >>>
> > > >>>I know there is the -I option, but that does not really do what I want,
> > > >>>I want the connection to be tear down when the peer is unreachable, not
> > > >>>when the user has been idle for a while.
> > > >>>
> > > >>>Regards
> > > >>>  Mattias
> > > >>>
> > > 
diff -r 1b8b2b9d6e94 cli-main.c
--- a/cli-main.c	Thu Mar 21 23:29:04 2013 +0800
+++ b/cli-main.c	Mon Apr 01 22:59:26 2013 +0800
@@ -98,8 +98,7 @@
 	}
 
 	/* Do the cleanup first, since then the terminal will be reset */
-	cli_session_cleanup();
-	common_session_cleanup();
+	session_cleanup();
 
 	_dropbear_log(LOG_INFO, fmtbuf, param);
 
diff -r 1b8b2b9d6e94 cli-session.c
--- a/cli-session.c	Thu Mar 21 23:29:04 2013 +0800
+++ b/cli-session.c	Mon Apr 01 22:59:26 2013 +0800
@@ -41,6 +41,7 @@
 static void cli_sessionloop();
 static void cli_session_init();
 static void cli_finished();
+static void cli_session_cleanup(void);
 
 struct clientsession cli_ses; /* GLOBAL */
 
@@ -142,6 +143,7 @@
 
 	/* For printing "remote host closed" for the user */
 	ses.remoteclosed = cli_remoteclosed;
+	ses.extra_session_cleanup = cli_session_cleanup;
 	ses.buf_match_algo = cli_buf_match_algo;
 
 	/* packet handlers */
@@ -278,7 +280,7 @@
 
 }
 
-void cli_session_cleanup() {
+static void cli_session_cleanup(void) {
 
 	if (!sessinitdone) {
 		return;
@@ -296,8 +298,7 @@
 
 static void cli_finished() {
 
-	cli_session_cleanup();
-	common_session_cleanup();
+	session_cleanup();
 	fprintf(stderr, "Connection to %s@%s:%s closed.\n", cli_opts.username,
 			cli_opts.remotehost, cli_opts.remoteport);
 	exit(cli_ses.retval);
diff -r 1b8b2b9d6e94 common-session.c
--- a/common-session.c	Thu Mar 21 23:29:04 2013 +0800

Re: segfault RH EL5 /dev/urandom read-only

[Matt Johnston]

That's a bit unfortunate, I've fixed it in 
https://secure.ucc.asn.au/hg/dropbear/rev/73b6e5d8801b

Cheers,
Matt

Scott Case  wrote:

>I just built the 2013.56 release and am receiving segfaults on startup.
>The offending line is the fwrite() in random.c in write_urandom().
>
>Our RHEL 5 servers appear to have /dev/urandom as read-only.  I am
>guessing that is likely the root cause.
>
> 
>
>Commenting out the internals of write_urandom() stopped the segfault.  
>
> 
>
>Maybe a build flag to avoid writing to /dev/urandom would be
>appropriate
>for some platforms?
>
> 
>
>Thanks,
>
>Scott
>
> 

Re: Timeout dead connections

[Matt Johnston]

Are you using -K ? I wouldn't expect it to time out otherwise. As an 
example I hibernate my computer nightly but connections remain alive in 
the morning.


Cheers,
Matt

On 2013-04-05 16:25, Mattias Walström wrote:

Hi!
I still have problems, this is my output from 'who':
admin   pts/0   02:50   Apr  5 07:24:09  x.x.x.x
admin   pts/1   00:00   Apr  5 09:39:05  y.y.y.y

current time:
Fri Apr  5 10:18:27 CEST 2013

shouldn't the first session be timed out? It has not just been idle
for 2 h 50 min,
the computer is not there any more. So in my opinion, dropbear should
have forgotten the
connection.

Mattias

On 2013-04-01 17:01, Matt Johnston wrote:

Hi,

The attached attached patch against 2013.56 should fix it, or
https://secure.ucc.asn.au/hg/dropbear/rev/70811267715c

Dropbear wasn't running cleanup handlers when it exited due
to the TCP connection being closed.

Matt

On Thu, Mar 28, 2013 at 07:24:55PM +0800, Matt Johnston wrote:

I think that -K on the server should be enough. On the
server can you run "tcpdump -i eth0 -w cap1.cap port 22",
get a ssh session going, pull out the cable, wait 10
minutes, then send me the capture?

Could you also check that the Dropbear process for the
connection is still running after the connection should have
been finished. It's possible that the process is exiting but
the session cleanup code isn't working correctly. The whole
debug log might give me an idea what's going on.

Cheers,
Matt

On Thu, Mar 28, 2013 at 09:56:02AM +0100, Mattias Walström wrote:
Thanks for your responses, all your suggestions imply that you 
should do something
in the client (set keepalive on client end), but shouldn't the 
server itself be able to

decide if a client is dead (can't OpenSSH do this?).

If I do the -K 15 -I 20 on the server end only, this will close 
the connection when
the OpenSSH client has not sent any characters in 20s. I expected 
the keepalive to be
two way, that the server got responses on these packages as well, 
is that not the case?


Regards
  Mattias



On Wed, Mar 27, 2013 at 11:24 AM, Mattias Walström <
mattias.walst...@westermo.se> wrote:


Hi!
I am running dropbear 2013.56, connecting to the server with a 
PC but
not performing a clean close (I pulled my ethernet cable), this 
caused

dropbear to never drop its connection.

Looking at the utmp entries, I could see that the connection 
never got

dropped,
the utmp entries was kept forever, and running with debug 
indicates that

also.
  Tried to use -K to send keepalive, but it just keeps sending 
keepalives

to the peer,
even it is no longer there, and not possible to reach. 
Shouldn't
the connection be dropped if the keepalive does not reach its 
destination?


I know there is the -I option, but that does not really do what 
I want,
I want the connection to be tear down when the peer is 
unreachable, not

when the user has been idle for a while.

Regards
  Mattias

Re: Timeout dead connections

[Matt Johnston]

Roy Tam  wrote:
>I got same issue with 2012.55-1.3@debian(debian does not have 2013.56
>at the moment) without -K switch.
>Once I not issuing 'exit' command but closing putty window directly,
>the session leaves alone.

That sounds exactly like the situation fixed in 2013.56

Cheers,
Matt
>
>>
>> Cheers,
>> Matt
>>
>>
>> On 2013-04-05 16:25, Mattias Walström wrote:
>>>
>>> Hi!
>>> I still have problems, this is my output from 'who':
>>> admin   pts/0   02:50   Apr  5 07:24:09  x.x.x.x
>>> admin   pts/1   00:00   Apr  5 09:39:05  y.y.y.y
>>>
>>> current time:
>>> Fri Apr  5 10:18:27 CEST 2013
>>>
>>> shouldn't the first session be timed out? It has not just been idle
>>> for 2 h 50 min,
>>> the computer is not there any more. So in my opinion, dropbear
>should
>>> have forgotten the
>>> connection.
>>>
>>> Mattias
>>>
>>> On 2013-04-01 17:01, Matt Johnston wrote:
>>>>
>>>> Hi,
>>>>
>>>> The attached attached patch against 2013.56 should fix it, or
>>>> https://secure.ucc.asn.au/hg/dropbear/rev/70811267715c
>>>>
>>>> Dropbear wasn't running cleanup handlers when it exited due
>>>> to the TCP connection being closed.
>>>>
>>>> Matt
>>>>
>>>> On Thu, Mar 28, 2013 at 07:24:55PM +0800, Matt Johnston wrote:
>>>>>
>>>>> I think that -K on the server should be enough. On the
>>>>> server can you run "tcpdump -i eth0 -w cap1.cap port 22",
>>>>> get a ssh session going, pull out the cable, wait 10
>>>>> minutes, then send me the capture?
>>>>>
>>>>> Could you also check that the Dropbear process for the
>>>>> connection is still running after the connection should have
>>>>> been finished. It's possible that the process is exiting but
>>>>> the session cleanup code isn't working correctly. The whole
>>>>> debug log might give me an idea what's going on.
>>>>>
>>>>> Cheers,
>>>>> Matt
>>>>>
>>>>> On Thu, Mar 28, 2013 at 09:56:02AM +0100, Mattias Walström wrote:
>>>>>>
>>>>>> Thanks for your responses, all your suggestions imply that you
>should
>>>>>> do something
>>>>>> in the client (set keepalive on client end), but shouldn't the
>server
>>>>>> itself be able to
>>>>>> decide if a client is dead (can't OpenSSH do this?).
>>>>>>
>>>>>> If I do the -K 15 -I 20 on the server end only, this will close
>the
>>>>>> connection when
>>>>>> the OpenSSH client has not sent any characters in 20s. I expected
>the
>>>>>> keepalive to be
>>>>>> two way, that the server got responses on these packages as well,
>is
>>>>>> that not the case?
>>>>>>
>>>>>> Regards
>>>>>>   Mattias
>>>>>
>>>>>
>>>>>>>> On Wed, Mar 27, 2013 at 11:24 AM, Mattias Walström <
>>>>>>>> mattias.walst...@westermo.se> wrote:
>>>>>>>>
>>>>>>>>> Hi!
>>>>>>>>> I am running dropbear 2013.56, connecting to the server with a
>PC
>>>>>>>>> but
>>>>>>>>> not performing a clean close (I pulled my ethernet cable),
>this
>>>>>>>>> caused
>>>>>>>>> dropbear to never drop its connection.
>>>>>>>>>
>>>>>>>>> Looking at the utmp entries, I could see that the connection
>never
>>>>>>>>> got
>>>>>>>>> dropped,
>>>>>>>>> the utmp entries was kept forever, and running with debug
>indicates
>>>>>>>>> that
>>>>>>>>> also.
>>>>>>>>>   Tried to use -K to send keepalive, but it just keeps sending
>>>>>>>>> keepalives
>>>>>>>>> to the peer,
>>>>>>>>> even it is no longer there, and not possible to reach.
>Shouldn't
>>>>>>>>> the connection be dropped if the keepalive does not reach its
>>>>>>>>> destination?
>>>>>>>>>
>>>>>>>>> I know there is the -I option, but that does not really do
>what I
>>>>>>>>> want,
>>>>>>>>> I want the connection to be tear down when the peer is
>unreachable,
>>>>>>>>> not
>>>>>>>>> when the user has been idle for a while.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>   Mattias
>>>>>>>>>
>>>>>>
>>

Re: Patch for stricthostkey and a multihop fix

[Matt Johnston]

Hi,

Thanks for the patch. I think I'll change it slightly to use
"-y -y" rather than "-Y" - saves using another letter.

Cheers,
Matt

On Sun, Apr 07, 2013 at 04:03:37PM +0200, Hans Harder wrote:
> Underneath some modifications against a stock 2013.56 version
> 
> - Added -Y option to completely ignore check for hostkeys
>   Needed this for connections to logical hosts, same as openssh -o
> StrictHostKeychecking=no
> 
> - Added -y and -Y in function multihop_passthrough_args
> 
> - fix: in function multihop_passthrough_args there was no space kept
> between the -W and -i args
>   so added always a space after each added arg
>   after last addition the last space is removed.
> 
> I am new to the dropbear sources, so perhaps I didn't see it
> correctlyif so please correct me...
> Overall nice sourcecode, very clean.
> 
> Hans
> ---
> Quote:  ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
> 
> 
> diff -ruBpN dropbear-2013.56/cli-kex.c work/cli-kex.c
> --- dropbear-2013.56/cli-kex.c  2013-03-21 08:29:34.0 -0700
> +++ work/cli-kex.c  2013-04-07 03:01:31.0 -0600
> @@ -217,6 +217,11 @@ static void checkhostkey(unsigned char*
> buffer * line = NULL;
> int ret;
> 
> +   if (!cli_opts.strict_hostkey) {
> +   TRACE(("strict_hostkey disabled, ignoring hostkey check"));
> +   return;
> +}
> +
> hostsfile = open_known_hosts_file(&readonly);
> if (!hostsfile) {
> ask_to_confirm(keyblob, keybloblen);
> diff -ruBpN dropbear-2013.56/cli-runopts.c work/cli-runopts.c
> --- dropbear-2013.56/cli-runopts.c  2013-03-21 08:29:34.0 -0700
> +++ work/cli-runopts.c  2013-04-07 03:08:59.0 -0600
> @@ -62,6 +62,7 @@ static void printhelp() {
> "-NDon't run a remote command\n"
> "-fRun in background after auth\n"
> "-yAlways accept remote
> host key if unknown\n"
> +   "-YAlways ignore the
> remote host key\n"
> "-sRequest a subsystem
> (use by external sftp)\n"
>  #ifdef ENABLE_CLI_PUBKEY_AUTH
> "-i(multiple
> allowed)\n"
> @@ -130,6 +131,7 @@ void cli_getopts(int argc, char ** argv)
> cli_opts.backgrounded = 0;
> cli_opts.wantpty = 9; /* 9 means "it hasn't been touched",
> gets set later */
> cli_opts.always_accept_key = 0;
> +   cli_opts.strict_hostkey = 1;
> cli_opts.is_subsystem = 0;
>  #ifdef ENABLE_CLI_PUBKEY_AUTH
> cli_opts.privkeys = list_new();
> @@ -215,6 +217,9 @@ void cli_getopts(int argc, char ** argv)
> case 'y': /* always accept the remote hostkey 
> */
> cli_opts.always_accept_key = 1;
> break;
> +   case 'Y': /* always ignore the remote hostkey 
> */
> +   cli_opts.strict_hostkey = 0;
> +   break;
> case 'p': /* remoteport */
> next = &cli_opts.remoteport;
> break;
> @@ -461,20 +466,32 @@ multihop_passthrough_args() {
> int total;
> unsigned int len = 0;
> m_list_elem *iter;
> -   /* Fill out -i and -W options that make sense for all
> +   /* Fill out -i , -W, -y and -Y options that make sense for all
>  * the intermediate processes */
> for (iter = cli_opts.privkeys->first; iter; iter = iter->next)
> {
> sign_key * key = (sign_key*)iter->item;
> len += 3 + strlen(key->filename);
> }
> -   len += 20; // space for -W , terminator.
> +   len += 30; // space for -W , terminator.
> ret = m_malloc(len);
> total = 0;
> 
> +   if (cli_opts.always_accept_key)
> +   {
> +   int written = snprintf(ret+total, len-total, "-y ");
> +   total += written;
> +   }
> +
> +   if (cli_opts.strict_hostkey == 0)
> +   {
> +   int written = snprintf(ret+total, len-total, "-Y ");
> +   total += written;
> +   }
> +
> if (opts.recv_window != DEFAULT_RECV_WINDOW)
> {
> -   int written = snprintf(ret+total, len-total, "-W %d",
> opts.recv_window);
> +   int written = snprintf(ret+total, len-total, "-W %d ",
> opts.recv_window);
> total += written;
> }
> 
> @@ -482,11 +499,17 @@ multihop_passthrough_args() {
> {
> sign_key * key = (sign_key*)iter->item;
> const size_t size = len - total;
> -   int written = snprintf(ret+total, size, "-i %s", 
> key->filename);
> +   int w

Dropbear 2013.57 released

[Matt Johnston]

Hi all,

I've put up Dropbear 2013.57 as usual at
https://matt.ucc.asn.au/dropbear/dropbear.html

As well as a few bug fixes it has significant improvements
to the number of round trips required to set up a connection
- useful for high latency links.

Cheers,
Matt

2013.57 - Monday 15 April 2013

- Decreased connection setup time particularly with high latency connections,
  the number of round trips has been reduced for both client and server. 
  CPU time hasn't been changed.

- Client will send an initial key exchange guess to save a round trip.
  Dropbear implements an extension kexgue...@matt.ucc.asn.au to allow the first
  packet guess to succeed in wider circumstances than the standard behaviour.
  When communicating with other implementations the standard behaviour is used.

- Client side: when public key or password authentication with
  $DROPBEAR_PASSWORD is used an initial authentication request will
  be sent immediately rather than querying the list of available methods.
  This behaviour is enabled by CLI_IMMEDIATE_AUTH option (on by default),
  please let the Dropbear author know if it causes any interoperability
  problems.

- Implement client escape characters ~. (terminate session) and 
  ~^Z (background session)

- Server will more reliably clean up utmp when connection is closed, reported by
  Mattias Walström

- Don't crash if /dev/urandom isn't writable (RHEL5), thanks to Scott Case

- Add "-y -y" client option to skip host key checking, thanks to Hans Harder

- scp didn't work properly on systems using vfork(), thanks to Frank Van Uffelen

- Added IUTF8 terminal mode support (Linux and Mac OS). Not standardised yet
though probably will be soon

- Some verbose DROPBEAR_TRACE output is now hidden unless $DROPBEAR_TRACE2
  enviroment variable is set

- Fix using asymmetric MAC algorithms (broke in )

- Renamed configure.in to configure.ac to quieten autoconf, from Mike Frysinger

Re: embedded dropbear...

[Matt Johnston]

Hi,

I'm pretty sure there'd be interest in such a port, even if
there are no immediate takers. I guess it depends how much
effort you want to put in - a separate tarball (or hg
branch ease of merging future versions) might be enough for other
people to get going. It doesn't sound like the changes would
be _too_ intrusive, so could probably live in the main tree.
One concern would be avoiding it breaking from other changes
- would it be easy enough to build the embedded variant
targetting a normal Linux-type platform?

A few comments inline below.

>   no fork(), no exec(), no pipes, etc..  This includes no use of
> fprintf(...) as well.

Missing fprintf() might make the code a bit messier - did
you encounter other uses than for logging/error messages?

> - I loosely base this on the "no-inetd" option; and I
> heavily chopped away at things in options.h (hopefully
> without breaking anything).
> - Since there is no shell, this simply hooks to an internal command
> line processor.
> - Currently the server is built to run as if the following command
> line were invoked:
>   ./dropbear -s -F -b "yada yada" -r dropbear_rsa_host_key
>   and since I do have an FS, I created the dropbear_rsa_host_key
> file using dropbearkey on my host machine, and simply
> copied it to my embedded system's FS for now.  The need
> for the FS could easily be eliminated.

A good source of random values is pretty important for
SSH security. If there are say 16 bytes of good random
values written at "manufacturing", that could be read in as
input then saved out at Dropbear startup and occassionally
during operation (reusing the same seed twice would be very
bad). The write_urandom() would work for writing a value
back. A flash write per boot isn't great, but hard to see a
better way without random number generation hardware.

> DETAILS:
> My build puts the two math directories into a library, and
> then builds the server using portions of ~25 of the ~65 .c
> files that are in the main dropbear directory.

Did you have to change much in the libtom libraries? I'm
planning to merge in tomsfastmath support (using the ltc_mp
descriptor to keep libtommath working as a fallback), that
might help performance as well by reducing malloc()s.

> I simulate interaction with a shell by intercepting incoming
> characters in common_recv_msg_channel_data().  Each line
> of text is simply passed to a command line parser.  While
> that command line is being processed, all output from that
> embedded command is sent through the function
> ssh_putchar():
> 
> static void
> ssh_putcharc(struct Channel *channel,char c)
> {
> CHECKCLEARTOWRITE();
> buf_putbyte(ses.writepayload, SSH_MSG_CHANNEL_DATA);
> buf_putint(ses.writepayload, channel->remotechan);
> buf_putint(ses.writepayload, 1);
> buf_putbyte(ses.writepayload, c);
> encrypt_packet();
> }

You may as well write out at least 12 bytes at once (I
think), since encrypt_packet pads out to MIN_PACKET_LEN (=16) 
with at least 4 bytes of padding.

> and one other important thing...
> At the bottom of encrypt_packet(), I call write_packet() so that the data
> is immediately pushed out the socket.

That sounds fine.

> SUMMARY:
> Thats about it in the nutshell.  The two big gotchas with this were
> issues that
> would not necessarily be important in a process-based environment:
> 
> 1. The use of dropbear_exit() for errors requires the use of
> setjmp/longjmp because
>its in a thread that needs to cleanup properly.
> 2. The heap is clean when exits are clean; but things get messy in a lot of
>exception cases; hence, the need for a dropbear-specific heap which
>allows me to force a clean heap when the session ends (simulating
> the cleanup that
>is automatically done when the process exits).

It'd need a close look over releasing any resources other
than memory allocations, though there probably aren't many
things. libtom* might make use of some static variables.
Dropbear has a small number that can be fixed.

Cheers,
Matt

Re: Compile errors on 2013.57

[Matt Johnston]

Sorry about that. The patch is correct, I'll put up a new
release in a couple of days (wait to see if there are any
more glaring bugs).

Cheers,
Matt

On Tue, Apr 16, 2013 at 11:13:48PM +0200, Hans Harder wrote:
> I get compile errors with the new version, because I compile this in a
> uclib environment without zlib.
> I use ./configure --disable-zlib
> 
> In common-kex.c I run into compile errors.
> 
> common-kex.o(.text+0x203): In function `switch_keys':
> : undefined reference to `gen_new_zstream_recv'
> common-kex.o(.text+0x257): In function `switch_keys':
> : undefined reference to `gen_new_zstream_trans'
> collect2: ld returned 1 exit status
> make: *** [dropbear] Error 1
> 
> Probably this will solve it.
> 
> --- common-kex.c2013-04-16 14:44:42.0 -0600
> +++ common-kex.c2013-04-16 15:08:54.0 -0600
> @@ -171,14 +171,18 @@ static void switch_keys() {
> }
> if (ses.kexstate.recvnewkeys && ses.newkeys->recv.valid) {
> TRACE(("switch_keys recv"))
> +#ifndef DISABLE_ZLIB
> gen_new_zstream_recv();
> +#endif
> ses.keys->recv = ses.newkeys->recv;
> m_burn(&ses.newkeys->recv, sizeof(ses.newkeys->recv));
> ses.newkeys->recv.valid = 0;
> }
> if (ses.kexstate.sentnewkeys && ses.newkeys->trans.valid) {
> TRACE(("switch_keys trans"))
> +#ifndef DISABLE_ZLIB
> gen_new_zstream_trans();
> +#endif
> ses.keys->trans = ses.newkeys->trans;
> m_burn(&ses.newkeys->trans, sizeof(ses.newkeys->trans));
> ses.newkeys->trans.valid = 0;

Re: Patch multihop scp with different ports

[Matt Johnston]

I've applied this with % as the delimiter instead, since #
breaks some shells (eg echo "echo thing#blah" | csh  )

Cheers,
Matt

On Wed, Apr 17, 2013 at 02:23:52PM +0200, Hans Harder wrote:
> I had some problems with the multihop for scp using different portnumbers.
> The original syntax uses / as separator, which conflicts with the
> current code in scp for detecting source and destination
> Ex.  scp file user@host1/,user@host2/22:.
> 
> Simplest way of solvng this was to allow also another char as
> separator for a port, like '#'
> So you can do: scp file user@host1#,user@host2#22:.
> 
> Just a one liner, which allows now to use both chars as a separator
> 
> 
> --- cli-runopts.c  2013-04-15 08:01:57.0 -0600
> +++ cli-runopts.c  2013-04-17 06:14:56.0 -0600
> @@ -611,6 +611,7 @@ static void parse_hostname(const char* o
> }
> 
> port = strchr(cli_opts.remotehost, '/');
> +if (!port)  port = strchr(cli_opts.remotehost, '#');
> if (port) {
> *port = '\0';
> cli_opts.remoteport = port+1;

Dropbear 2013.58 released

[Matt Johnston]

Hi all,

I've put up a new release 2013.58 that fixes building
2013.57 without zlib, and a couple of other things
thanks to Hans Harder.

As usual https://matt.ucc.asn.au/dropbear/dropbear.html

Cheers,
Matt


2013.58 - Thursday 18 April 2013

- Fix building with Zlib disabled, thanks to Hans Harder and cuma@freetz

- Use % as a separator for ports, fixes scp in multihop mode, from Hans Harder

- Reject logins for other users when running as non-root, from Hans Harder

- Disable client immediate authentication request by default, it prevents
  passwordless logins from working

Re: howto: send the X commands to the X server on your host.

[Matt Johnston]

jn Fri, Apr 19, 2013 at 09:20:27AM +0100, Jonathan Chetwynd wrote:
> does dbclient take a command similar to -X in ssh?
> to send the X commands to the X server on your host.
> 
> if not is there a workaround or plans to implement?

Not easily.  If the X server is listening on TCP (port 6000)
you could probably portforward back to that You'd have
to use "xauth" to set up authentication tokens too:

xauth list (gives you a token)
dbclient -R 6000:localhost:6000 remotehost

then on the remotehost:
export DISPLAY=localhost:0.0
xauth add 

or something like that. Proper -X or -Y support could be
added to Dropbear though would probably need something like
the X11 proxy for xauth that OpenSSH has.

Matt

Re: About "DEFAULT_PATH" and "_PATH_SSH_PROGRAM" variables

[Matt Johnston]

The options.h file is intended to be edited for
configuration. I'll add those #ifndefs too though - it
should probably happen for all of the things in options.h

Cheers,
Matt

On Fri, Apr 19, 2013 at 04:24:47PM +0800, Yuan-Yi Chang wrote:
> Hi,
> 
> I'm new to Embedded System World.  There are some problems, "scp not
> found", when I use dropbear-scp to copy some files. I trace the source code
> to find the DEFINE variables: DEFAULT_PATH & _PATH_SSH_PROGRAM.
> 
> Could we redefine it at configure or make process without modify the source
> code?
> 
> like that:
> ===
> +#ifndef _PATH_SSH_PROGRAM
>  #define _PATH_SSH_PROGRAM "/usr/bin/dbclient"
> +#endif
> 
> +#ifndef DEFAULT_PATH
>  #define DEFAULT_PATH "/usr/bin:/bin"
> +#endif
> 
> and then:
> ===
> $ ./configure
> $ CFLAGS=' -D_PATH_SSH_PROGRAM="/path/dbclient"
> -DDDEFAULT_PATH="/usr/bin:/bin:/mnt/ubi_boot/bin"  ' make
> $ CFLAGS=' -D_PATH_SSH_PROGRAM="/path/dbclient"
> -DDDEFAULT_PATH="/usr/bin:/bin:/mnt/ubi_boot/bin"  ' make scp
> 
> 
> Best Regards,
> Yuan-Yi Chang

Re: question

[Matt Johnston]

As long as you respond to a key exchange request from a
client then it should keep working fine. Dropbear does that
(common-kex.c) so unless you've patched it out it should be OK. 
Some clients (PuTTY?) send a rekey request every hour.
Dropbear itself tries to rekey every 8 hours or 1GB data.

Keepalive is usually implemented by sending SSH_MSG_IGNORE,
but there isn't any requirement for that.

It hasn't hit some edge case of the circular buffer in
the channel handling code has it?

Cheers,
Matt

On Thu, Apr 25, 2013 at 04:23:49PM -0400, Ed Sutter wrote:
> Hi,
> I noticed that I'm not doing any re-keying...
> Will this cause a typical SSH client to quit?
> Ed
> >Hi,
> >I have a modified version of the dropbear ssh server running in
> >a multitasking RTOS environment that is not POSIX compliant.
> >In almost all cases it is running perfectly...
> >I run load tests on it by just using a simple expect script
> >that spawns an ssh client and sends commands and expects
> >responses (in a loop).
> >If, within that loop, I occasionally (every ~30 minutes)
> >disconnect and reconnect then I can let that run *forever*
> >(haven't fully tested that).  :-(
> >
> >The problem I run into is if I just make an initial connection
> >and put the script in a loop that simply keeps issuing commands
> >and responses (I never disconnect; just maintain the initial session).
> >After some unpredictable amount of time (usually it takes an hour or
> >more); having invoked a few thousand commands, suddenly everything
> >just stops.  The server is sitting in the select of the session_loop,
> >and the client (in the expect script) is just waiting for a response.
> >
> >It seems like everything is where its supposed to be, but the client
> >is not able to send any characters to the server.  It appears that the
> >connection dropped; however, I'm fairly certain that it has not.
> >
> >So, I apparently broke something; hence my question...
> >
> >After the client/server transactions for key exchange,
> >login/password etc..
> >are complete and basically both sides are just passing encrypted
> >data back
> >and forth, is there any other periodic responsibility (on the
> >servers' part)
> >to issue any "keep-alive" type of commands (or something similar) that I
> >have not implemented?
> >
> >Thanks,
> >Ed
> 

Re: question

[Matt Johnston]

Ah that explains it, it did sound like a problem in the
channel layer.

Cheers,
Matt

On Tue, Apr 30, 2013 at 10:41:24AM -0400, Ed Sutter wrote:
> Matt,
> Well, I think I finally found the problem.  At least my testing (so
> far) says its fixed...
> I see there is a "windowing" type of flow control between client and server.
> This is where my error was.  Since, I don't use channelio(), I had
> to rewrite a lot of
> the mechanisms that in a normal use of dropbear would "just work".
> Anyway, I was decrementing the recvwindow value, but I was not doing
> anything
> with it.  I noticed in channelio() that when recvwindow gets to a
> certain level it
> sends a message to the client telling it to increase the window
> size.  Since I wasn't
> doing that, the client was essentially switched off waiting for the
> window resize
> message to come in...
> I now detect the recvwindow size getting low and call
> send_msg_channel_window_adjust()
> to inform the client that the windowsize should be bumped up.
> With that fixed, things are now running smoothly.
> Does that make sense?
> Ed
> >As long as you respond to a key exchange request from a
> >client then it should keep working fine. Dropbear does that
> >(common-kex.c) so unless you've patched it out it should be OK.
> >Some clients (PuTTY?) send a rekey request every hour.
> >Dropbear itself tries to rekey every 8 hours or 1GB data.
> >
> >Keepalive is usually implemented by sending SSH_MSG_IGNORE,
> >but there isn't any requirement for that.
> >
> >It hasn't hit some edge case of the circular buffer in
> >the channel handling code has it?
> >
> >Cheers,
> >Matt
> >
> >On Thu, Apr 25, 2013 at 04:23:49PM -0400, Ed Sutter wrote:
> >>Hi,
> >>I noticed that I'm not doing any re-keying...
> >>Will this cause a typical SSH client to quit?
> >>Ed
> >>>Hi,
> >>>I have a modified version of the dropbear ssh server running in
> >>>a multitasking RTOS environment that is not POSIX compliant.
> >>>In almost all cases it is running perfectly...
> >>>I run load tests on it by just using a simple expect script
> >>>that spawns an ssh client and sends commands and expects
> >>>responses (in a loop).
> >>>If, within that loop, I occasionally (every ~30 minutes)
> >>>disconnect and reconnect then I can let that run *forever*
> >>>(haven't fully tested that).  :-(
> >>>
> >>>The problem I run into is if I just make an initial connection
> >>>and put the script in a loop that simply keeps issuing commands
> >>>and responses (I never disconnect; just maintain the initial session).
> >>>After some unpredictable amount of time (usually it takes an hour or
> >>>more); having invoked a few thousand commands, suddenly everything
> >>>just stops.  The server is sitting in the select of the session_loop,
> >>>and the client (in the expect script) is just waiting for a response.
> >>>
> >>>It seems like everything is where its supposed to be, but the client
> >>>is not able to send any characters to the server.  It appears that the
> >>>connection dropped; however, I'm fairly certain that it has not.
> >>>
> >>>So, I apparently broke something; hence my question...
> >>>
> >>>After the client/server transactions for key exchange,
> >>>login/password etc..
> >>>are complete and basically both sides are just passing encrypted
> >>>data back
> >>>and forth, is there any other periodic responsibility (on the
> >>>servers' part)
> >>>to issue any "keep-alive" type of commands (or something similar) that I
> >>>have not implemented?
> >>>
> >>>Thanks,
> >>>Ed
> 

Re: Add support for aarch64

[Matt Johnston]

On Mon, May 13, 2013 at 05:27:49PM +0800, Christopher Meng wrote:
> Hi,
> 
> As dropbear doesn't support AArch64, I hope the author can do something in
> order to fix it. In fact I'm the packager of dropbear, some users asked us
> why not support aarch64.

I've pulled in the latest config.guess and config.sub, the
latest release 2013.57 should already be made with autoconf
2.69. Thanks for letting me know, I'd forgotten about the
config.* files.

Cheers,
Matt

Re: A solution for PAM with nonexistent user

[Matt Johnston]

Hi,

It looks like a useful patch for some customised
applications, though I'm not sure that it's worth including
in the general program. 

Cheers,
Matt

On Fri, May 03, 2013 at 02:44:21PM +0800, Yuan-Yi Chang wrote:
> Hi,
> 
> After configured with --enable-pam and modified the option.h:
> 
> //#define ENABLE_SVR_PASSWORD_AUTH
> #define ENABLE_SVR_PAM_AUTH
> 
> The Dropbear would be with the PAM functionality.
> 
> When I used the PAM module to pass the account login flow, but I got the
> message: "Login attempt for nonexistent user". I know there should be a
> white list for most popular applications, I still think there is another
> way for convenience usage on Dropbear.
> 
> There is a patch for choose a system account for nonexistent user at PAM
> mode (The coding style of this patch may not good enough):
> https://github.com/changyy/dropbear-cmake/blob/master/dropbear-2013.58-pam-nonexistent-user-handle.patch
> 
> $ /path/dropbear -h
> ...
> -c username choose a system account for nonexistent user at PAM mode
> ...
> 
> $ cat /etc/pam.d/sshd
> auth required /path/pam_myway.so
> account required /path/pam_myway.so
> $ /path/dropbear -p 222 -r /path/testkey -c root -E -F
> 
> If login account is nonexistent user, it would choose "root" account to use.
> 
> Best Regards,
> Yuan-Yi Chang

Re: segfault in svr-authpasswd.c

[Matt Johnston]

Hi,

Thanks for that, I've committed the fix.

Cheers,
Matt

On Mon, Apr 29, 2013 at 08:20:32AM -0600, Kevin Johnson wrote:
> For users with locked accounts, dropbear segfaults on password
> authentication. The call to crypt() with glibc 2.17 returns NULL if
> the passwd field is '!'. Strcmp() segfaults on the NULL value. Here's
> a patch against 2013.58 that adds a check.
> 
> --- svr-authpasswd.c.old
> +++ svr-authpasswd.c
> @@ -66,6 +66,12 @@
>  m_burn(password, passwordlen);
>  m_free(password);
> 
> +if (testcrypt == NULL) {
> +dropbear_log(LOG_WARNING, "Crypt against user '%s' password
> failed, rejected",
> +ses.authstate.pw_name);
> +send_msg_userauth_failure(0, 1);
> +return;
> +}
>  /* check for empty password */
>  if (passwdcrypt[0] == '\0') {
>  dropbear_log(LOG_WARNING, "User '%s' has blank password, rejected",
> 
> 
> --
> thx,
> Kevin Johnson

Re: [PATCH] Notify clients of PAM error messages

[Matt Johnston]

Hi,

Thanks for the patch. It looks useful, though I plan to
update Dropbear to full PAM handling (with
keyboard-interactive mode) soon, which should handle this
case as well. If I don't get that done I'll put the patch in
the next release.

My one concern is how clients might deal with multiple
banner messages - have you tried with many clients?

Cheers,
Matt

On Thu, May 02, 2013 at 11:44:10AM +0100, Martin Donnelly wrote:
> This patch adds support for relaying PAM_ERROR_MSG to clients. This
> is useful when PAM_ERROR_MSG returns meaningful information, an
> example of this is when pam_nologin is being used and '/etc/nologin'
> contains a message for clients attempting to connect.
> 
> -Martin

> diff -ubNr dropbear-2013.58.orig/auth.h dropbear-2013.58/auth.h
> --- dropbear-2013.58.orig/auth.h  2013-04-18 15:58:14.0 +0100
> +++ dropbear-2013.58/auth.h   2013-04-30 17:37:33.317480220 +0100
> @@ -36,6 +36,7 @@
>  void recv_msg_userauth_request();
>  void send_msg_userauth_failure(int partial, int incrfail);
>  void send_msg_userauth_success();
> +void send_msg_userauth_banner(buffer **msg);
>  void svr_auth_password();
>  void svr_auth_pubkey();
>  void svr_auth_pam();
> diff -ubNr dropbear-2013.58.orig/common-session.c 
> dropbear-2013.58/common-session.c
> --- dropbear-2013.58.orig/common-session.c2013-04-18 15:58:14.0 
> +0100
> +++ dropbear-2013.58/common-session.c 2013-05-01 15:55:20.687368142 +0100
> @@ -122,6 +122,8 @@
>  
>   ses.allowprivport = 0;
>  
> + ses.pam_err = NULL;
> +
>   TRACE(("leave session_init"))
>  }
>  
> diff -ubNr dropbear-2013.58.orig/session.h dropbear-2013.58/session.h
> --- dropbear-2013.58.orig/session.h   2013-04-18 15:58:14.0 +0100
> +++ dropbear-2013.58/session.h2013-05-02 11:32:32.610072021 +0100
> @@ -197,6 +197,8 @@
>* really belong here, but nowhere else fits nicely */
>   int allowprivport;
>  
> + /* buffer for storing PAM error messages */
> + buffer * pam_err;
>  };
>  
>  struct serversession {
> diff -ubNr dropbear-2013.58.orig/svr-auth.c dropbear-2013.58/svr-auth.c
> --- dropbear-2013.58.orig/svr-auth.c  2013-04-18 15:58:14.0 +0100
> +++ dropbear-2013.58/svr-auth.c   2013-05-01 17:36:28.249791834 +0100
> @@ -37,7 +37,6 @@
>  
>  static void authclear();
>  static int checkusername(unsigned char *username, unsigned int userlen);
> -static void send_msg_userauth_banner();
>  
>  /* initialise the first time for a session, resetting all parameters */
>  void svr_authinitialise() {
> @@ -82,10 +81,10 @@
>  
>  /* Send a banner message if specified to the client. The client might
>   * ignore this, but possibly serves as a legal "no trespassing" sign */
> -static void send_msg_userauth_banner() {
> +void send_msg_userauth_banner(buffer **banner) {
>  
>   TRACE(("enter send_msg_userauth_banner"))
> - if (svr_opts.banner == NULL) {
> + if ((banner == NULL) || (*banner == NULL)) {
>   TRACE(("leave send_msg_userauth_banner: banner is NULL"))
>   return;
>   }
> @@ -93,13 +92,13 @@
>   CHECKCLEARTOWRITE();
>  
>   buf_putbyte(ses.writepayload, SSH_MSG_USERAUTH_BANNER);
> - buf_putstring(ses.writepayload, buf_getptr(svr_opts.banner,
> - svr_opts.banner->len), svr_opts.banner->len);
> + buf_putstring(ses.writepayload, buf_getptr(*banner,
> + (*banner)->len), (*banner)->len);
>   buf_putstring(ses.writepayload, "en", 2);
>  
>   encrypt_packet();
> - buf_free(svr_opts.banner);
> - svr_opts.banner = NULL;
> + buf_free(*banner);
> + *banner = NULL;
>  
>   TRACE(("leave send_msg_userauth_banner"))
>  }
> @@ -121,7 +120,7 @@
>  
>   /* send the banner if it exists, it will only exist once */
>   if (svr_opts.banner) {
> - send_msg_userauth_banner();
> + send_msg_userauth_banner(&svr_opts.banner);
>   }
>  
>   
> diff -ubNr dropbear-2013.58.orig/svr-authpam.c dropbear-2013.58/svr-authpam.c
> --- dropbear-2013.58.orig/svr-authpam.c   2013-04-18 15:58:14.0 
> +0100
> +++ dropbear-2013.58/svr-authpam.c2013-05-01 15:18:38.603729862 +0100
> @@ -142,6 +142,22 @@
>   (*respp) = resp;
>   break;
>  
> + case PAM_ERROR_MSG:
> +
> + if (msg_len > 0) {
> + ses.pam_err  = buf_new(msg_len + 4);
> + buf_setpos(ses.pam_err, 0);
> + buf_putbytes(ses.pam_err, "\r\n", 2);
> + buf_putbytes(ses.pam_err, (*msg)->msg, msg_len);
> + buf_putbytes(ses.pam_err, "\r\n", 2);
> + buf_setpos(ses.pam_err, 0);
> +
> + send_msg_userauth_banner(&ses.pam_err);
> + }
> +
> + rc = PAM_AUTH_ERR;
> + break;
> +
>  

Re: Google Authenticator

[Matt Johnston]

Hi,

Even if it's built with PAM I'm not sure it'll work. Dropbear's PAM handling is 
fairly rudimentary, it can only handle conversations that just ask for 
username, password. 

Adding more sophisticated handling probably requires recursively running the 
Dropbear session main loop from within the PAM conversation function callback.

Cheers,
Matt

Alex  wrote:
>Hi,
>
>I've a raspberry pi with dropbear ssh installed, I would to use google
>authenticator to log in in my ssh session. I've installed the PAM
>support with:
>
>apt-get install libpam-google-authenticator
>
>and I already generated the code, but now how can I configure dropbear
>to
>use the PAM module?
>
>Thank you.

Re: slow logins -- some data for comparison

[Matt Johnston]

Hi,

I think the solution is to use tomsfastmath instead. There was a patched 
version posted a while ago on this list. Eventually I'd like to have Dropbear 
able to build against either tomsfastmath (for speed) or libtommath (for 
portability) using the ltc_mp mechanism in libtomcrypt.

There's also ECC support nearly complete in the 'ecc' mercurial branch. That's 
a few times faster than normal kexdh. It adds around 30kB to binary size on 
x86. That should make it into the next Dropbear release, though only will help 
for recent OpenSSH peers.

Matt

William Welch  wrote:
>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

Re: slow logins -- some data for comparison

[Matt Johnston]

I'd start from 2013.58. It's mostly a case of search/replace
of function calls, though mp_init is a bit different I
think (it allocates whereas the straight libtommath version
doesn't?). Take a look at
https://secure.ucc.asn.au/hg/dropbear/file/75509065db53/ecdsa.c#l169
- the ltc_mp variable is set up at
https://secure.ucc.asn.au/hg/dropbear/file/75509065db53/crypto_desc.c#l71
so it could be set to tfm_desc instead.

Tomsfastmath 0.12 would be best from libtom.org

Cheers,
Matt



On Sat, May 25, 2013 at 10:01:16AM -0500, William Welch wrote:
> Thank you for your reply.
> 
> If I were to attempt to add support for tomsfastmath, using ltc_mp as you
> described, which version of dropbear should I start from?  And where should
> I obtain the tomsfastmath library?
> 
> Thank you,
> 
> William
> 
> 
> 
> On Sat, May 25, 2013 at 3:41 AM, Matt Johnston  wrote:
> 
> > Hi,
> >
> > I think the solution is to use tomsfastmath instead. There was a patched
> > version posted a while ago on this list. Eventually I'd like to have
> > Dropbear able to build against either tomsfastmath (for speed) or
> > libtommath (for portability) using the ltc_mp mechanism in libtomcrypt.
> >
> > There's also ECC support nearly complete in the 'ecc' mercurial branch.
> > That's a few times faster than normal kexdh. It adds around 30kB to binary
> > size on x86. That should make it into the next Dropbear release, though
> > only will help for recent OpenSSH peers.
> >
> > Matt
> >
> >
> > William Welch  wrote:
> >>
> >> 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
> >>
> >>

Re: slow logins -- some data for comparison

[Matt Johnston]

Hi William,

That's puzzling. I wonder if the hotspot is different on the Microblaze device 
versus what you see with valgrind - googling I came across a setup that sounds 
similar to yours [1], they thought the SDRAM interface was the bottleneck. Do 
you know what kind of memory setup your CPU has? Perhaps OpenSSL is better at 
keeping everything in registers, or something like that. It could be worth 
asking on the libtom google group if anyone has ideas?

[1] bottom of 
https://groups.google.com/forum/#!msg/sci.crypt/3pg1ngSaQpc/Tr-gcbqxfvEJ

I'd be keen to see your modifications to integrate them into the main tree - 
for more "normal" slow CPUs I think tomsfastmath will be worthwhile.

Cheers,
Matt



On Sat 1/6/2013, at 5:15 am, William Welch  wrote:

> Greetings,
> 
> I completed a first cut of the fast math version -- sadly, it did not help 
> much.  I went back to my linux PC and did some testing with 
> valgrind/callgrind -- and, according to callgrind, for both the tommath and 
> the fast math versions, the hot spots are in tight loops inside of 
> fp_montgomery_reduce and fast_mp_montgomery_reduce. The 2nd hot spot is in 
> fast_s_mp_sqr and the similar routine in fast math.
> 
> I am pondering my next step -- I guess I will study those inner loops and see 
> why they are so slow on the microblaze -- but I am a bit confused by the fact 
> that openssh / sshd completes in 5 to 10 seconds on the same system...
> 
> If there is interest in these modifications to dropbox for fast math, let me 
> know and I will send them or put them online.  The changes are pretty clean 
> -- just a couple of things as mentioned previously.
> 
> Suggestions welcome!
> 
> William
> 
> 
> 
> On Sat, May 25, 2013 at 10:19 AM, Matt Johnston  wrote:
> I'd start from 2013.58. It's mostly a case of search/replace
> of function calls, though mp_init is a bit different I
> think (it allocates whereas the straight libtommath version
> doesn't?). Take a look at
> https://secure.ucc.asn.au/hg/dropbear/file/75509065db53/ecdsa.c#l169
> - the ltc_mp variable is set up at
> https://secure.ucc.asn.au/hg/dropbear/file/75509065db53/crypto_desc.c#l71
> so it could be set to tfm_desc instead.
> 
> Tomsfastmath 0.12 would be best from libtom.org
> 
> Cheers,
> Matt
> 
> 
> 
> On Sat, May 25, 2013 at 10:01:16AM -0500, William Welch wrote:
> > Thank you for your reply.
> >
> > If I were to attempt to add support for tomsfastmath, using ltc_mp as you
> > described, which version of dropbear should I start from?  And where should
> > I obtain the tomsfastmath library?
> >
> > Thank you,
> >
> > William
> >
> >
> >
> > On Sat, May 25, 2013 at 3:41 AM, Matt Johnston  wrote:
> >
> > > Hi,
> > >
> > > I think the solution is to use tomsfastmath instead. There was a patched
> > > version posted a while ago on this list. Eventually I'd like to have
> > > Dropbear able to build against either tomsfastmath (for speed) or
> > > libtommath (for portability) using the ltc_mp mechanism in libtomcrypt.
> > >
> > > There's also ECC support nearly complete in the 'ecc' mercurial branch.
> > > That's a few times faster than normal kexdh. It adds around 30kB to binary
> > > size on x86. That should make it into the next Dropbear release, though
> > > only will help for recent OpenSSH peers.
> > >
> > > Matt
> > >
> > >
> > > William Welch  wrote:
> > >>
> > >> 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
> > 

Re: scp to always accept unknown remote hostkey

[Matt Johnston]

The workaround I sometimes use is to have a shell script:

#!/bin/sh
dbclient -y "$@"

Then run "scp -S thescript".

Dropbear could probably do with "-o" option support which
would solve that problem.

Cheers,
Matt

On Wed, Jun 26, 2013 at 02:53:33PM +0800, Valliappan Muthiah wrote:
> 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.

Re: Fixing crash on -J (proxycmd)

[Matt Johnston]

On Tue, Jun 18, 2013 at 11:31:35PM +0200, Lluís Batlle i Rossell wrote:
> > > 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.
> 
> I confirm that the patch avoids the crash on mips.

Thanks for the patch, I've committed that now. Sorry for the
delay in replying.

Cheers,
Matt

https://secure.ucc.asn.au/hg/dropbear/rev/c936abfa9935

Re: documentation installation

[Matt Johnston]

Huh, that is a bit of an oversight. I'll add installing manpages to the "make 
install" target - you can manually copy dropbear.8 to /usr/share/man/man8 etc.

Cheers,
Matt

David Henderson  wrote:
>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

Re: dbclient half-close?

[Matt Johnston]

Hi Catalin,

Thanks for looking at that - the last patch looks sensible, I'll give it a good 
test. There are a lot of subtle scenarios in channel closing (and variations 
between OSes). 

Cheers,
Matt

Catalin Patulea  wrote:
>Hm, that broke channel-close-by-child-exit. One more try, where we
>check for the child exiting and close writefd as a result. If writefd
>is the last remaining open pipe to the child, then we also close the
>channel as a whole.
>
>On Wed, Jul 17, 2013 at 3:25 PM, Catalin Patulea 
>wrote:
>> Attached patch should fix both, and use hard tabs so should apply
>easily.
>>
>> Rather than replacing readfd with writefd, *both* are checked for
>> FD_CLOSED before closing the entire channel. Then each direction can
>> be initially closed independently.
>>
>> On Wed, Jul 17, 2013 at 7:57 PM, Catalin Patulea 
>wrote:
>>> dbclient handling of remote EOF/local not at EOF also appears
>broken:
>>>
>>> openssh:
>>> $ ssh -v root@1.2.3.4 'exec cat >/dev/null 2>/dev/null'
>>> [...]
>>> debug1: Entering interactive session.
>>> debug1: Sending command: exec cat >/dev/null 2>/dev/null
>>> # remote has sent EOF by virtue of &>/dev/null, but local->remote
>>> # direction still active
>>> foo  # local sends
>>> bar
>>> ^D  # local EOF, channel tears down
>>> debug1: client_input_channel_req: channel 1 rtype exit-status reply
>0
>>> debug1: channel 1: free: client-session, nchannels 2
>>> 
>>>
>>> Note 'exec' is required to replace shell and prevent it from holding
>a
>>> ref to the stdout pipe.
>>>
>>> dropbear:
>>> $ ./dbclient -v r...@lun.nanobit.org 'exec cat >/dev/null
>2>/dev/null'
>>> [...]
>>> TRACE  (31787) 1374079900.330457: process_packet: packet type = 96, 
>len 5
>>> TRACE  (31787) 1374079900.330499: enter recv_msg_channel_eof
>>> TRACE  (31787) 1374079900.330513: CLOSE some fd 1
>>> TRACE  (31787) 1374079900.330526: sending close, readfd is closed
>>> # remote EOF should *not* cause entire channel teardown;
>>> # local may still have something to write ("foo bar" from openssh
>>> # example).
>>> TRACE  (31787) 1374079900.330537: enter send_msg_channel_close
>0x1f78660
>>> TRACE  (31787) 1374079900.330549: enter cli_tty_cleanup
>>> TRACE  (31787) 1374079900.330560: leave cli_tty_cleanup: not in raw
>mode
>>> TRACE  (31787) 1374079900.330606: CLOSE some fd 0
>>> TRACE  (31787) 1374079900.330618: CLOSE some fd 2
>>> 
>>>
>>>
>>> On Sat, Jul 13, 2013 at 12:51 PM, Catalin Patulea
> wrote:
 Maybe the check on common-channel.c:338 should be against writefd
 instead of readfd? This would get set by
 close_chan_fd(channel->writefd) once recv_eof happens.

 This patch indeed causes 'foo' to surface after input EOF:

 diff -r 69cb561cc4c4 common-channel.c
 --- a/common-channel.c Sat Jul 13 11:53:24 2013 +0300
 +++ b/common-channel.c Sat Jul 13 12:50:41 2013 +0300
 @@ -335,7 +335,7 @@
   }

   /* And if we can't receive any more data from them either, close
>up */
 - if (channel->readfd == FD_CLOSED
 + if (channel->writefd == FD_CLOSED
   && (ERRFD_IS_WRITE(channel) || channel->errfd == FD_CLOSED)
   && !channel->sent_close
   && close_allowed

 On Sat, Jul 13, 2013 at 12:31 PM, Catalin Patulea
> wrote:
> 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@1.2.3.4 'cat; echo foo'
> ^D
> foo
>
> dbclient:
> $ ./dbclient root@1.2.3.4 'cat; echo foo'
> ^D
> 
>
> 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

Re: dbclient half-close?

[Matt Johnston]

Hi Catalin,

Sorry for taking so long to get back on this. I've committed
it now, slightly changed the check_close case since there's
no point waiting to flush data to an exited child.

Cheers,
Matt


On Sun, Aug 25, 2013 at 03:37:38AM -0400, Catalin Patulea wrote:
> ping?
> 
> On Fri, Jul 26, 2013 at 9:31 PM, Matt Johnston  wrote:
> > Hi Catalin,
> >
> > Thanks for looking at that - the last patch looks sensible, I'll give it a
> > good test. There are a lot of subtle scenarios in channel closing (and
> > variations between OSes).
> >
> > Cheers,
> > Matt
> >
> > Catalin Patulea  wrote:
> >>Hm, that broke channel-close-by-child-exit. One more try, where we
> >>check for the child exiting and close writefd as a result. If writefd
> >>is the last remaining open pipe to the child, then we also close the
> >>channel as a whole.
> >>
> >>On Wed, Jul 17, 2013 at 3:25 PM, Catalin Patulea 
> >>wrote:
> >>> Attached patch should fix both, and use hard tabs so should apply
> >>easily.
> >>>
> >>> Rather than replacing readfd with writefd, *both* are checked for
> >>> FD_CLOSED before closing the entire channel. Then each direction can
> >>> be initially closed independently.
> >>>
> >>> On Wed, Jul 17, 2013 at 7:57 PM, Catalin Patulea 
> >>wrote:
> >>>> dbclient handling of remote EOF/local not at EOF also appears
> >>broken:
> >>>>
> >>>> openssh:
> >>>> $ ssh -v root@1.2.3.4 'exec cat >/dev/null 2>/dev/null'
> >>>> [...]
> >>>> debug1: Entering interactive session.
> >>>> debug1: Sending command: exec cat >/dev/null 2>/dev/null
> >>>> # remote has sent EOF by virtue of &>/dev/null, but local->remote
> >>>> # direction still active
> >>>> foo # local sends
> >>>> bar
> >>>> ^D # local EOF, channel tears down
> >>>> debug1: client_input_channel_req: channel 1 rtype exit-status reply
> >>0
> >>>> debug1: channel 1: free: client-session, nchannels 2
> >>>> 
> >>>>
> >>>> Note 'exec' is required to replace shell and prevent it from holding
> >>a
> >>>> ref to the stdout pipe.
> >>>>
> >>>> dropbear:
> >>>> $ ./dbclient -v r...@lun.nanobit.org 'exec cat >/dev/null
> >>2>/dev/null'
> >>>> [...]
> >>>> TRACE (31787) 1374079900.330457: process_packet: packet type = 96,
> >>len 5
> >>>> TRACE (31787) 1374079900.330499: enter recv_msg_channel_eof
> >>>> TRACE (31787) 1374079900.330513: CLOSE some fd 1
> >>>> TRACE (31787) 1374079900.330526: sending close, readfd is closed
> >>>> # remote EOF should *not* cause entire channel teardown;
> >>>> # local may still have something to write ("foo bar" from openssh
> >>>> # example).
> >>>> TRACE (31787) 1374079900.330537: enter send_msg_channel_close
> >>0x1f78660
> >>>> TRACE (31787) 1374079900.330549: enter cli_tty_cleanup
> >>>> TRACE (31787) 1374079900.330560: leave cli_tty_cleanup: not in raw
> >>mode
> >>>> TRACE (31787) 1374079900.330606: CLOSE some fd 0
> >>>> TRACE (31787) 1374079900.330618: CLOSE some fd 2
> >>>> 
> >>>>
> >>>>
> >>>> On Sat, Jul 13, 2013 at 12:51 PM, Catalin Patulea
> >> wrote:
> >>>>> Maybe the check on common-channel.c:338 should be against writefd
> >>>>> instead of readfd? This would get set by
> >>>>> close_chan_fd(channel->writefd) once recv_eof happens.
> >>>>>
> >>>>> This patch indeed causes 'foo' to surface after input EOF:
> >>>>>
> >>>>> diff -r 69cb561cc4c4 common-channel.c
> >>>>> --- a/common-channel.c Sat Jul 13 11:53:24 2013 +0300
> >>>>> +++ b/common-channel.c Sat Jul 13 12:50:41 2013 +0300
> >>>>> @@ -335,7 +335,7 @@
> >>>>> }
> >>>>>
> >>>>> /* And if we can't receive any more data from them either, close
> >>up */
> >>>>> - if (channel->readfd == FD_CLOSED
> >>>>> + if (channel->writefd == FD_CLOSED
> >>>>> && (ERRFD_IS_WRITE(channel) || channel->errfd == FD_CLOSED

Re: implementing e...@openssh.com

[Matt Johnston]

On Wed, Jul 24, 2013 at 09:21:43PM -0400, Catalin Patulea wrote:
> e...@openssh.com is an extension that allows EPIPE to propagate through
> SSH sessions. For example:
...
> 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
...
> 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 */

On some particular busybox version I found that I had to set
stdin/stdout (perhaps just one of them?) back to
non-blocking before dbclient exited. Otherwise the shell
somehow inherited the non-blocking FDs and either spun or
exited. It was fairly odd and a while ago, I can't remember
the exact details. Possibly that code could be removed now.

I've fixed Dropbear's erroneous sending
send_msg_channel_failure when wantreply was set - it was
just a problem for dbclient, the server was OK I think.

Cheers,
Matt

Dropbear 2013.59

[Matt Johnston]

Hi all,

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

- 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
service.

- Valid users could be identified due to timing variations.

As usual you can download it from
https://matt.ucc.asn.au/dropbear/dropbear.html


Cheers,
Matt

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

- Send a banner message to report PAM error messages intended for the user
  Patch from Martin Donnelly

- Limit the size of decompressed payloads, avoids memory exhaustion denial
  of service 
  Thanks to Logan Lamb for reporting and investigating it

- Avoid disclosing existence of valid users through inconsistent delays
  Thanks to Logan Lamb for reporting

- Update config.guess and config.sub for newer architectures

- Avoid segfault in server for locked accounts

- "make install" now installs manpages
  dropbearkey.8 has been renamed to dropbearkey.1
  manpage added for dropbearconvert

- Get rid of one second delay when running non-interactive commands

Releases are signed by PGP key m...@ucc.asn.au 4C647FBC 
 D11E 5F8D 2C38 523F 57F1  2166 8CF9 F8B0 4C64 7FBC

Re: Dropbear 2013.59

[Matt Johnston]

Hi all,

There are a few problems with the Makefile in 2013.59. 

- @exec_prefix@ wasn't set but configure refers to that in
  when substituting @bindir@ (!). This caused installation
  to go to /bin and /sbin rather than the prefix.
  
- Installation fails if there isn't a manpage for targets
  such as scp and dropbearmulti

I think these should be fixed now, could anyone with
problems grab the Makefile.in below, run configure again,
and check that it fixes things. I'll make a new release in a
few days with this fix - please contact me if there are
other things broken.

https://secure.ucc.asn.au/hg/dropbear/raw-file/93e04b9ff676/Makefile.in

Cheers,
Matt

On Wed, Oct 09, 2013 at 10:48:39AM +0200, Alexander Dahl wrote:
> Hei hei, 
> 
> because of the security fixes I tried upgrading the dropbear package in
> ptxdist and this fails. Let me explain how.
> 
> Am 2013-10-04 16:38, schrieb Matt Johnston:
> > - "make install" now installs manpages
> >   dropbearkey.8 has been renamed to dropbearkey.1
> >   manpage added for dropbearconvert
> 
> ptxdist compiles dropbear with `make all scp` and installs with `make
> install inst_scp`. Usually we use a cross compiler for ARMv5 but I can
> reproduce this behaviour when compiling on Debian Wheezy (amd64), too.
> See:
> 
> The failing stage is the install stage, see the output from my Debian
> machine:
> 
> % LANG=C DESTDIR=~/compiled/dropbear-2013.59 make install inst_scp
> install -d /home/adahl/compiled/dropbear-2013.59/sbin
> install dropbear /home/adahl/compiled/dropbear-2013.59/sbin
> install -d
> /home/adahl/compiled/dropbear-2013.59/usr/local/share/man/man8
> install -m 644 dropbear.8 
> /home/adahl/compiled/dropbear-2013.59/usr/local/share/man/man8/dropbear.8
> install -d /home/adahl/compiled/dropbear-2013.59/bin
> install dbclient /home/adahl/compiled/dropbear-2013.59/bin
> install -d
> /home/adahl/compiled/dropbear-2013.59/usr/local/share/man/man1
> install -m 644 dbclient.1 
> /home/adahl/compiled/dropbear-2013.59/usr/local/share/man/man1/dbclient.1
> install -d /home/adahl/compiled/dropbear-2013.59/bin
> install dropbearkey /home/adahl/compiled/dropbear-2013.59/bin
> install -d
> /home/adahl/compiled/dropbear-2013.59/usr/local/share/man/man1
> install -m 644 dropbearkey.1 
> /home/adahl/compiled/dropbear-2013.59/usr/local/share/man/man1/dropbearkey.1
> install -d /home/adahl/compiled/dropbear-2013.59/bin
> install dropbearconvert /home/adahl/compiled/dropbear-2013.59/bin
> install -d
> /home/adahl/compiled/dropbear-2013.59/usr/local/share/man/man1
> install -m 644 dropbearconvert.1 
> /home/adahl/compiled/dropbear-2013.59/usr/local/share/man/man1/dropbearconvert.1
> install -d /home/adahl/compiled/dropbear-2013.59/bin
> install scp /home/adahl/compiled/dropbear-2013.59/bin
> install -d
> /home/adahl/compiled/dropbear-2013.59/usr/local/share/man/man1
> install -m 644 scp.1 
> /home/adahl/compiled/dropbear-2013.59/usr/local/share/man/man1/scp.1
> install: cannot stat `scp.1': No such file or directory
> make: *** [inst_scp] Error 1
> 
> 2013.58 works so I guess this behaviour was accidently introduced
> between 2013.58 and 2013.59. I'm not familiar with autotools, so could
> you give me a hint how to fix this?
> 
> Greets
> Alex
> 
> -- 
> »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: 02C8 A590 7FE5 CA5F 3601  D1D5 8FBA 7744 CC87 10D0 ***

Re: Dropbear 2013.59

[Matt Johnston]

On Sun, Oct 06, 2013 at 03:49:01PM -0400, Catalin Patulea wrote:
> Are there any mirrors of Dropbear releases? OpenWRT used to use
> http://www.mirrors.wiretapped.net/security/cryptography/apps/ssh/dropbear/
> but it seems that mirror is now defunct.

I've set up a mirror at https://dropbear.nl/mirror/

It's hosted on a Raspberry Pi in the Netherlands by
https://pcextreme.nl with http://raspberrycolocation.com 

Cheers,
Matt

Re: fix bundled libtom configure flag

[Matt Johnston]

On Sat, Oct 12, 2013 at 04:37:15PM -0400, Mike Frysinger wrote:
> the current flag treats --disable-bundled-libtom like enable.  this patch 
> fixes it.

I've committed this modified. If it can't find system libraries
with --disable-bundled-libtom it fails rather than silently
falling back to bundled.

https://secure.ucc.asn.au/hg/dropbear/rev/4cf61252dfc3

Cheers,
Matt

Dropbear 2013.60

[Matt Johnston]

Hi all,

Dropbear 2013.60 is released fixing a few bugs from 2013.59,
mainly related to "make install". Download as usual from
https://matt.ucc.asn.au/dropbear/dropbear.html
or the new mirror
https://dropbear.nl/mirror/

Cheers,
Matt

2013.60 - Wednesday 16 October 2013

- Fix "make install" so that it doesn't always install to /bin and /sbin

- Fix "make install MULTI=1", installing manpages failed

- Fix "make install" when scp is included since it has no manpage

- Make --disable-bundled-libtom work


Releases are signed by PGP key m...@ucc.asn.au 4C647FBC 
   
 D11E 5F8D 2C38 523F 57F1  2166 8CF9 F8B0 4C64 7FBC  

Dropbear test version 2013.61test with ECC

[Matt Johnston]

Hi all,

Dropbear now has support for ECC which is significantly
faster at setting up connections on slow platforms. Since
it's a large patch I'm making a test release first.

I've also added a "-R" mode to automatically generate
hostkeys on first connection - this is recommended on
embedded platforms which may take a while after boot before
a good /dev/urandom seed has been derived.

Download from 
https://matt.ucc.asn.au/dropbear/testing/dropbear-2013.61test.tar.bz2

Cheers,
Matt

2013.61test - Thursday 14 November 2013

- ECC (elliptic curve) support. Supports ECDSA hostkeys (requires new keys to
  be generated) and ECDH for setting up encryption keys (no intervention
  required). This is significantly faster.

- curve25519-sha...@libssh.org support for setting up encryption keys. This is
  another elliptic curve mode with less potential of NSA interference in
  algorithm parameters. curve25519-donna code thanks to Adam Langley

- -R option to automatically generate hostkeys. This is recommended for
  embedded platforms since it allows the system random number device
  /dev/urandom a longer startup time to generate a secure seed before the
  hostkey is required.

- Compile fixes for old vendor compilers like Tru64 from Daniel Richard G.

Re: Dropbear test version 2013.61test with ECC

[Matt Johnston]

NiLuJe  wrote:

>* libtomcrypt has to be built w/ -DLTM_DESC for ECC support (I'm using
>external libtom* libs).

Yes, I guess people can always force bundled libtom*. I think Debian builds 
libtomcrypt with LTM_DESC but doesn't set the macro in tomcrypt_custom, which 
is why I set it separately.
>
>
>* I had to patch the configure script to detect libtommath before
>libtomcrypt so that the LIBS var was built in the right order to please
>recent binutils versions (libtomcrypt depends on libtommath, so
>-ltommath
>has to come *after* -ltomcrypt).

Thanks, I updated the makefile for that but missed configure's tests.

>* Didn't really look further than that, but dropbearconvert dropbear ->
>openssh on a fresh ecdsa key generated by dropbearkey dies with a "***
>glibc
>detected *** dropbearconvert: free(): corrupted unsorted chunks:
>0x000530b0
>***" (take this one with a grain of salt, that's on a Kindle 5 [eglibc
>2.12], so there may be some weirdness involved).


Sounds like a Dropbear bug, I'll investigate. 

Thanks,
Matt 

Re: dropbear: no auth methods could be used

[Matt Johnston]

On Mon, Nov 18, 2013 at 03:41:04PM +, shm wrote:
> I have created passwordless ssh connection between two nodes of an embedded 
> target using dropbear. 
> Dropbear is enabled "dropbear -s -g -E"
...
> "192.168.10.5: Connection exited, no auth methods could be used

This means that the server rejected all the authentication
methods the client tried. Since password authentication is
disabled it means that the public key wasn't accepted (for
that user). The error message could be clearer - I'll
improve that.

The rest of the error message is MPI responding to dropbear
failing, I think?

Cheers,
Matt

> A daemon (pid 1214) died unexpectedly with status 1 while attempting
> to launch so we are aborting.
> 
> This may be because the daemon was unable to find all the needed
> shared libraries on the remote node. You may set your LD_LIBRARY_PATH
> to have the location of the shared libraries on the remote nodes and
> this will automatically be forwarded to the remote nodes."
> 
> I have set LD_LIBRARY_PATH, but still doesn't work.
> The problem occurs when running mpirun.
> passwordless connection using dropbear was succesfull still Why is it showing 
> "no auth methods could be used".?
> Could you please help me? Thanks in advance
> 

Re: TOS byte for bulk transfers

[Matt Johnston]

Catalin Patulea  wrote:

>Matt, would you accept a patch that keys the TOS setting off 
> PTY requests?

Yes, I've been meaning to look at that. 

I'm not sure if it should disable TCP_NODELAY at the same time. I know sshfs 
(which doesn't use a PTY) should have nodelay set.
There are probably other optimisations possible now that Dropbear is using 
writev() anyway - only write out all replies after processing all requests, for 
example.

Cheers,
Matt

Re: Dropbear test version 2013.61test with ECC

[Matt Johnston]

On Thu, Nov 14, 2013 at 05:22:13PM +0100, Daniel Cegiełka wrote:
> Thank you Matt! Thank you Adam! :)
> 
> btw. can we use qhasm version as an option for x86 (curve25519)?

Hi Daniel,

Is x86 performance an issue with the current code? Binary
size might be a reason to use the asm version, though
probably on other CPUs? Generally I'd prefer to keep it
portable and relatively readable.

Cheers,
Matt

Re: [PATCH] Set IPTOS_LOWDELAY on PTY sessions only

[Matt Johnston]

Hi Catalin,

Thank you for the patch, I've committed it. I've made a 
change so that it will start off in lowdelay mode for
a pty client or any server - the initial connection involves
lots of roundtrips, so delays matter there. It's dropping
down to BULK if it ends up having a non-pty shell.

The only remaining question I can see is whether it needs
special handling for the SSH socket in a situation without a
shell, just used for tcp forwarding. Default TOS is probably
better than BULK, but I'll leave it for now.

I disabled the printing errors when setsockopt() failed
since it can validly fail if a ipv4 socket is passed to the
ipv6 call (or I assume vice versa), at least on OS X.

Cheers,
Matt


On Mon, Dec 02, 2013 at 01:54:25AM -0800, Catalin Patulea wrote:
> Signed-off-by: Catalin Patulea 
> ---
>  cli-chansession.c |  1 +
>  dbutil.c  | 29 +
>  dbutil.h  |  2 ++
>  includes.h|  4 
>  svr-chansession.c |  2 ++
>  5 files changed, 30 insertions(+), 8 deletions(-)
> 
> diff --git a/cli-chansession.c b/cli-chansession.c
> index 0ee3e85..b99e073 100644
> --- a/cli-chansession.c
> +++ b/cli-chansession.c
> @@ -369,6 +369,7 @@ static int cli_initchansess(struct Channel *channel) {
>  
>   if (cli_opts.wantpty) {
>   send_chansess_pty_req(channel);
> + set_sock_priority(ses.sock_out);
>   }
>  
>   send_chansess_shell_req(channel);
> diff --git a/dbutil.c b/dbutil.c
> index ce88731..4f15027 100644
> --- a/dbutil.c
> +++ b/dbutil.c
> @@ -177,28 +177,41 @@ void dropbear_trace2(const char* format, ...) {
>  }
>  #endif /* DEBUG_TRACE */
>  
> -static void set_sock_priority(int sock) {
> -
> +void set_sock_nodelay(int sock) {
>   int val;
>  
>   /* disable nagle */
>   val = 1;
>   setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (void*)&val, sizeof(val));
> +}
> +
> +void set_sock_priority(int sock) {
> +
> + int val, rc;
>  
>   /* set the TOS bit for either ipv4 or ipv6 */
>  #ifdef IPTOS_LOWDELAY
>   val = IPTOS_LOWDELAY;
>  #if defined(IPPROTO_IPV6) && defined(IPV6_TCLASS)
> - setsockopt(sock, IPPROTO_IPV6, IPV6_TCLASS, (void*)&val, sizeof(val));
> + rc = setsockopt(sock, IPPROTO_IPV6, IPV6_TCLASS, (void*)&val, 
> sizeof(val));
> + if (rc < 0)
> + dropbear_log(LOG_WARNING, "Couldn't set IPV6_TCLASS (%s)",
> + strerror(errno));
>  #endif
> - setsockopt(sock, IPPROTO_IP, IP_TOS, (void*)&val, sizeof(val));
> + rc = setsockopt(sock, IPPROTO_IP, IP_TOS, (void*)&val, sizeof(val));
> + if (rc < 0)
> + dropbear_log(LOG_WARNING, "Couldn't set IP_TOS (%s)",
> + strerror(errno));
>  #endif
>  
>  #ifdef SO_PRIORITY
>   /* linux specific, sets QoS class.
>* 6 looks to be optimal for interactive traffic (see tc-prio(8) ). */
> - val = 6;
> - setsockopt(sock, SOL_SOCKET, SO_PRIORITY, (void*) &val, sizeof(val));
> + val = TC_PRIO_INTERACTIVE;
> + rc = setsockopt(sock, SOL_SOCKET, SO_PRIORITY, (void*) &val, 
> sizeof(val));
> + if (rc < 0)
> + dropbear_log(LOG_WARNING, "Couldn't set SO_PRIORITY (%s)",
> + strerror(errno));
>  #endif
>  
>  }
> @@ -290,7 +303,7 @@ int dropbear_listen(const char* address, const char* port,
>   }
>  #endif
>  
> - set_sock_priority(sock);
> + set_sock_nodelay(sock);
>  
>   if (bind(sock, res->ai_addr, res->ai_addrlen) < 0) {
>   err = errno;
> @@ -429,7 +442,7 @@ int connect_remote(const char* remotehost, const char* 
> remoteport,
>   TRACE(("Error connecting: %s", strerror(err)))
>   } else {
>   /* Success */
> - set_sock_priority(sock);
> + set_sock_nodelay(sock);
>   }
>  
>   freeaddrinfo(res0);
> diff --git a/dbutil.h b/dbutil.h
> index 7c7435c..7665845 100644
> --- a/dbutil.h
> +++ b/dbutil.h
> @@ -66,6 +66,8 @@ void get_socket_address(int fd, char **local_host, char 
> **local_port,
>   char **remote_host, char **remote_port, int host_lookup);
>  void getaddrstring(struct sockaddr_storage* addr, 
>   char **ret_host, char **ret_port, int host_lookup);
> +void set_sock_nodelay(int sock);
> +void set_sock_priority(int sock);
>  int dropbear_listen(const char* address, const char* port,
>   int *socks, unsigned int sockcount, char **errstring, int 
> *maxfd);
>  int spawn_command(void(*exec_fn)(void *user_data), void *exec_data,
> diff --git a/includes.h b/includes.h
> index 62a8d73..bae82f5 100644
> --- a/includes.h
> +++ b/includes.h
> @@ -156,6 +156,10 @@ typedef unsigned int u_int32_t;
>  typedef u_int32_t uint32_t;
>  #endif /* HAVE_UINT32_T */
>  
> +#ifdef SO_PRIORITY
> +#include 
> +#endif
> +
>  #include "fake-rfc2553.h"
>  
>  #ifndef LOG_AUTHPRIV
> diff --git a/svr-chansession.c b/svr-chansession.c
> index b585a9a..b912eaf 10064

Dropbear 2013.62 released

[Matt Johnston]

Hi,

I've put up Dropbear 2013.62. It has only a few changes
since the 2013.61test release. The major features of 2013.61test 
are ECC support (significantly faster connections) and
generating hostkeys automatically.

Downloads as usual at
https://matt.ucc.asn.au/dropbear/dropbear.html or 
https://dropbear.nl/mirror/dropbear.html

Cheers,
Matt


2013.62 - Tuesday 3 December 2013

- Disable "interactive" QoS connection options when a connection doesn't
  have a PTY (eg scp, rsync). Thanks to Catalin Patulea for the patch.

- Log when a hostkey is generated with -R, fix some bugs in handling server
  hostkey commandline options

- Fix crash in Dropbearconvert and 521 bit key, reported by NiLuJe

- Update config.guess and config.sub again

2013.61test - Thursday 14 November 2013

- ECC (elliptic curve) support. Supports ECDSA hostkeys (requires new keys to
  be generated) and ECDH for setting up encryption keys (no intervention
  required). This is significantly faster.

- curve25519-sha...@libssh.org support for setting up encryption keys. This is
  another elliptic curve mode with less potential of NSA interference in
  algorithm parameters. curve25519-donna code thanks to Adam Langley

- -R option to automatically generate hostkeys. This is recommended for
  embedded platforms since it allows the system random number device
  /dev/urandom a longer startup time to generate a secure seed before the
  hostkey is required.

- Compile fixes for old vendor compilers like Tru64 from Daniel Richard G.

- Make authorized_keys handling more robust, don't exit encountering
  malformed lines. Thanks to Lorin Hochstein and Mark Stillwell 

Re: -Y that proxies over a socket, á la -J 'nc HOST PORT'

[Matt Johnston]

Steffen Daode Nurpmeso  wrote:

>  $ dbclient -Y [HOST:]PORT steffen@crux3
>

Hi,

Thanks for the patch. To clarify, is the reason for using this so that "crux3" 
is used to lookup the known_hosts key?

Cheers,
Matt 

Re: [patch] simplify install links

[Matt Johnston]

On Sun, Dec 08, 2013 at 08:26:43PM -0500, Mike Frysinger wrote:
> there's no need to do `rm; ln` when `ln -f` will do the same thing

It's not always the same, I dislike "ln -f". For example:

ln -s /tmp foo
ln -sf /etc/hosts foo
cat foo

> also, for softlinks in the bindir, just use relative ones rather than absolute

I'm not convinced this is worth doing - the "dropbear"
binary will need an absolute path, so they may as well be
consistent.

I've applied the other patches, thanks!

Cheers,
Matt

> --- a/Makefile.in Tue Dec 03 22:00:38 2013 +0800
> +++ b/Makefile.in Sun Dec 08 20:25:54 2013 -0500
> @@ -126,15 +126,13 @@ install: $(addprefix inst_, $(TARGETS))
>  
>  insmultidropbear: dropbearmulti
>   $(INSTALL) -d $(DESTDIR)$(sbindir)
> - -rm -f $(DESTDIR)$(sbindir)/dropbear$(EXEEXT)
> - -ln -s $(bindir)/dropbearmulti$(EXEEXT) 
> $(DESTDIR)$(sbindir)/dropbear$(EXEEXT) 
> + -ln -sf $(bindir)/dropbearmulti$(EXEEXT) 
> $(DESTDIR)$(sbindir)/dropbear$(EXEEXT)
>   $(INSTALL) -d $(DESTDIR)$(mandir)/man8
>   $(INSTALL) -m 644 dropbear.8  $(DESTDIR)$(mandir)/man8/dropbear.8
>  
>  insmulti%: dropbearmulti
>   $(INSTALL) -d $(DESTDIR)$(bindir)
> - -rm -f $(DESTDIR)$(bindir)/$*$(EXEEXT) 
> - -ln -s $(bindir)/dropbearmulti$(EXEEXT) $(DESTDIR)$(bindir)/$*$(EXEEXT) 
> + -ln -sf dropbearmulti$(EXEEXT) $(DESTDIR)$(bindir)/$*$(EXEEXT)
>   $(INSTALL) -d $(DESTDIR)$(mandir)/man1
>   $(INSTALL) -m 644 $*.1  $(DESTDIR)$(mandir)/man1/$*.1
>  

Re: Bug in rekeying

[Matt Johnston]

Hi,

Thanks for the report. I think this should be fixed in 
https://secure.ucc.asn.au/hg/dropbear/rev/19ce21bd198a

I think there has probably been a timing dependent bug there
for a long time, but it was exposed more easily in 2013.57.

Cheers,
Matt

On Mon, Jan 20, 2014 at 09:53:18PM +0100, Oliver Metz wrote:
> Hi,
> 
> we see a bug when the rekey limit is reached. Dropbear is run on a embedded 
> mips device. For testing purposes we changed the define in sysoptions.h to:
> #define KEX_REKEY_DATA (1<<21)
> 
> This gives the following log:
> ...
> TRACE (5619) 1389521630.365826: send_msg_channel_data: len 16375 fd 0
> TRACE (5619) 1389521630.372597: leave send_msg_channel_data
> TRACE (5619) 1389521630.373003: send normal readfd
> TRACE (5619) 1389521630.373316: enter send_msg_channel_data
> TRACE (5619) 1389521630.373707: enter send_msg_channel_data isextended 0 fd 0
> TRACE (5619) 1389521630.374120: maxlen 16375
> TRACE (5619) 1389521630.374595: send_msg_channel_data: len 16375 fd 0
> TRACE (5619) 1389521630.381393: leave send_msg_channel_data
> TRACE (5619) 1389521630.381798: rekeying after timeout or max data reached
> TRACE (5619) 1389521630.382441: send_msg_kexdh_init()
> TRACE (5619) 1389521630.391507: DATAALLOWED=0
> TRACE (5619) 1389521630.391861: -> KEXINIT
> TRACE (5619) 1389521630.392163: maybe_empty_reply_queue - no data allowed
> TRACE (5619) 1389521630.769376: empty queue dequeing
> TRACE (5619) 1389521630.769747: maybe_empty_reply_queue - no data allowed
> TRACE (5619) 1389521631.234696: process_packet: packet type = 93, len 9
> TRACE (5619) 1389521631.235255: enter session_cleanup
> TRACE (5619) 1389521631.235565: enter cli_tty_cleanup
> TRACE (5619) 1389521631.235865: leave cli_tty_cleanup: not in raw mode
> TRACE (5619) 1389521631.236376: enter chancleanup
> TRACE (5619) 1389521631.236683: channel 0 closing
> TRACE (5619) 1389521631.237056: enter remove_channel
> TRACE (5619) 1389521631.237352: channel index is 0
> TRACE (5619) 1389521631.238302: CLOSE writefd 1
> TRACE (5619) 1389521631.238677: CLOSE readfd 0
> TRACE (5619) 1389521631.239089: CLOSE errfd 2
> rsync: writefd_unbuffered failed to write 4092 bytes to socket [sender]: 
> Broken pipe (32)
> rsync: connection unexpectedly closed (34 bytes received so far) [sender]
> rsync error: error in rsync protocol data stream (code 12) at io.c(605) 
> [sender=3.0.9]
> 
> With the unaltered define this happens after exactly 1GB traffic. I'm sorry 
> that I can't attach a patch. But I can provide more logs if you need them.
> 
> Regards
> Oliver
> 
> http://freetz.org

Re: Elliptic Curve host key and -R argument bug

[Matt Johnston]

Hi,

Could you see if the patch below fixes it? I think the ecdsa hostkeys are
coincidental. 

Cheers,
Matt

https://secure.ucc.asn.au/hg/dropbear/rev/6e6ae84d3dba
--- a/gensignkey.c  Thu Jan 23 22:29:04 2014 +0800
+++ b/gensignkey.c  Tue Jan 28 22:44:24 2014 +0800
@@ -26,7 +26,7 @@
while (buf->pos != buf->len) {
int len = write(fd, buf_getptr(buf, buf->len - buf->pos),
buf->len - buf->pos);
-   if (errno == EINTR) {
+   if (len == -1 && errno == EINTR) {
continue;
}
if (len <= 0) {



On Tue, Jan 28, 2014 at 02:18:44PM +, Bruno Thomsen wrote:
> Hi,
> 
> I have observed some strange dropbear behavior with the -R argument (Create 
> hostkeys as required) and Elliptic Curve host keys.
> The result is an extremely large temporary host key file (multiple megabytes).
> 
> SSH client: Google Chrome extension: Secure Shell 0.8.25
> 
> 1) Connect to dropbear running without arguments and a single host key 
> (ecdsa-sha2-nistp521) in /etc/dropbear/dropbear_ecdsa_host_key
> 2) Stop dropbear
> 3) Remove old host key and generate a single new host key 
> (ecdsa-sha2-nistp256) in /etc/dropbear/dropbear_ecdsa_host_key
> 4) Start dropbear with -R argument
> 5) Reconnect to dropbear and it generate an extremely large host key (process 
> never ends).
> 
> 
> 
> Result:
> root@target:~ ll /etc/dropbear/
> total 54508
> dr2 root root  1024 Jan 28 13:38 .
> drwxrwxr-x   19 root root  1024 Jan 28 12:09 ..
> -r1 root root   140 Jan 28 13:35 
> dropbear_ecdsa_host_key
> -rw---1 root root  55593054 Jan 28 13:39 
> dropbear_ecdsa_host_key.tmp377
> root@target:~ ll /etc/dropbear/
> total 66001
> dr2 root root  1024 Jan 28 13:38 .
> drwxrwxr-x   19 root root  1024 Jan 28 12:09 ..
> -r1 root root   140 Jan 28 13:35 
> dropbear_ecdsa_host_key
> -rw---1 root root  67316589 Jan 28 13:40 
> dropbear_ecdsa_host_key.tmp377
> root@target:~ ll /etc/dropbear/
> total 70657
> dr2 root root  1024 Jan 28 13:38 .
> drwxrwxr-x   19 root root  1024 Jan 28 12:09 ..
> -r1 root root   140 Jan 28 13:35 
> dropbear_ecdsa_host_key
> -rw---1 root root  72064080 Jan 28 13:40 
> dropbear_ecdsa_host_key.tmp377
> root@target:~ ll /etc/dropbear/
> total 84631
> dr2 root root  1024 Jan 28 13:38 .
> drwxrwxr-x   19 root root  1024 Jan 28 12:09 ..
> -r1 root root   140 Jan 28 13:35 
> dropbear_ecdsa_host_key
> -rw---1 root root  86317002 Jan 28 13:40 
> dropbear_ecdsa_host_key.tmp377
> root@target:~ ll /etc/dropbear/
> total 129200
> dr2 root root  1024 Jan 28 13:38 .
> drwxrwxr-x   19 root root  1024 Jan 28 12:09 ..
> -r1 root root   140 Jan 28 13:35 
> dropbear_ecdsa_host_key
> -rw---1 root root 131778657 Jan 28 13:41 
> dropbear_ecdsa_host_key.tmp377
> root@target:~ ll /etc/dropbear/
> total 130372
> dr2 root root  1024 Jan 28 13:38 .
> drwxrwxr-x   19 root root  1024 Jan 28 12:09 ..
> -r1 root root   140 Jan 28 13:35 
> dropbear_ecdsa_host_key
> -rw---1 root root 132973731 Jan 28 13:41 
> dropbear_ecdsa_host_key.tmp377
> root@target:~ ll /etc/dropbear/
> total 131219
> dr2 root root  1024 Jan 28 13:38 .
> drwxrwxr-x   19 root root  1024 Jan 28 12:09 ..
> -r1 root root   140 Jan 28 13:35 
> dropbear_ecdsa_host_key
> -rw---1 root root 133837839 Jan 28 13:41 
> dropbear_ecdsa_host_key.tmp377
> root@target:~ top
> Mem: 121580K used, 3376K free, 0K shrd, 10172K buff, 91900K cached
> CPU: 20.0% usr 80.0% sys  0.0% nic  0.0% idle  0.0% io  0.0% irq  0.0% sirq
> Load average: 2.30 1.04 0.52 2/55 1416
>   PID  PPID USER STAT   VSZ %MEM CPU %CPU COMMAND
>   377 31162 root R 2292  1.8   0 66.5 dropbear -R
> 
> 
> 
> Maybe it's a collision in /etc/dropbear/dropbear_ecdsa_host_key that holds an 
> ecdsa-sha2-nistp256 and when dropbear tries to generate a new 
> ecdsa-sha2-nistp521.
> 
> 
> Venlig hilsen / Best regards
> 
> Kamstrup A/S  
> Bruno Thomsen
> Development engineer
> Technology
> 
> Kamstrup A/S
> Industrivej 28
> DK-8660 Skanderborg
> Tel:   +45 89 93 10 00 
> Fax:   +45 89 93 10 01 
> Dir:   +45 89 93 13 94 
> E-mail:b...@kamstrup.dk
> Web:   www.kamstrup.dk 
> 

Re: [REGRESSION] ssh link-local addresses fails with "Servname not supported for ai_socktype"

[Matt Johnston]

Hi,

That's a bit unfortunate. Cursed ipv6 syntax, always causing
problems!

If noone has any objections I'll change the separator to ^.
There aren't any common keyboard layouts missing that symbol?

Cheers,
Matt

On Tue, Jan 28, 2014 at 10:13:10AM -0300, Gui Iribarren wrote:
> Hello,
> I bumped into an... interesting... regression introduced by
> 
> http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2013q2/001390.html
> 
> which breaks the possibility to connect to ipv6 link-local
> addresses, since '%' is actually the separator for the interface
> identifier.
> 
> symptom is:
> # ssh fe80::f8d1:11ff:fea0:fc%wlan0
> ssh: Exited: Error resolving 'fe80::f8d1:11ff:fea0:fc' port 'wlan0'.
> Servname not supported for ai_socktype
> 
> and jow
> https://lists.openwrt.org/pipermail/openwrt-devel/2014-January/023526.html
> kindly pointed me to this mailing list.
> 
> given it was introduced by a one-liner, maybe another one-liner
> could fix it?
> 
> Signed-off-by: Gui Iribarren 
> 
> ---
> 
> diff --git a/cli-runopts.c b/cli-runopts.c
> index 8ffd997..acf738e 100644
> --- a/cli-runopts.c
> +++ b/cli-runopts.c
> @@ -620,7 +620,7 @@ static void parse_hostname(const char* orighostarg) {
> cli_opts.username = m_strdup(cli_opts.own_user);
> }
> 
> -   port = strchr(cli_opts.remotehost, '%');
> +   port = strchr(cli_opts.remotehost, '^');
> if (!port)  {
> // legacy separator
> port = strchr(cli_opts.remotehost, '/');

Re: Interactive QoS with `scp'

[Matt Johnston]

Hi,

> # ssh with command (implies no-pty) --> uses IPTOS_THROUGHPUT == OK!
> ssh 14.64.1.4 "date"
> tos 0x8
> 
> # scp --> Still uses IPTOS_LOWDELAY! i.e. NOT OK(?)
> scp /tmp/file.dat 14.64.1.4:/tmp/
> tos 0x10

That's strange. scp should just be calling "dbclient localhost scp -t 
destination" - the same as the "date" case. Could you run

strace -f -F -e process scp /tmp/file.dat 14.64.1.4:/tmp/

and check what it's doing?

> [The TOS of the initial packets during connection establishment was 0 and 
> then changed to the mentioned values, which is OK and expected]

Yep, that's intentional to avoid initial roundtrip latency.

> One more thing:
> Using TOS is actually obsoleted. "Modern" implementations should use the DS 
> Field and DSCP classes as described in RFC2474/RFC3260.
> But as long as interactive and non-interactive connections can be identified 
> and separated in the network, I'm fine with that...

Yeah, I couldn't see any benefit though. It's just an extra
configuration option with no sensible default value? (Assume
rfc2597 is the most relevant one).

Cheers,
Matt

Re: Server process not closed after disconnect, problems with reconnect

[Matt Johnston]

Hi,

Running with -K 30 for keepalive might sort it out?

Cheers,
Matt

On 3 February 2014 4:25:49 pm AWST, Alexander Kriegisch 
 wrote:
>My setup:
>  - Server (DSL/WLAN router running Dropbear sshd v2012.55)
>
>  $ uname -mrsp
>  Linux 2.6.19.2 mips unknown
>
>  $ ps | grep dropbear | grep -v grep
>   1673 root  1352 Sdropbear -i -R -a
>  14826 root  1396 Sdropbear -i -R -a
>
>  - Client
>
>  OS: Windows XP Pro 64-bit
>  SSH Client: Bitvise
>
>As you can see, my Dropbear runs as root in inetd mode, permitting root
>logins (which is what I use) and accepting connections to forwarded
>ports from other hosts. I need this because my connection basically
>creates a few forward tunnels (client to server) to other machines
>behind the router as well as backward tunnels (server to client) to a
>few services on the client's network. So far, so good.
>
>The DSL router gets disconnected once every night, reconnects within
>seconds and gets a new IP address, which is the usual thing in Germany
>for consumer-type ISP connections. What I expect to happen is that the
>dropbear process goes down, but in ca. 4 out of 7 days this does not
>happen. The main symptom is that the auto-reconnect for the SSH
>connection to the dynamic host name fails because ports on the router
>cannot be bound because they are already in use. When I check with
>netstat I can see that indeed all the listening ports for the reverse
>tunnels are still in use by the old Dropbear process which has not
>terminated. On a few days a week it works, but I do not know the
>circumstances or race conditions which cause this behaviour. So what I
>end up doing most of the time is log on to the router without the
>tunnels and kill the non-terminated Dropbear process blocking the
>listening ports. A few seconds later, the full-blown SSH connection
>with forward and reverse tunnels automatical
> ly reconnects and everything is fine for another 24 hours.
>
>Now this obviously is ugly and unstable. Is there a way to make
>Dropbear understand it should terminate when the DSL connection is
>gone? Or is there at least a workaround by which I can check if the SSH
>process ist still alive? I thought that maybe I could try and connect
>to one of the stale reverse tunnels (localhost:someport on the router)
>in order to see if it is still functional, then kill the process
>otherwise, but I had difficulty doing so because a wget test does not
>work (I only have Busybox wget which does not have a time-out
>parameter).
>
>Please ask for more information if this was too unspecific.
>-- 
>Alexander Kriegisch
>http://scrum-master.de

Re: Server process not closed after disconnect, problems with reconnect

[Matt Johnston]

Hi,

The keepalive option makes sure that traffic is transmitted every N seconds. It 
can be used to avoid routers closing idle (keeping them "alive").

If the connection is gone then the connection will be terminated after a 
timeout (a minute perhaps?) when the traffic is transmitted. A program doesn't 
get notified when a network interface goes down (at least with standard Unix 
programming interfaces), so it only finds out when traffic is sent.

An alternative might be to "killall dropbear", "/etc/init.d/dropbear start" in 
/etc/ppp/ip-down.d or similar, since that part knows that the interface has 
gone away.

Cheers,
Matt

On 3 February 2014 8:34:15 pm AWST, Alexander Kriegisch 
 wrote:
>Hi Matt.
>
>Thanks for your swift reply. Could you please elaborate on what "-K" is
>actually meant to do (what is kept alive and how?) and how it might
>help me solve my problem? Documentation on Dropbear is sparse and I
>fail to see the connection.
>
>Kind regards
>-- 
>Alexander Kriegisch
>http://scrum-master.de
>
>
>Matt Johnston schrieb am 03.02.2014 13:02:
>
>> Running with -K 30 for keepalive might sort it out?
>> 
>> 
>> On 3 February 2014 4:25:49 pm AWST, Alexander Kriegisch
>>  wrote:
>>>My setup:
>>>  - Server (DSL/WLAN router running Dropbear sshd v2012.55)
>>>
>>>  $ uname -mrsp
>>>  Linux 2.6.19.2 mips unknown
>>>
>>>  $ ps | grep dropbear | grep -v grep
>>>   1673 root  1352 Sdropbear -i -R -a
>>>  14826 root  1396 Sdropbear -i -R -a
>>>
>>>  - Client
>>>
>>>  OS: Windows XP Pro 64-bit
>>>  SSH Client: Bitvise
>>>
>>>As you can see, my Dropbear runs as root in inetd mode, permitting
>root
>>>logins (which is what I use) and accepting connections to forwarded
>>>ports from other hosts. I need this because my connection basically
>>>creates a few forward tunnels (client to server) to other machines
>>>behind the router as well as backward tunnels (server to client) to a
>>>few services on the client's network. So far, so good.
>>>
>>>The DSL router gets disconnected once every night, reconnects within
>>>seconds and gets a new IP address, which is the usual thing in
>Germany
>>>for consumer-type ISP connections. What I expect to happen is that
>the
>>>dropbear process goes down, but in ca. 4 out of 7 days this does not
>>>happen. The main symptom is that the auto-reconnect for the SSH
>>>connection to the dynamic host name fails because ports on the router
>>>cannot be bound because they are already in use. When I check with
>>>netstat I can see that indeed all the listening ports for the reverse
>>>tunnels are still in use by the old Dropbear process which has not
>>>terminated. On a few days a week it works, but I do not know the
>>>circumstances or race conditions which cause this behaviour. So what
>I
>>>end up doing most of the time is log on to the router without the
>>>tunnels and kill the non-terminated Dropbear process blocking the
>>>listening ports. A few seconds later, the full-blown SSH connection
>>>with forward and reverse tunnels automatical
>>> ly reconnects and everything is fine for another 24 hours.
>>>
>>>Now this obviously is ugly and unstable. Is there a way to make
>>>Dropbear understand it should terminate when the DSL connection is
>>>gone? Or is there at least a workaround by which I can check if the
>SSH
>>>process ist still alive? I thought that maybe I could try and connect
>>>to one of the stale reverse tunnels (localhost:someport on the
>router)
>>>in order to see if it is still functional, then kill the process
>>>otherwise, but I had difficulty doing so because a wget test does not
>>>work (I only have Busybox wget which does not have a time-out
>>>parameter).
>>>
>>>Please ask for more information if this was too unspecific.

Re: 2013.62 broken, 2013.60 ok

[Matt Johnston]

On Sat, Feb 15, 2014 at 03:34:28PM -0600, Steve Dover wrote:
> compile failure of dbutil.c, various typedefs missing.
> 
> unknown type name '___u64' (and 32,16,8)
> 
> I've diffed the entire tree, and can find no obvious changes
> between 60 and 62 that lead to this breakage.  This is basic
> ...
> But, in both environments, 2013.60 builds fine.

Hi,

There were a few changes in includes.h to do with types,
I can't see why it would break things though.

Could you try adding

#ifdef HAVE_STDINT_H
#include 
#endif

to includes.h before the bit for utmp.h?

Cheers,
Matt

Re: 2013.62 broken, 2013.60 ok - PATCH

[Matt Johnston]

Hi Steve,

Thanks for tracking that down, I've committed it as
https://secure.ucc.asn.au/hg/dropbear/rev/5d3e917bb7a6

I guess it's some unique combination of toolchain, library,
or Linux brokenness! Alternatively maybe Dropbear should
have been including linux/types.h all along.

Cheers,
Matt

On Sun, Feb 16, 2014 at 12:10:31PM -0600, Steve Dover wrote:
> Fix includes.h to have a
> 
> #include 
> 
> before the
> #include 
> (line 160)
> 
> 
> Seems like the correct fix to me, but as to why
> it did not show up for others is interesting, unless
> no one has tied to build on Linux?  That seems unlikely.
> 
> 
> 

Dropbear 2014.63

[Matt Johnston]

Hi all,

Dropbear 2014.63 is released containing mostly accumulated
bug fixes.  Some are for regressions in the past couple of
releases so it's recommended for everyone.

As usual the URL is
https://matt.ucc.asn.au/dropbear/dropbear.html 
or mirrored at
https://dropbear.nl/mirror/

Cheers,
Matt

2014.63 - Wednesday 19 February 2014

- Fix ~. to terminate a client interactive session after waking a laptop
  from sleep.

- Changed port separator syntax again, now using host^port. This is because
  IPv6 link-local addresses use %. Reported by Gui Iribarren

- Avoid constantly relinking dropbearmulti target, fix "make install"
  for multi target, thanks to Mike Frysinger

- Avoid getting stuck in a loop writing huge key files, reported by Bruno
  Thomsen

- Don't link dropbearkey or dropbearconvert to libz or libutil, 
  thanks to Nicolas Boos

- Fix linking -lcrypt on systems without /usr/lib, thanks to Nicolas Boos

- Avoid crash on exit due to cleaned up keys before last packets are sent,
  debugged by Ronald Wahl

- Fix a race condition in rekeying where Dropbear would exit if it received a
  still-in-flight packet after initiating rekeying. Reported by Oliver Metz.
  This is a longstanding bug but is triggered more easily since 2013.57

- Fix README for ecdsa keys, from Catalin Patulea

- Ensure that generated RSA keys are always exactly the length
  requested. Previously Dropbear always generated N+16 or N+15 bit keys.
  Thanks to Unit 193

- Fix DROPBEAR_CLI_IMMEDIATE_AUTH mode which saves a network round trip if the
  first public key succeeds. Still not enabled by default, needs more
  compatibility testing with other implementations.

- Fix for port 0 forwarding in the client and port forwarding with Apache MINA 
SSHD. Thanks to 

- Fix for bad system linux/pkt-sched.h header file with older Linux
  kernels, from Steve Dover

- Fix signal handlers so that errno is saved, thanks to Erik Ahlén for a patch
  and Mark Wickham for independently spotting the same problem.

Re: Dropbear channel request race condition?

[Matt Johnston]

Hi,

I'm not sure whether it's possible to use EOF like that for a
session with a PTY terminal. 

For a PTY session it will have a single file descriptor
(returned from openpty() or similar) for both stdin and
stdout. Dropbear's behaviour on receiving a EOF is to close
the stdin for the process (assuming no write data is
pending), then let the process deal with it. For the PTY
case closing that file descriptor will also close stdout.

For TCP channels Dropbear uses shutdown() to close each
direction independently, but I don't think that will work
with a PTY - anyone know?

Have you come across any programs that aren't flushing
buffers? Does running without a terminal work OK with your
EOF-sending program?  I tried to make a quick change to send
a eof straight away but can't replicate it.

(As a side-note I hit the same hassle with sudo needing a
terminal this week - annoying!)

Cheers,
Matt


On Thu, Mar 20, 2014 at 05:48:51PM +, Tim Broberg wrote:
> For reasons which may, or may not be, pathological, I'm working on
> developing
> an SSH client. I'm running into problems executing commands in a terminal
> on
> dropbear.
> 
> I'm sending an exec request to a session with a terminal (so I can run
> sudo commands).
> 
> I send the channel request, then send eof expecting to get data, exit
> status, and eof back.
> 
> Instead, dropbear server sends eof right away, then the running command
> fails because his terminal has been shut down. (See the last 3 lines of
> the server log snippet below.)
> 
> If I don't send eof, it works fine, but then I worry about other processes
> /
> Servers not flushing buffers out until they see eof.
> 
> I would expect dropbear to wait for the outstanding channel request to run
> to completion before sending eof.
> 
> Am I making sense, or is there some problem with my use case of requesting
> exec from a terminal session? If this is considered an invalid use case,
> what would you suggest as an appropriate usage / workaround?
> 
> The full log is attached, and an excerpt from receipt of eof to the
> failure of the command due to terminal non-existence is below.
> 
> Thanks for any help you're able to provide,
> - Tim.
> 
> TRACE (2354): enter recv_msg_channel_eof
> TRACE (2354): check_close: writefd 6, readfd 6, errfd -1, sent_close 0,
> recv_close 0
> TRACE (2354): writebuf size 0 extrabuf size 0
> TRACE (2354): sesscheckclose, pid is -1
> TRACE (2354): sesscheckclose, pid is -1
> TRACE (2354): CLOSE some fd 6
> TRACE (2354): enter send_msg_channel_eof
> TRACE (2354): enter encrypt_packet()
> TRACE (2354): encrypt_packet type is 96
> TRACE (2354): enter writemac
> TRACE (2354): leave writemac
> TRACE (2354): enter enqueue
> TRACE (2354): leave enqueue
> TRACE (2354): leave encrypt_packet()
> TRACE (2354): leave send_msg_channel_eof
> TRACE (2354): leave recv_msg_channel_eof
> TRACE (2354): leave process_packet
> TRACE (2354): check_close: writefd -1, readfd -1, errfd -1, sent_close 0,
> recv_close 0
> TRACE (2354): writebuf size 0 extrabuf size 0
> TRACE (2354): sesscheckclose, pid is -1
> TRACE (2354): sesscheckclose, pid is -1
> TRACE (2354): CLOSE some fd -1
> TRACE (2354): enter write_packet
> TRACE (2354): empty queue dequeing
> TRACE (2354): leave write_packet
> TRACE (2354): check_close: writefd -1, readfd -1, errfd -1, sent_close 0,
> recv_close 0
> TRACE (2354): writebuf size 0 extrabuf size 0
> TRACE (2354): sesscheckclose, pid is -1
> TRACE (2354): sesscheckclose, pid is -1
> TRACE (2354): CLOSE some fd -1
> TRACE (2356): back to normal sigchld
> [2356] Mar 19 14:13:12 ioctl(TIOCSCTTY): Input/output error
> [2356] Mar 19 14:13:12 /dev/pts/1: No such file or directory
> [2356] Mar 19 14:13:12 open /dev/tty failed - could not set controlling
> tty: No such device or address
> 
> 
> 

Re: Dropbear requiring passphrase

[Matt Johnston]

Hi,

Dropbear has its own key format and doesn't support passphrases (encrypted 
keys). OpenSSH might be getting confused by the unknown format so asks for a 
passphrase, while dbclient just falls back to password authentication? 
dropbearconvert can convert the formats.

Have a look at the Dropbear log /var/log/auth.log if you can, or run with 
"dropbear -F -E" interactively to log to stdout. In a boot script you should be 
able to run "dropbear -E" for just the logging to the console.

Cheers,
Matt

On 29 April 2014 5:03:29 pm AWST, Logan Anderson  wrote:
>Guys,
>
>I added drop bear to an initramfs I am building for PXE. No matter what
>I
>do, dropbear appears to require an ssh passphrase and I really don't
>know
>how to handle this. It doesn't ask me for a passphrase when I create
>the
>key.
>
>It appears to ask for the passphrase when I use ssh but it simply asks
>for
>a password when I use dbclient. What am I doing wrong?
>
>Any direction would be welcome.

Re: [PATCH] Limit size of the iovect passed to writev in packet.c

[Matt Johnston]

Hi Ronny,

Thanks for those patches, I've applied them. Definitely a
nasty bug.

Cheers,
Matt

On Mon, May 19, 2014 at 08:22:19AM +0200, ronny.me...@gmail.com wrote:
> The writev allows only a limited number of entries to be present in the
> iovector. This number depends on the OS. If more entries are passed, the
> writev operation fails and the connection is closed.
> 
> This patch limits the size of the vector to the maximum number accepted
> by the OS. On some operating systems IOV_MAX is not defined, if this is
> the case UIO_MAXIOV is being used as the maximum value.
> 
> In the problematic scenario the Linux box, running dropbear, has a slow
> uplink. If an ssh is done to the box and a command is executed that
> generates a lot of small fragments (for example a 'find .' in the root),
> a lot of small interactions are seen between dropbear and the shell process.
> The observation was that the amount of entries pending in the queue could
> go up to 7500. Since all entries present in the queue will be passed to
> writev an error will be returned since Linux only accepts 1024 entries to
> be present in the vector. The result is that the connection is being closed.

Re: SFTP Client support required for dropbear v0.48

[Matt Johnston]

Hi,

Dropbear doesn't come with a SFTP server. You might be able
to build the OpenSSH sftp-server to use, have a look through
the mailing list archives.

Cheers,
Matt

On Thu, May 22, 2014 at 08:14:20PM +0530, pratik singh wrote:
> Hi all,
> 
> I am running the default dropbear (version 0.48) found in the
> uClinux-dist distribution with my microblaze as the processor.
> Currently it does not support sftp client. Please let me know how i
> can run the sftp client on this?
> 
> Appreciate your reply.
> 
> 
> 
> -- 
> Thanks & Regards
> Pratik Singh

Re: SFTP Client support required for dropbear v0.48

[Matt Johnston]

Hi,

sftp-client should be similar - once you have a working sftp
binary you just run "sftp -S /path/to/dbclient"

Cheers,
Matt
On Fri, May 23, 2014 at 11:49:55PM +0530, pratik singh wrote:
> Hi Matt,
> 
> Thanks for the response.
> 
> I think there is some misunderstanding. I want sftp-client support instead
> of sftp-server. It would be great if I can get any help for the same.
> 
> Thanks
> Pratik
> 
> 
> On Fri, May 23, 2014 at 4:55 PM, Matt Johnston  wrote:
> 
> > Hi,
> >
> > Dropbear doesn't come with a SFTP server. You might be able
> > to build the OpenSSH sftp-server to use, have a look through
> > the mailing list archives.
> >
> > Cheers,
> > Matt
> >
> > On Thu, May 22, 2014 at 08:14:20PM +0530, pratik singh wrote:
> > > Hi all,
> > >
> > > I am running the default dropbear (version 0.48) found in the
> > > uClinux-dist distribution with my microblaze as the processor.
> > > Currently it does not support sftp client. Please let me know how i
> > > can run the sftp client on this?
> > >
> > > Appreciate your reply.
> > >
> > >
> > >
> > > --
> > > Thanks & Regards
> > > Pratik Singh
> >
> 
> 
> 
> -- 
> Thanks & Regards
> Pratik Singh

Re: Dropbear and crypt() implementation

[Matt Johnston]

Hi Martin,

How does your operating system authenticate users? crypt()
is kind of specific to how many unix-style systems store passwords in
/etc/passwd or /etc/shadow. You could modify your
svr-authpasswd.c to compare the hash of "password" with your
stored hashed password, or something similar.

Cheers,
Matt

On Wed, May 28, 2014 at 08:16:23PM +, Martin Osterloh wrote:
> Hi All,
> 
> 
> I am in the process of porting dropbear to my own operating system (x86 64 
> architecture). So far, I am happy with the progress.
> 
> 
> However, I just discovered that svr-authpasswd.c uses crypt(). I am using 
> newlib as a  general C library. I am not being provided with crypt() 
> unfortunately. Is there any general consensus what people do in this case? So 
> far I am just returning "send_msg_userauth_success()" which is  well not 
> that great.
> 
> 
> Any input would be greatly appreciated!
> 
> 
> Thanks,
> 
> --Martin
> 

Re: Need SCP Client support with dropbear V0.48

[Matt Johnston]

On Wed, Jun 04, 2014 at 01:19:33PM +0530, pratik singh wrote:
> Hi All,
> 
> I am running the default dropbear (version 0.48) found in the
> uClinux-dist distribution with my microblaze as the processor. I want
> to use scp with dropbear. Please let me know how can i achieve this?

You should be able to build scp as part of Dropbear with

make PROGRAMS="dropbear dbclient scp"

Cheers,
Matt

Re: Cross-compile for AM335x

[Matt Johnston]

Hi,

Sounds like something is wrong with the compiler. Take a
look at config.log, towards the bottom it'll have the
commandline and code that failed. Do you mean to set
--target=arm perhaps?

Cheers,
Matt

On Thu, Jun 26, 2014 at 10:53:38AM -0400, Nicolas Luna wrote:
> Hi,
> 
> I'm trying to cross-compile for ARM Cortex-A8 (AM335x) and I have a weird
> error. It looks like the toolchain is not supported.
> 
> What I executed:
> *./configure --prefix=/home/build-tools/dropbear-build/
> CC=arm-linux-gnueabihf-gcc --host=arm -disable-zlib*
> 
> What I received from configure script:
> *checking for arm-gcc... arm-linux-gcc*
> *checking whether the C compiler works... no*
> 
> *configure: error: C compiler cannot create executables*
> 
> The version of my toolchain (PSP 6.0 from TI)
> *#: arm-linux-gnueabihf-gcc -v*
> *gcc version 4.7.3 20130226 (prerelease) (crosstool-NG
> linaro-1.13.1-4.7-2013.03-20130313 - Linaro GCC 2013.03)*
> 
> Any ideas ?
> 
> Regards,
> 
> Nicolas

Re: TOS byte on port forwarding-only connections

[Matt Johnston]

On Fri, Jul 04, 2014 at 02:59:09AM -0400, Catalin Patulea wrote:
> 'ssh -Lx:x:x cat' is a workaround, albeit ugly. Ideally I would like
> 'ssh -N -Lx:x:x' to also trigger IPTOS_BULK.
> 
> I think for that I could start the connection at LOWDELAY, then reduce
> to BULK until the first pty session, then set LOWDELAY again. If the
> client deletes the pty session but keeps the connection, it will stay
> at LOWDELAY - we probably want it to reduce to BULK in that case.
> 
> How about a cleaner approach, where we keep a "refcount on lowdelay",
> updated when pty channels are created/removed. When the refcount
> transitions from 0->1, set LOWDELAY, 1->0, set BULK. I don't think
> it's all that much extra code and it will really do the right thing in
> many situations.
> 
> How would you feel about a patch for that?

Hi,

Thanks for the thoughts. It sounds consistent, but -L always
implying IPTOS_BULK isn't necessarily desirable. Multihop
interactive sessions ("dbclient host1,host2,host3") will
establish no-pty channels to host1 and host2. I assume there
are people using -N to tunnel interactive traffic through
port forwards too.

I'm not really sure how to resolve it though. Maybe as a
tradeoff the refcounting could just switch between LOWDELAY
and no-tos-flags if there are TCP forwards going on, then
BULK if there aren't TCP forwards?

Matt

Re: Getting dbclient to time out when network goes down with reverse proxy usage

[Matt Johnston]

On Fri, Jul 04, 2014 at 03:57:09AM -0700, Jesse Molina wrote:
> 
> Note that I have "ClientAliveInterval 15" set on the sshd_config
> server side. I would expect dropbear to count this traffic towards
> -I.
> 
> Without -I above, it took my device 18 minutes to figure out that I
> had pulled the network out from under it by shutting down the
> interface. That isn't acceptable.
> 
> Can dropbear do this, or do I need to use openssh?  I get the
> feeling after reading what I have read that dropbear is too simple
> to figure out when the server has gone away in most situations.

I've now made "-K" do the same as OpenSSH's
ServerAliveInterval/ClientAliveInterval. CountMax is
hardcoded to 3 in options.h - I don't think that needs to be
a runtime setting. I've only given it brief testing, it
might need some more attention to cases such as clients
being suspended (laptop lid shuts).
https://secure.ucc.asn.au/hg/dropbear/rev/a0819ecfee0b

I don't _think_ anyone really desired the old -K behaviour
of sending keepalives but not caring about the response - it
can still be used to keep a NAT session open, and if you've
gone that long without a response then the session is
probably dead anyway. Someone please correct me if I'm
mistaken.

-I deliberately ignores keepalive traffic to avoid bad
interactions. I think that's desirable.

For reference the issue Fabrizio had with OpenSSH
ClientAliveInterval looks like it was fixed in OpenSSH 4.9
https://bugzilla.mindrot.org/show_bug.cgi?id=1307
I've also made Dropbear send a SSH_MSG_REQUEST_FAILURE
response as suggested in Ahilan's reply - better late than
never!
https://www.mail-archive.com/dropbear@ucc.asn.au/msg00711.html

Cheers,
Matt

Re: Small build without ECDSA gives errors

[Matt Johnston]

Hi Bruno,

This is fixed for the next release, you can get the change from 
https://secure.ucc.asn.au/hg/dropbear/rev/25692c60479e

Cheers,
Matt

On 10 July 2014 12:02:18 am AWST, Bruno Vernay  wrote:
>Hi,
>
>I try to build a small Dropbear server (dropbear-2014.63)
>
>>From option.h, I commented out DROPBEAR_ECDSA and DROPBEAR_DSS and
>other things ...
>
>make clean
>./configure --disable-syslog --disable-shadow --disable-lastlog
>--disable-zlib  --prefix=/mnt/rwfs/dropbear
>--host=arm-fsl-linux-gnueabi  --build=i686-pc-linux-gnu ARCH=arm
>CROSS_COMPILE=arm-none-linux-gnueabi-   CC=arm-fsl-linux-gnueabi-gcc
>LDFLAGS=-Wl,--gc-sections  CFLAGS="-ffunction-sections
>-fdata-sections"
>make PROGRAMS="dropbear"
>
>...
>and I get this error:
>
>arm-fsl-linux-gnueabi-gcc -ffunction-sections -fdata-sections
>-I./libtomcrypt/src/headers/ -I. -I.
>-I/opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/arm-fsl
>  -linux-gnueabi/multi-libs/usr/include
>-ffunction-sections -fdata-sections -DDROPBEAR_SERVER
>-I/opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/arm-fsl-linux-
>  gnueabi/multi-libs/usr/include  -c -o signkey.o
>signkey.c
>signkey.c: In function 'signkey_key_ptr':
>signkey.c:110: error: 'DROPBEAR_SIGNKEY_ECDSA_NISTP256' undeclared
>(first use in this function)
>signkey.c:110: error: (Each undeclared identifier is reported only once
>signkey.c:110: error: for each function it appears in.)
>signkey.c:111: error: 'sign_key' has no member named 'ecckey256'
>signkey.c:114: error: 'DROPBEAR_SIGNKEY_ECDSA_NISTP384' undeclared
>(first use in this function)
>signkey.c:115: error: 'sign_key' has no member named 'ecckey384'
>signkey.c:118: error: 'DROPBEAR_SIGNKEY_ECDSA_NISTP521' undeclared
>(first use in this function)
>signkey.c:119: error: 'sign_key' has no member named 'ecckey521'
>make: *** [signkey.o] Error 1
>
>
>Any idea ??
>
>-- 
>Bruno

Re: TOS byte on port forwarding-only connections

[Matt Johnston]

Hi Catalin,

Yes, that's what I was thinking of. I can implement it.

Cheers,
Matt

On 14 July 2014 2:56:17 am AWST, Catalin Patulea  wrote:
>On Tue, Jul 8, 2014 at 9:44 AM, Matt Johnston  wrote:
>> I'm not really sure how to resolve it though. Maybe as a
>> tradeoff the refcounting could just switch between LOWDELAY
>> and no-tos-flags if there are TCP forwards going on, then
>> BULK if there aren't TCP forwards?
>Ok, so if I'm understanding correctly, the invariant would be something
>like:
>
>if (connecting || ptys) tos = LOWDELAY;
>else if (tcp_forwards) tos = 0;
>else tos = BULK;
>
>This might be implemented cleverly so that it's only reapplied on 0/1
>transitions of ptys and tcp_forwards, but these would be the
>high-level semantics?

Re: TOS byte on port forwarding-only connections

[Matt Johnston]

> On 14 July 2014 2:56:17 am AWST, Catalin Patulea  wrote:
> >Ok, so if I'm understanding correctly, the invariant would be something
> >like:
> >
> >if (connecting || ptys) tos = LOWDELAY;
> >else if (tcp_forwards) tos = 0;
> >else tos = BULK;

I've implemented this in
https://secure.ucc.asn.au/hg/dropbear/rev/5daedffd0769

I'm hoping to get a new release out in the next week or so.

After that release I'll merge the PAM branch
https://secure.ucc.asn.au/hg/dropbear/shortlog/bae0b34bc059
which should provide full PAM module support. Two factor
auth modules should work, and locale/environment setup. It's
ready for testing now.

Cheers,
Matt

Re: Does Dropbear support SCP server?

[Matt Johnston]

On Fri, Jul 25, 2014 at 03:51:58PM +0530, pratik singh wrote:
> Hi,
> 
> I am running the default dropbear (version 0.48) found in the uClinux-dist
> distribution with my microblaze as the processor.  It has SCP client
> support.
> 
> Does it support SCP server also? If Yes, what are all the changes required?

Yes. The scp "server" is just the normal scp binary, the
client sends a commandline with some extra flags to run it
on the ssh server.

Cheers,
Matt

Dropbear 2014.64

[Matt Johnston]

Hi all,

Dropbear 2014.64 is released with changes as follows. 
As usual get it from
https://matt.ucc.asn.au/dropbear/dropbear.html or 
https://dropbear.nl/mirror/

Cheers,
Matt


2014.64 - Sunday 27 July 2014

- Fix compiling with ECDSA and DSS disabled

- Don't exit abruptly if too many outgoing packets are queued for writev(). 
Patch
  thanks to Ronny Meeus

- The -K keepalive option now behaves more like OpenSSH's 
"ServerAliveInterval". 
  If no response is received after 3 keepalives then the session is terminated. 
This
  will close connections faster than waiting for a TCP timeout.

- Rework TCP priority setting. New settings are
if (connecting || ptys || x11) tos = LOWDELAY
else if (tcp_forwards) tos = 0
else tos = BULK
  Thanks to Catalin Patulea for the suggestion.

- Improve handling of many concurrent new TCP forwarded connections, should now
  be able to handle as many as MAX_CHANNELS. Thanks to Eduardo Silva for 
reporting
  and investigating it.

- Make sure that exit messages from the client are printed, regression in 
2013.57

- Use monotonic clock where available, timeouts won't be affected by system time
  changes

- Add -V for version

Re: Dropbear 2014.64

[Matt Johnston]

Hi,

Thanks for tracking that down, I'll see what's going on with channel closing.

Would you be able to send a strace of the clock_gettime issue? I avoided 
clock_gettime() from glibc since that pulls in librt. I'm curious how it's 
failing. Dropbear should probably just check the second clock_gettime return 
value then use clock() instead.

Thanks,
Matt

On 28 July 2014 11:06:14 am AWST, NiLuJe  wrote:
>Yup, building master w/ ca86726 reverted does the trick on the machine
>where
>I'm experiencing this issue...

Re: Dropbear 2014.64

[Matt Johnston]

On Mon, Jul 28, 2014 at 01:56:43PM +, NiLuJe wrote:
> Sure ;). Basically, if CLOCK_MONOTONIC_COARSE isn't supported, it never
> falls back to CLOCK_MONOTONIC (AFAICT, that's because the only way to check
> the status of syscall() is through errno, not its return value?).

Oh, that's a bit embarassing, it should certainly check errno.

> BTW, the clock_source variable isn't terribly useful, since we're using the
> constants only once, and only in the clock_gettime call (and I just realized
> that the CLOCK_MONOTONIC fallback just uses the constant directly anyway).
> 
> Also, why not ifdef the CLOCK_MONOTONIC_COARSE stuff? If it's not defined,
> there's not much chance it'll work at runtime, unless I missed something ;).

The Linux headers people are building against often don't
match the running kernel, particularly with strange embedded
toolchains.  So first-time it tests if the running kernel
supports CLOCK_MONTONIC_COARSE, then if it doesn't work
keeps going with CLOCK_MONOTONIC. That's the intent anyway,
I'll fix it and make it also fallback if CLOCK_MONOTONIC
fails.

Thanks,
Matt

Re: Dropbear 2014.64

[Matt Johnston]

On Mon, Jul 28, 2014 at 03:06:14AM +, NiLuJe wrote:
> Yup, building master w/ ca86726 reverted does the trick on the machine where
> I'm experiencing this issue...

Could you try with
https://github.com/mkj/dropbear/commit/0e7409c7ff6fc760018fce3d5e8b72247bf782b5

(the same as  https://secure.ucc.asn.au/hg/dropbear/rev/36eacc322e00 )

I can sometimes reproduce it here and that patch seems to
solve the problem. I was assuming that all channel state
changes would occur through file descriptors, forgetting
about signal handlers when a process exits.

Thanks,
Matt

# HG changeset patch
# User Matt Johnston 
# Date 1406561029 -28800
# Node ID 36eacc322e00924e511810c519bf5a3f05898cdd
# Parent  356a25a108a3338b58f22a6c5b03336a10cd2bbd
Make sure the check_close() handler runs when a server child process exits

diff -r 356a25a108a3 -r 36eacc322e00 common-channel.c
--- a/common-channel.c  Mon Jul 28 22:59:16 2014 +0800
+++ b/common-channel.c  Mon Jul 28 23:23:49 2014 +0800
@@ -258,6 +258,12 @@
writechannel(channel, channel->errfd, 
channel->extrabuf);
do_check_close = 1;
}
+
+   if (ses.channel_signal_pending) {
+   /* SIGCHLD can change channel state for server sessions 
*/
+   do_check_close = 1;
+   ses.channel_signal_pending = 0;
+   }

/* handle any channel closing etc */
if (do_check_close) {
diff -r 356a25a108a3 -r 36eacc322e00 session.h
--- a/session.h Mon Jul 28 22:59:16 2014 +0800
+++ b/session.h Mon Jul 28 23:23:49 2014 +0800
@@ -187,6 +187,7 @@
unsigned int chansize; /* the number of Channel*s allocated for 
channels */
unsigned int chancount; /* the number of Channel*s in use */
const struct ChanType **chantypes; /* The valid channel types */
+   int channel_signal_pending; /* Flag set by sigchld handler */
 
/* TCP priority level for the main "port 22" tcp socket */
enum dropbear_prio socket_prio;
diff -r 356a25a108a3 -r 36eacc322e00 svr-chansession.c
--- a/svr-chansession.c Mon Jul 28 22:59:16 2014 +0800
+++ b/svr-chansession.c Mon Jul 28 23:23:49 2014 +0800
@@ -89,6 +89,9 @@
 
const int saved_errno = errno;
 
+   /* Make channel handling code look for closed channels */
+   ses.channel_signal_pending = 1;
+
TRACE(("enter sigchld handler"))
while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
TRACE(("sigchld handler: pid %d", pid))

Re: Dropbear 2014.64

[Matt Johnston]

I plan to release 2013.65 early next week to fix those regressions. If anyone 
has seen other problems please let me know.

Cheers,
Matt

On 27 July 2014 11:41:56 pm AWST, Matt Johnston  wrote:
>Hi all,
>
>Dropbear 2014.64 is released with changes as follows. 
>As usual get it from
>https://matt.ucc.asn.au/dropbear/dropbear.html or 
>https://dropbear.nl/mirror/
>
>Cheers,
>Matt
>
>
>2014.64 - Sunday 27 July 2014
>
>- Fix compiling with ECDSA and DSS disabled
>
>- Don't exit abruptly if too many outgoing packets are queued for
>writev(). Patch
>  thanks to Ronny Meeus
>
>- The -K keepalive option now behaves more like OpenSSH's
>"ServerAliveInterval". 
>If no response is received after 3 keepalives then the session is
>terminated. This
>  will close connections faster than waiting for a TCP timeout.
>
>- Rework TCP priority setting. New settings are
>   if (connecting || ptys || x11) tos = LOWDELAY
>   else if (tcp_forwards) tos = 0
>   else tos = BULK
>  Thanks to Catalin Patulea for the suggestion.
>
>- Improve handling of many concurrent new TCP forwarded connections,
>should now
>be able to handle as many as MAX_CHANNELS. Thanks to Eduardo Silva for
>reporting
>  and investigating it.
>
>- Make sure that exit messages from the client are printed, regression
>in 2013.57
>
>- Use monotonic clock where available, timeouts won't be affected by
>system time
>  changes
>
>- Add -V for version

Re: [PATCH] use xauth in /usr/bin

[Matt Johnston]

Thanks, I've committed it.

On Fri, Aug 01, 2014 at 06:15:01AM -0400, Mike Frysinger wrote:
> # HG changeset patch
> # User Mike Frysinger 
> # Date 1406888059 14400
> #  Fri Aug 01 06:14:19 2014 -0400
> # Node ID 89a637587a611c0bf3802ff5005bc1f7fe63eec6
> # Parent  36eacc322e00924e511810c519bf5a3f05898cdd
> use xauth in /usr/bin
> 
> Since the x.org rework, X has been installed into standard paths and not
> its own random prefixes.  I think it's time we update the default paths
> accordingly.
> 
> diff -r 36eacc322e00 -r 89a637587a61 options.h
> --- a/options.h   Mon Jul 28 23:23:49 2014 +0800
> +++ b/options.h   Fri Aug 01 06:14:19 2014 -0400
> @@ -264,7 +264,7 @@
>  /* The command to invoke for xauth when using X11 forwarding.
>   * "-q" for quiet */
>  #ifndef XAUTH_COMMAND
> -#define XAUTH_COMMAND "/usr/bin/X11/xauth -q"
> +#define XAUTH_COMMAND "/usr/bin/xauth -q"
>  #endif
>  
>  /* if you want to enable running an sftp server (such as the one included 
> with

Re: Dropbear 2014.64

[Matt Johnston]

On Fri, Aug 01, 2014 at 06:10:46AM -0400, Mike Frysinger wrote:
> > 
> fwiw, glibc-2.19 has moved clock_gettime to libc

Ah, good to know. At some point I'll add a test for
clock_gettime() in configure, though want a bit more testing
first.

Cheers,
Matt

Re: Regarding dbclient failure

[Matt Johnston]

Hi Pratik,

It looks like it is failing when it tries to read the 'y/n' response from 
/dev/tty.  Can you check that is set up correctly on the system? Running 
'strace -o logfile dbclient...' might have some clues if you send me it.

You can skip the hostkey confirmation with '-y' but that means you lose 
security against the SSH session being altered or monitored. Useful for 
debugging though.

Cheers,
Matt

On 7 August 2014 10:47:37 pm AWST, pratik singh  wrote:
>Hi,
>
>I am using Dropbear 0.48 with uClinux-dist. Currently server is working
>fine but while trying to run dbclient its throwing following error:
>
>
>#dbclient -i dss_key pratik@10.10.10.1
>
>TRACE: enter session_init
>TRACE: kexinitialise()
>TRACE: leave session_init
>TRACE: enter ident_readln
>TRACE: leave ident_readln: return 20
>TRACE: remoteident: SSH-2.0-OpenSSH_4.3
>TRACE: enter encrypt_packet()
>TRACE: encrypt_packet type is 20
>TRACE: enter writemac
>TRACE: leave writemac
>TRACE: enter enqueue
>TRACE: leave enqueue
>TRACE: leave encrypt_packet()
>TRACE: DATAALLOWED=0
>TRACE: -> KEXINIT
>TRACE: enter write_packet
>TRACE: empty queue dequeing
>TRACE: leave write_packet
>TRACE: enter read_packet
>TRACE: enter decrypt_packet
>TRACE: leave decrypt_packet
>TRACE: leave read_packet
>TRACE: enter process_packet
>TRACE: process_packet: packet type = 20
>TRACE: <- KEXINIT
>TRACE: enter recv_msg_kexinit
>TRACE: cli_buf_match_algo:
>diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
>TRACE: kex algo diffie-hellman-group1-sha1
>TRACE: cli_buf_match_algo: ssh-rsa,ssh-dss
>TRACE: hostkey algo ssh-dss
>TRACE: cli_buf_match_algo:
>aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,
>rijndael-...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
>TRACE: enc c2s is  aes128-cbc
>TRACE: cli_buf_match_algo:
>aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,
>rijndael-...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
>TRACE: enc s2c is  aes128-cbc
>TRACE: cli_buf_match_algo: hmac-md5,hmac-sha1,hmac-ripemd160,
>hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
>TRACE: hash c2s is  hmac-sha1-96
>TRACE: cli_buf_match_algo: hmac-md5,hmac-sha1,hmac-ripemd160,
>hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
>TRACE: hash s2c is  hmac-sha1-96
>TRACE: cli_buf_match_algo: none,z...@openssh.com
>TRACE: hash c2s is  none
>TRACE: cli_buf_match_algo: none,z...@openssh.com
>TRACE: hash s2c is  none
>TRACE: leave recv_msg_kexinit
>TRACE: leave process_packet
>TRACE: enter cli_sessionloop
>TRACE: enter send_msg_kexdh_reply
>
>
>TRACE: enter buf_putmpint
>TRACE: leave buf_putmpint
>TRACE: enter encrypt_packet()
>TRACE: encrypt_packet type is 30
>TRACE: enter writemac
>TRACE: leave writemac
>TRACE: enter enqueue
>TRACE: leave enqueue
>TRACE: leave encrypt_packet()
>TRACE: leave cli_sessionloop: done with KEXINIT_RCVD
>TRACE: enter write_packet
>TRACE: empty queue dequeing
>TRACE: leave write_packet
>TRACE: enter cli_sessionloop
>TRACE: leave cli_sessionloop: kex_state != KEX_NOTHING
>TRACE: enter read_packet
>TRACE: enter decrypt_packet
>TRACE: leave decrypt_packet
>TRACE: leave read_packet
>TRACE: enter process_packet
>TRACE: process_packet: packet type = 31
>TRACE: enter recv_msg_kexdh_reply
>TRACE: type is 2
>TRACE: enter buf_getline
>
>
>
>
>
>
>
>
>
>
>
>
>*TRACE: leave buf_getline: failureTRACE: failed reading line: prob EOF
>Host
>'10.10.10.1' is not in the trusted hosts file. (fingerprint md5
>aa:c4:3e:32:ac:42:5b:21:0e:86:7d:b2:21:db:fb:1c)Do you want to continue
>connecting? (y/n)TRACE: enter cli_tty_cleanupTRACE: leave
>cli_tty_cleanup:
>not in raw modeTRACE: enter session_cleanup TRACE: enter
>chancleanupTRACE:
>leave chancleanupTRACE: leave session_cleanupdbclient: connection to
>pratik@10.10.10.1:22  exited: Didn't
>validate
>host key*
>-
>
>Any suggestions on this would be a great help.
>
>-- 
>Thanks & Regards
>Pratik Singh

Re: Regarding dbclient failure

[Matt Johnston]

Hi Pratik,

It looks like it is failing when it tries to read the 'y/n' response from 
/dev/tty.  Can you check that is set up correctly on the system? Running 
'strace -o logfile dbclient...' might have some clues if you send me it.

You can skip the hostkey confirmation with '-y' but that means you lose 
security against the SSH session being altered or monitored. Useful for 
debugging though.

Cheers,
Matt

On 7 August 2014 10:47:37 pm AWST, pratik singh  wrote:
>Hi,
>
>I am using Dropbear 0.48 with uClinux-dist. Currently server is working
>fine but while trying to run dbclient its throwing following error:
>
>
>#dbclient -i dss_key pratik@10.10.10.1
>
>TRACE: enter session_init
>TRACE: kexinitialise()
>TRACE: leave session_init
>TRACE: enter ident_readln
>TRACE: leave ident_readln: return 20
>TRACE: remoteident: SSH-2.0-OpenSSH_4.3
>TRACE: enter encrypt_packet()
>TRACE: encrypt_packet type is 20
>TRACE: enter writemac
>TRACE: leave writemac
>TRACE: enter enqueue
>TRACE: leave enqueue
>TRACE: leave encrypt_packet()
>TRACE: DATAALLOWED=0
>TRACE: -> KEXINIT
>TRACE: enter write_packet
>TRACE: empty queue dequeing
>TRACE: leave write_packet
>TRACE: enter read_packet
>TRACE: enter decrypt_packet
>TRACE: leave decrypt_packet
>TRACE: leave read_packet
>TRACE: enter process_packet
>TRACE: process_packet: packet type = 20
>TRACE: <- KEXINIT
>TRACE: enter recv_msg_kexinit
>TRACE: cli_buf_match_algo:
>diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
>TRACE: kex algo diffie-hellman-group1-sha1
>TRACE: cli_buf_match_algo: ssh-rsa,ssh-dss
>TRACE: hostkey algo ssh-dss
>TRACE: cli_buf_match_algo:
>aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,
>rijndael-...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
>TRACE: enc c2s is  aes128-cbc
>TRACE: cli_buf_match_algo:
>aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,
>rijndael-...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
>TRACE: enc s2c is  aes128-cbc
>TRACE: cli_buf_match_algo: hmac-md5,hmac-sha1,hmac-ripemd160,
>hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
>TRACE: hash c2s is  hmac-sha1-96
>TRACE: cli_buf_match_algo: hmac-md5,hmac-sha1,hmac-ripemd160,
>hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
>TRACE: hash s2c is  hmac-sha1-96
>TRACE: cli_buf_match_algo: none,z...@openssh.com
>TRACE: hash c2s is  none
>TRACE: cli_buf_match_algo: none,z...@openssh.com
>TRACE: hash s2c is  none
>TRACE: leave recv_msg_kexinit
>TRACE: leave process_packet
>TRACE: enter cli_sessionloop
>TRACE: enter send_msg_kexdh_reply
>
>
>TRACE: enter buf_putmpint
>TRACE: leave buf_putmpint
>TRACE: enter encrypt_packet()
>TRACE: encrypt_packet type is 30
>TRACE: enter writemac
>TRACE: leave writemac
>TRACE: enter enqueue
>TRACE: leave enqueue
>TRACE: leave encrypt_packet()
>TRACE: leave cli_sessionloop: done with KEXINIT_RCVD
>TRACE: enter write_packet
>TRACE: empty queue dequeing
>TRACE: leave write_packet
>TRACE: enter cli_sessionloop
>TRACE: leave cli_sessionloop: kex_state != KEX_NOTHING
>TRACE: enter read_packet
>TRACE: enter decrypt_packet
>TRACE: leave decrypt_packet
>TRACE: leave read_packet
>TRACE: enter process_packet
>TRACE: process_packet: packet type = 31
>TRACE: enter recv_msg_kexdh_reply
>TRACE: type is 2
>TRACE: enter buf_getline
>
>
>
>
>
>
>
>
>
>
>
>
>*TRACE: leave buf_getline: failureTRACE: failed reading line: prob EOF
>Host
>'10.10.10.1' is not in the trusted hosts file. (fingerprint md5
>aa:c4:3e:32:ac:42:5b:21:0e:86:7d:b2:21:db:fb:1c)Do you want to continue
>connecting? (y/n)TRACE: enter cli_tty_cleanupTRACE: leave
>cli_tty_cleanup:
>not in raw modeTRACE: enter session_cleanup TRACE: enter
>chancleanupTRACE:
>leave chancleanupTRACE: leave session_cleanupdbclient: connection to
>pratik@10.10.10.1:22  exited: Didn't
>validate
>host key*
>-
>
>Any suggestions on this would be a great help.
>
>-- 
>Thanks & Regards
>Pratik Singh

Dropbear 2014.65

[Matt Johnston]

Hi,

Here's Dropbear 2014.65. It mainly fixes regressions in
2014.64, with a couple of other minor improvements.

https://matt.ucc.asn.au/dropbear/dropbear.html
https://dropbear.nl/mirror/

Cheers,
Matt

2014.65 - Friday 8 August 2014

- Fix 2014.64 regression, server session hang on exit with scp (and probably
  others), thanks to NiLuJe for tracking it down

- Fix 2014.64 regression, clock_gettime() error handling which broke on older
  Linux kernels, reported by NiLuJe

- Fix 2014.64 regression, writev() could occassionally fail with EAGAIN which
  wasn't caught

- Avoid error message when trying to set QoS on proxycommand or multihop pipes

- Use /usr/bin/xauth, thanks to Mike Frysinger

- Don't exit the client if the local user entry can't be found, thanks to iquaba

Releases signed with PGP key
4C647FBC Matthew Johnston 
D11E 5F8D 2C38 523F 57F1  2166 8CF9 F8B0 4C64 7FBC

Re: Regarding dbclient failure

[Matt Johnston]

On Tue, Aug 12, 2014 at 07:19:45PM +0530, pratik singh wrote:
> Hi Matt,
> 
> Thanks for your valuable suggestion.
> Unfortunately my system doesn't have "strace" utility support. I tried
> dbclient with "-y" option but again its failing again with "write
> error:broken pipe".

Hi Pratik,

It seems like ttys are broken somehow. Could you try the following:

At a prompt:
read testvar < /dev/tty
somethinghere (then press enter)

echo $testvar

It should print "somethinghere".

How are you getting a shell on the system - Dropbear or
serial console or something else?

Cheers,
Matt

Re: Failure to use dropbear with PAM

[Matt Johnston]

On Wed, Aug 20, 2014 at 01:25:21PM +, DELOGET, Emmanuel wrote:
> Hello, 
> 
> Yet in my use case I have to authenticate users whose login/password 
> information is stored in a distant database. Everytime I try to log in with 
> such a user, dropear answers me that the user is unknown - and that's true : 
> the user is unknown, because the whole point is to not have him/her in 
> /etc/passwd but on a distant database. 
> 
> That's where things break : dropbear seems to assume that the user must be 
> known on the system where it runs - that's one of the purpose of 
> checkusername() in svr-auth.c. If the user is not found in /etc/passwd then 
> it's not a valid user and login fails. 

Hi Emmanuel,

Is this a normal Unix type system or something more
embedded? From what I've seen the normal approach for remote
DB auth (LDAP etc) is to have nsswitch.conf set up to know
about the users, then optionally a PAM module if there isn't
a straightforward mapping to Unix password crypts. Would
that work for your situation? The benefit there is that all
programs know about the user using the standard user APIs.

Dropbear's PAM currently only allows username/password,
though there's a dev branch that should allow kind of
authentication conversation. It doesn't handle user
remapping though since that seems out of PAM's scope. Note
that the branch also needs some attention in terms of setting up PAM
login sessions properly.

Cheers,
Matt

Re: dbclient failed : Server Timeout

[Matt Johnston]

On Thu, Aug 21, 2014 at 11:31:43PM +0530, pratik singh wrote:
> This issue can be  resolve if I can reduce the time taken by dbclient.
> Currently its taking more than 5 minutes.
> 
> Please share your inputs to reduce this time taken by dbclient. How can I
> achieve this? Appreciate your reply.

Hi Pratik,

You could take a look at the work William Welch did on
improving Dropbear Microblaze performance, see
the thread http://thread.gmane.org/gmane.network.ssh.dropbear/1350/focus=1359
and 
https://github.com/bvwelch/dropbear (though I'm not sure if
that branch is complete).

What clock speed and device is it, out of interest?

Cheers,
Matt