From dllud at riseup.net Sat Apr 1 09:34:39 2017 From: dllud at riseup.net (dllud) Date: Sat, 1 Apr 2017 02:34:39 +0100 Subject: ED25519 key support? In-Reply-To: <20160628225054.GO4685@vapier.lan> References: <20160628225054.GO4685@vapier.lan> Message-ID: Hi, The feature parity argument gets stronger by the day. Right now I use a ed25519 key on all machines except for those running Dropbear (routers). Anyone willing to take a look at this? Thanks, dllud From peter at softwolves.pp.se Tue May 9 20:34:20 2017 From: peter at softwolves.pp.se (Peter Krefting) Date: Tue, 9 May 2017 13:34:20 +0100 (CET) Subject: [PATCH] dropbear: support out-of-tree builds Message-ID: Fixes issues with libtomcrypt and libtommath not finding config.h when building out-of-tree. --- libtomcrypt/Makefile.in | 2 +- libtommath/Makefile.in | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libtomcrypt/Makefile.in b/libtomcrypt/Makefile.in index 3056ef0..40dea1a 100644 --- a/libtomcrypt/Makefile.in +++ b/libtomcrypt/Makefile.in @@ -19,7 +19,7 @@ srcdir=@srcdir@ # Compilation flags. Note the += does not write over the user's CFLAGS! # The rest of the flags come from the parent Dropbear makefile -CFLAGS += -c -I$(srcdir)/src/headers/ -I$(srcdir)/../ -DLTC_SOURCE -I$(srcdir)/../libtommath/ +CFLAGS += -c -I$(srcdir)/src/headers/ -I$(srcdir)/../ -DLTC_SOURCE -I$(srcdir)/../libtommath/ -I../ # additional warnings (newer GCC 3.4 and higher) ifdef GCC_34 diff --git a/libtommath/Makefile.in b/libtommath/Makefile.in index 06aba68..f6e34c2 100644 --- a/libtommath/Makefile.in +++ b/libtommath/Makefile.in @@ -9,7 +9,7 @@ VPATH=@srcdir@ srcdir=@srcdir@ # So that libtommath can include Dropbear headers for options and m_burn() -CFLAGS += -I$(srcdir)/../libtomcrypt/src/headers/ -I$(srcdir)/../ +CFLAGS += -I$(srcdir)/ -I$(srcdir)/../libtomcrypt/src/headers/ -I$(srcdir)/../ -I../ ifndef IGNORE_SPEED -- 2.12.0 From matt at ucc.asn.au Wed May 10 00:39:23 2017 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 10 May 2017 00:39:23 +0800 Subject: [PATCH] dropbear: support out-of-tree builds In-Reply-To: References: Message-ID: Hi Peter, Thank you for the patch. I think this should be solved in the hg tree but it didn't make it into the 2016.74 release. https://github.com/mkj/dropbear/commit/3aeb55719633108471564b6780fe735c897a368a I'll see if I can get a release sorted out in the next few weeks. Current hg/git head has some large changes to options.h handling which haven't been tested much. I may make a smaller cherry picked release first with accumulated patches, with a separate release for options.h changes. Cheers, Matt > On Tue 9/5/2017, at 8:34 pm, Peter Krefting wrote: > > Fixes issues with libtomcrypt and libtommath not finding config.h when > building out-of-tree. > > --- > libtomcrypt/Makefile.in | 2 +- > libtommath/Makefile.in | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libtomcrypt/Makefile.in b/libtomcrypt/Makefile.in > index 3056ef0..40dea1a 100644 > --- a/libtomcrypt/Makefile.in > +++ b/libtomcrypt/Makefile.in > @@ -19,7 +19,7 @@ srcdir=@srcdir@ > > # Compilation flags. Note the += does not write over the user's CFLAGS! > # The rest of the flags come from the parent Dropbear makefile > -CFLAGS += -c -I$(srcdir)/src/headers/ -I$(srcdir)/../ -DLTC_SOURCE -I$(srcdir)/../libtommath/ > +CFLAGS += -c -I$(srcdir)/src/headers/ -I$(srcdir)/../ -DLTC_SOURCE -I$(srcdir)/../libtommath/ -I../ > > # additional warnings (newer GCC 3.4 and higher) > ifdef GCC_34 > diff --git a/libtommath/Makefile.in b/libtommath/Makefile.in > index 06aba68..f6e34c2 100644 > --- a/libtommath/Makefile.in > +++ b/libtommath/Makefile.in > @@ -9,7 +9,7 @@ VPATH=@srcdir@ > srcdir=@srcdir@ > > # So that libtommath can include Dropbear headers for options and m_burn() > -CFLAGS += -I$(srcdir)/../libtomcrypt/src/headers/ -I$(srcdir)/../ > +CFLAGS += -I$(srcdir)/ -I$(srcdir)/../libtomcrypt/src/headers/ -I$(srcdir)/../ -I../ > > ifndef IGNORE_SPEED > > -- > 2.12.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20170510/31cc3894/attachment.htm From sriram.ec at gmail.com Wed May 10 01:08:28 2017 From: sriram.ec at gmail.com (Sriram) Date: Tue, 9 May 2017 22:38:28 +0530 Subject: dropbear with PAM support - Unable to do ssh. Message-ID: Hello, I m facing a problem when I am trying to use dropbear with PAM support. My requirement is to restrict certain users to do ssh only through certain interfaces. for ex: my board has 2 ip's 10.207.18.101/24 on eth0 and 10.207.118.101/24 on eth1. dropbear server listens on port 22 on both of these interfaces. Given this scenario, I want to restrict a particular user say "abc" to be able to do ssh only through eth1 network. like "abc" should be able to login from ip's like 10.207.118.102/24, 10.207.118.103/24 etc., I didnt find a way to do using only dropbear. So had to integrate dropbear with PAM. I applied this patch to dropbear-2016.74.tar.bz2 --- a/options.h +++ b/options.h @@ -213,10 +213,10 @@ If you test it please contact the Dropbear author */ /* This requires crypt() */ #ifdef HAVE_CRYPT -#define ENABLE_SVR_PASSWORD_AUTH +/*#define ENABLE_SVR_PASSWORD_AUTH*/ #endif /* PAM requires ./configure --enable-pam */ -/*#define ENABLE_SVR_PAM_AUTH */ +#define ENABLE_SVR_PAM_AUTH #define ENABLE_SVR_PUBKEY_AUTH Configured and compiled dropbear with PAM support. I added below configuration files. a. cat /etc/pam.d/sshd auth required pam_unix.so account required pam_access.so b. cat /etc/security/access.conf + : root : ALL + : abc : 10.207.118.0/24 - : abc : 10.207.18.0/24 - : ALL : ALL But with this configuration, abc is unable to login to the machine via 10.207.118.0/24 also. Any idea on how to fix this one ? Apologies if its not the right forum to ask this question. Regards, Sriram. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20170509/db356773/attachment.htm From salatiel.filho at gmail.com Wed May 17 02:07:28 2017 From: salatiel.filho at gmail.com (Salatiel Filho) Date: Tue, 16 May 2017 15:07:28 -0300 Subject: Implement CheckHostIP, StrictHostKeyChecking, ServerAliveCountMax , ServerAliveInterval Message-ID: Would it be possible to implement CheckHostIP, StrictHostKeyChecking, ServerAliveCountMax and ServerAliveInterval from ssh client ? These are the only options missing to use sshtunnel from openwrt without depending on the huge sshclient package. Thanks! []'s Salatiel From peter at softwolves.pp.se Thu May 18 15:06:58 2017 From: peter at softwolves.pp.se (Peter Krefting) Date: Thu, 18 May 2017 08:06:58 +0100 (CET) Subject: [PATCH] dropbear: support out-of-tree builds In-Reply-To: References: Message-ID: Hi! > Thank you for the patch. I think this should be solved in the hg > tree but it didn't make it into the 2016.74 release. It does indeed. I didn't notice it when looking through the revision history. Sorry for the duplicate. -- \\// Peter - http://www.softwolves.pp.se/ From wharms at bfs.de Thu May 18 17:40:24 2017 From: wharms at bfs.de (walter harms) Date: Thu, 18 May 2017 11:40:24 +0200 Subject: Errorcodes Message-ID: <591D6C08.4030404@bfs.de> Hi List, i am using dropbear is a script and was testing error codes. I noticed that DB returns 0 (success) even when authentication does not work. (OpenSSH returns here 255). Is there somewhere a list of error codes to find ? General i noticed that the errorcodes are not divers enough so i had to rely on message strings. re, wh From matt at ucc.asn.au Thu May 18 23:02:09 2017 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 18 May 2017 23:02:09 +0800 Subject: Dropbear 2017.75 Message-ID: <20170518150209.GA30604@ucc.gu.uwa.edu.au> Hi all, Dropbear 2017.75 is released. This has a couple of security fixes and a couple of bug fixes since 2016.74. https://matt.ucc.asn.au/dropbear/dropbear.html I'm intending to make another release in the next couple of weeks including the various pending fixes in the Mercurial tree and pull requests. That's a bit more obtrusive with changes to options.h and #ifdef => #if. Cheers, Matt 2017.75 - 18 May 2017 - Security: Fix double-free in server TCP listener cleanup A double-free in the server could be triggered by an authenticated user if dropbear is running with -a (Allow connections to forwarded ports from any host) This could potentially allow arbitrary code execution as root by an authenticated user. Affects versions 2013.56 to 2016.74. Thanks to Mark Shepard for reporting the crash. - Security: Fix information disclosure with ~/.ssh/authorized_keys symlink. Dropbear parsed authorized_keys as root, even if it were a symlink. The fix is to switch to user permissions when opening authorized_keys A user could symlink their ~/.ssh/authorized_keys to a root-owned file they couldn't normally read. If they managed to get that file to contain valid authorized_keys with command= options it might be possible to read other contents of that file. This information disclosure is to an already authenticated user. Thanks to Jann Horn of Google Project Zero for reporting this. - Generate hostkeys with dropbearkey atomically and flush to disk with fsync Thanks to Andrei Gherzan for a patch - Fix out of tree builds with bundled libtom Thanks to Henrik Nordstr?m and Peter Krefting for patches. From Henrik.Uggla at kristianstad.se Fri May 19 15:42:21 2017 From: Henrik.Uggla at kristianstad.se (Henrik Uggla) Date: Fri, 19 May 2017 07:42:21 +0000 Subject: Restrictions for password logins Message-ID: <1495179741060.54029@kristianstad.se> Hi! How can I set restrictions, like those given in authorized_keys, to all password logins? regards HU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20170519/65abd56a/attachment.htm From guilhem at fripost.org Fri May 19 20:37:28 2017 From: guilhem at fripost.org (Guilhem Moulin) Date: Fri, 19 May 2017 14:37:28 +0200 Subject: Dropbear 2017.75 In-Reply-To: <20170518150209.GA30604@ucc.gu.uwa.edu.au> References: <20170518150209.GA30604@ucc.gu.uwa.edu.au> Message-ID: <20170519123727.deum76xna6q34qdn@localhost.localdomain> Hi Matt, On Thu, 18 May 2017 at 23:02:09 +0800, Matt Johnston wrote: > Dropbear 2017.75 is released. This has a couple of security > fixes and a couple of bug fixes since 2016.74. FYI https://matt.ucc.asn.au/dropbear/CHANGES yields 403 forbidden. > - Security: Fix double-free in server TCP listener cleanup > A double-free in the server could be triggered by an authenticated user if > dropbear is running with -a (Allow connections to forwarded ports from any host) > This could potentially allow arbitrary code execution as root by an authenticated user. > Affects versions 2013.56 to 2016.74. Thanks to Mark Shepard for reporting the crash. > > - Security: Fix information disclosure with ~/.ssh/authorized_keys symlink. > Dropbear parsed authorized_keys as root, even if it were a symlink. The fix > is to switch to user permissions when opening authorized_keys > > A user could symlink their ~/.ssh/authorized_keys to a root-owned file they > couldn't normally read. If they managed to get that file to contain valid > authorized_keys with command= options it might be possible to read other > contents of that file. > This information disclosure is to an already authenticated user. > Thanks to Jann Horn of Google Project Zero for reporting this. We're backporting these two to Debian Jessie (stable, soon to be oldstable). Did you already request CVE IDs? Cheers, -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20170519/c302775f/attachment.sig From wharms at bfs.de Fri May 19 20:42:32 2017 From: wharms at bfs.de (walter harms) Date: Fri, 19 May 2017 14:42:32 +0200 Subject: Restrictions for password logins In-Reply-To: <1495179741060.54029@kristianstad.se> References: <1495179741060.54029@kristianstad.se> Message-ID: <591EE838.9070602@bfs.de> Am 19.05.2017 09:42, schrieb Henrik Uggla: > Hi! > > > How can I set restrictions, like those given in authorized_keys, to all password logins? > > did you try the generalsetup at /etc/ssh/ssh_config ? re, wh > regards > > HU > From matt at ucc.asn.au Fri May 19 20:46:22 2017 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 19 May 2017 20:46:22 +0800 Subject: Restrictions for password logins In-Reply-To: <1495179741060.54029@kristianstad.se> References: <1495179741060.54029@kristianstad.se> Message-ID: <20170519124622.GB30604@ucc.gu.uwa.edu.au> On Fri, May 19, 2017 at 07:42:21AM +0000, Henrik Uggla wrote: > Hi! > > > How can I set restrictions, like those given in authorized_keys, to all password logins? Hi Henrik, You can't set all of those restrictions like command= though you can disable TCP forwarding at compile time in options.h What restrictions were you looking at? Cheers, Matt From matt at ucc.asn.au Fri May 19 21:26:24 2017 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 19 May 2017 21:26:24 +0800 Subject: Dropbear 2017.75 In-Reply-To: <20170519123727.deum76xna6q34qdn@localhost.localdomain> References: <20170518150209.GA30604@ucc.gu.uwa.edu.au> <20170519123727.deum76xna6q34qdn@localhost.localdomain> Message-ID: <20170519132624.GD30604@ucc.gu.uwa.edu.au> On Fri, May 19, 2017 at 02:37:28PM +0200, Guilhem Moulin wrote: > Hi Matt, > > On Thu, 18 May 2017 at 23:02:09 +0800, Matt Johnston wrote: > > Dropbear 2017.75 is released. This has a couple of security > > fixes and a couple of bug fixes since 2016.74. > > FYI https://matt.ucc.asn.au/dropbear/CHANGES yields 403 forbidden. Sorry missed this email before. Noticed it myself just now while requesting CVEs, I've fixed it. From Henrik.Uggla at kristianstad.se Fri May 19 22:34:03 2017 From: Henrik.Uggla at kristianstad.se (Henrik Uggla) Date: Fri, 19 May 2017 14:34:03 +0000 Subject: SV: Restrictions for password logins In-Reply-To: <20170519124622.GB30604@ucc.gu.uwa.edu.au> References: <1495179741060.54029@kristianstad.se>, <20170519124622.GB30604@ucc.gu.uwa.edu.au> Message-ID: <1495204443741.29103@kristianstad.se> Permission to run one command, everything else should be denied. /HU ________________________________________ Fr?n: Matt Johnston Skickat: den 19 maj 2017 14:46 Till: Henrik Uggla Kopia: dropbear at ucc.asn.au ?mne: Re: Restrictions for password logins On Fri, May 19, 2017 at 07:42:21AM +0000, Henrik Uggla wrote: > Hi! > > > How can I set restrictions, like those given in authorized_keys, to all password logins? Hi Henrik, You can't set all of those restrictions like command= though you can disable TCP forwarding at compile time in options.h What restrictions were you looking at? Cheers, Matt From wharms at bfs.de Fri May 19 23:00:39 2017 From: wharms at bfs.de (walter harms) Date: Fri, 19 May 2017 17:00:39 +0200 Subject: SV: Restrictions for password logins In-Reply-To: <1495204443741.29103@kristianstad.se> References: <1495179741060.54029@kristianstad.se>, <20170519124622.GB30604@ucc.gu.uwa.edu.au> <1495204443741.29103@kristianstad.se> Message-ID: <591F0897.1070002@bfs.de> Am 19.05.2017 16:34, schrieb Henrik Uggla: > Permission to run one command, everything else should be denied. why not modify .profile (or /bin/sh in /etc/profile) ? anything else feels complicated. re, wh > > /HU > ________________________________________ > Fr?n: Matt Johnston > Skickat: den 19 maj 2017 14:46 > Till: Henrik Uggla > Kopia: dropbear at ucc.asn.au > ?mne: Re: Restrictions for password logins > > On Fri, May 19, 2017 at 07:42:21AM +0000, Henrik Uggla wrote: >> Hi! >> >> >> How can I set restrictions, like those given in authorized_keys, to all password logins? > > Hi Henrik, > > You can't set all of those restrictions like command= though > you can disable TCP forwarding at compile time in options.h > > What restrictions were you looking at? > > Cheers, > Matt From Henrik.Uggla at kristianstad.se Sat May 20 20:17:19 2017 From: Henrik.Uggla at kristianstad.se (Henrik Uggla) Date: Sat, 20 May 2017 12:17:19 +0000 Subject: SV: SV: Restrictions for password logins In-Reply-To: <591F0897.1070002@bfs.de> References: <1495179741060.54029@kristianstad.se>, <20170519124622.GB30604@ucc.gu.uwa.edu.au> <1495204443741.29103@kristianstad.se>,<591F0897.1070002@bfs.de> Message-ID: <1495282638758.85346@kristianstad.se> Yes, that would probably work. Thanks. /HU ________________________________________ Fr?n: dropbear-bounces+henrik.uggla=kristianstad.se at ucc.asn.au f?r walter harms Skickat: den 19 maj 2017 17:00 Till: dropbear at ucc.asn.au ?mne: Re: SV: Restrictions for password logins Am 19.05.2017 16:34, schrieb Henrik Uggla: > Permission to run one command, everything else should be denied. why not modify .profile (or /bin/sh in /etc/profile) ? anything else feels complicated. re, wh > > /HU > ________________________________________ > Fr?n: Matt Johnston > Skickat: den 19 maj 2017 14:46 > Till: Henrik Uggla > Kopia: dropbear at ucc.asn.au > ?mne: Re: Restrictions for password logins > > On Fri, May 19, 2017 at 07:42:21AM +0000, Henrik Uggla wrote: >> Hi! >> >> >> How can I set restrictions, like those given in authorized_keys, to all password logins? > > Hi Henrik, > > You can't set all of those restrictions like command= though > you can disable TCP forwarding at compile time in options.h > > What restrictions were you looking at? > > Cheers, > Matt From wong.syrone at gmail.com Thu Jun 1 14:28:47 2017 From: wong.syrone at gmail.com (Syrone Wong) Date: Thu, 1 Jun 2017 14:28:47 +0800 Subject: OpenWrt/LEDE: dropbear & MIPS & gcc 7.1.0 Message-ID: Hi all, Recently, I upgrade my LEDE toolchain to binutils 2.28 & GCC 7, notice I cannot SSH to router. A more detailed description can be found (http://lists.infradead.org/pipermail/lede-dev/2017-May/007753.html), later, Kevin find it might related to libtommath (http://lists.infradead.org/pipermail/lede-dev/2017-May/007797.html). Two possible solution: i. change libtommath compilation flag from -Os to -O2: http://lists.infradead.org/pipermail/lede-dev/2017-May/007843.html ii. update the bundled libtom* to latest: http://lists.infradead.org/pipermail/lede-dev/2017-May/007849.html Please update the bundled libraries to latest, or help to find the root cause. Thanks in advance Best Regards, Syrone Wong From matt at ucc.asn.au Thu Jun 1 21:21:55 2017 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 1 Jun 2017 21:21:55 +0800 Subject: OpenWrt/LEDE: dropbear & MIPS & gcc 7.1.0 In-Reply-To: References: Message-ID: <2AA0D09B-4C5B-4AE6-BBF7-1573D95A1425@ucc.asn.au> Hi Syrone, Updating libtom makes sense, it's on the todo list. I'm curious if it's a bug in old libtommath or new gcc. In my experience differences between optimisation levels are more often problems with the compiler, but could be either. If you could get a backtrace of a stuck "dbclient" built with gcc 7 it might be useful to see what's going on (and to know where to look in the libtommath commit log) Cheers, Matt > On Thu 1/6/2017, at 2:28 pm, Syrone Wong wrote: > > Hi all, > > Recently, I upgrade my LEDE toolchain to binutils 2.28 & GCC 7, notice > I cannot SSH to router. > > A more detailed description can be found > (http://lists.infradead.org/pipermail/lede-dev/2017-May/007753.html), > later, Kevin find it might related to libtommath > (http://lists.infradead.org/pipermail/lede-dev/2017-May/007797.html). > > Two possible solution: > > i. change libtommath compilation flag from -Os to -O2: > http://lists.infradead.org/pipermail/lede-dev/2017-May/007843.html > > ii. update the bundled libtom* to latest: > http://lists.infradead.org/pipermail/lede-dev/2017-May/007849.html > > Please update the bundled libraries to latest, or help to find the root cause. > > Thanks in advance > > Best Regards, > Syrone Wong From wong.syrone at gmail.com Thu Jun 1 21:39:31 2017 From: wong.syrone at gmail.com (Syrone Wong) Date: Thu, 1 Jun 2017 21:39:31 +0800 Subject: OpenWrt/LEDE: dropbear & MIPS & gcc 7.1.0 In-Reply-To: <2AA0D09B-4C5B-4AE6-BBF7-1573D95A1425@ucc.asn.au> References: <2AA0D09B-4C5B-4AE6-BBF7-1573D95A1425@ucc.asn.au> Message-ID: Hi, I think it's a bug in libtommath. Compiling both 2017.75 and 2017.75 with updated libtom*, the latter one works while the original one doesn't. And for other parts, such as kernel, busybox, userspace programs, etc. , all of them are working perfectly. That's the reason why I think it isn't a compiler bug. Sorry, since I cannot access the router, which means I cannot execute any commands, it's not trivial to get the backtrace. Based on Kevin's report, > ssh -vvv' shows things hanging during the initial ECDH key exchange it might be something wrong with key verification, I'm not sure about it, totally wildly guess. You may want to contact Kevin off-list to know how he finds the issue resides in libtommath, I just follow his guess and replace libtom* to verify his idea. Kevin Darbyshire-Bryant Best Regards, Syrone Wong From horizn at wp.pl Thu Jun 8 23:52:48 2017 From: horizn at wp.pl (K K) Date: Thu, 08 Jun 2017 17:52:48 +0200 Subject: Force Dropbear to use only modern KEXes, MACs Message-ID: <593972d0d6b793.66379519@wp.pl> Hi, It is relatively easy in OpenSSH to setup support for only modern KEXes and MACs. Is it possible to run Dropbear with support only for modern/safe algorithms? If yes, how? brgds, From brent at mbari.org Sat Jun 24 09:31:16 2017 From: brent at mbari.org (Brent Roman) Date: Fri, 23 Jun 2017 18:31:16 -0700 Subject: RSA default key size of 2048 bits too large for low-spec systems Message-ID: I recently upgraded some low power ARM9 systems from dropbear v0.52 to v2017.75 Everything went well until a system system tried to generate server keys on first boot. Then it hung while working to generate the default 2048 bit RSA key. Further investigation determined that it had not really hung. Given many tens of minutes, it would complete the initial boot. Why did we decide to change the default to 2048 bit keys given the cost of generating these on the embedded systems for which it is intended to run? The #define for setting the default key size is currently in a .c file. Could this be moved to the options.h file with a comment recommending reducing the default size when targeting slow systems? Note, I do realize that there is a -s option for dropbearkey, but the appropriate values for that option are dependent on the key algorithm selected. I believe the defaults should always be usable. Dropbear is a great piece of Open Source software. I hope you'll consider this small change. - brent From matt at ucc.asn.au Sat Jun 24 11:02:41 2017 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 24 Jun 2017 11:02:41 +0800 Subject: RSA default key size of 2048 bits too large for low-spec systems In-Reply-To: References: Message-ID: Hi Brent, I'll see about improving the visibility of the default key sizes in options.h and also dropbearkey's printout. I changed to 2048 because 1024 is likely to become breakable within the next few years, it's best to have secure defaults if systems are going to remain un-updated for that timeframe. The change was never mentioned in the CHANGES for 2013.61test - sorry about that oversight, I've added it now. For a slow device maybe it'd be better to disable RSA and DSS altogether and just use ECDSA keys? Those are siginificantly faster and supported by all recent SSH implementations I know of (at least for desktops and servers). The newer "-R" option can also be used to generate keys on first connection - that might be fast enough with ECDSA. Cheers, Matt > On Sat 24/6/2017, at 9:31 am, Brent Roman wrote: > > I recently upgraded some low power ARM9 systems from dropbear v0.52 to v2017.75 > > Everything went well until a system system tried to generate server keys on first boot. > Then it hung while working to generate the default 2048 bit RSA key. > > Further investigation determined that it had not really hung. > Given many tens of minutes, it would complete the initial boot. > > Why did we decide to change the default to 2048 bit keys given the cost of generating these on the embedded systems for which it is intended to run? > > The #define for setting the default key size is currently in a .c file. > Could this be moved to the options.h file with a comment recommending reducing the default size when targeting slow systems? > > Note, I do realize that there is a -s option for dropbearkey, but the appropriate values for that option are dependent on the key algorithm selected. I believe the defaults should always be usable. > > Dropbear is a great piece of Open Source software. > > I hope you'll consider this small change. > > - brent > > > From brent at mbari.org Sat Jun 24 12:58:29 2017 From: brent at mbari.org (Brent Roman) Date: Fri, 23 Jun 2017 21:58:29 -0700 Subject: RSA default key size of 2048 bits too large for low-spec systems In-Reply-To: References: Message-ID: <8fff34d4-3370-6722-5693-88915c732336@mbari.org> Hi Matt, I like the -R option and am already using it to eliminate the need to generate keys on the initial system boot. However, I still generate a public/private key pair for each user the first time they log in. (which could delay that by many tens of minutes for the 2048 bit key) Maybe I should run the key generation in the background...Hmmm... ECDSA won't work so well here because of legacy systems (old OpenWRT routers) that don't support it. Thanks again, - brent On 06/23/2017 08:02 PM, Matt Johnston wrote: > Hi Brent, > > I'll see about improving the visibility of the default key sizes in options.h and also dropbearkey's printout. > I changed to 2048 because 1024 is likely to become breakable within the next few years, it's best to have secure defaults if systems are going to remain un-updated for that timeframe. > The change was never mentioned in the CHANGES for 2013.61test - sorry about that oversight, I've added it now. > > For a slow device maybe it'd be better to disable RSA and DSS altogether and just use ECDSA keys? Those are siginificantly faster and supported by all recent SSH implementations I know of (at least for desktops and servers). The newer "-R" option can also be used to generate keys on first connection - that might be fast enough with ECDSA. > > Cheers, > Matt > >> On Sat 24/6/2017, at 9:31 am, Brent Roman wrote: >> >> I recently upgraded some low power ARM9 systems from dropbear v0.52 to v2017.75 >> >> Everything went well until a system system tried to generate server keys on first boot. >> Then it hung while working to generate the default 2048 bit RSA key. >> >> Further investigation determined that it had not really hung. >> Given many tens of minutes, it would complete the initial boot. >> >> Why did we decide to change the default to 2048 bit keys given the cost of generating these on the embedded systems for which it is intended to run? >> >> The #define for setting the default key size is currently in a .c file. >> Could this be moved to the options.h file with a comment recommending reducing the default size when targeting slow systems? >> >> Note, I do realize that there is a -s option for dropbearkey, but the appropriate values for that option are dependent on the key algorithm selected. I believe the defaults should always be usable. >> >> Dropbear is a great piece of Open Source software. >> >> I hope you'll consider this small change. >> >> - brent >> >> >>