From ed.sutter at alcatel-lucent.com Mon Jan 4 21:07:23 2016 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Mon, 4 Jan 2016 08:07:23 -0500 Subject: Single-address space, no processes? In-Reply-To: <567AA21F.7090703@embedded-brains.de> References: <567AA21F.7090703@embedded-brains.de> Message-ID: <568A6E8B.6060901@alcatel-lucent.com> Sebastian, (sorry for the late reply) I ported dropbear SSH to uC/OS-I that used a sockets-api TCP/IP stack. Point being: it is certainly doable. Unfortunately, I can't release it, and I can tell you that it wasn't trivial; however, it is certainly doable. Ed > Hello, > > I would like to use SSH to do some remote administration for an > application running with the RTEMS real-time operating system. In this > environment we have no virtual memory and user and kernel space > separation. So this is like an application running in kernel mode > only. Is it in possible to use the dropbear SSH server in such an > environment? A quick grep showed that fork() is used for example to > spawn new processes. Would it be possible to spawn a new thread > instead (e.g. via pthread_create())? > From sebastian.huber at embedded-brains.de Mon Jan 4 21:18:34 2016 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Mon, 4 Jan 2016 14:18:34 +0100 Subject: Single-address space, no processes? In-Reply-To: <567AA21F.7090703@embedded-brains.de> References: <567AA21F.7090703@embedded-brains.de> Message-ID: <568A712A.8060705@embedded-brains.de> Hello, thanks for the hints. So, running dropbear in a single-address space and no process environment seems to be doable. However, it requires probably some possible large code modifications, e.g. * encapsulate the global state in a context structure and pass a pointer to this structure around, * add cleanup code instead of exit(). If I work on this, would it be possible to upstream these changes? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber at embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. From matt at ucc.asn.au Tue Jan 5 22:07:11 2016 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 5 Jan 2016 22:07:11 +0800 Subject: Single-address space, no processes? In-Reply-To: <568A712A.8060705@embedded-brains.de> References: <567AA21F.7090703@embedded-brains.de> <568A712A.8060705@embedded-brains.de> Message-ID: Hi Sebastian, I'd be interesting in merging changes upstream, I think it would be of interest to a few people. It would need to be under a similar license to the current code. Currently the session state is kept in ses, svr_ses, and cli_ses global variables (all structs defined in session.h). Changing eg ses.payload to ses->payload throughout the codebase is fairly straighforward. It mightn't be necessary to pass pointers around everywhere if ses/svr_ses/cli_ses could be thread-local pointer variables - how widely supported is thread-local storage? Some of the state in ses might need to move to a process-wide state structure - "childpids" for example. That mightn't be relevant for your situation. There is also some recent work to use Dropbear as a Perl module - that might have some useful changes in terms of avoiding Unix user authentication etc. https://github.com/atrodo/Net-Dropbear/tree/master/dropbear Cheers, Matt > On Mon 4/1/2016, at 9:18 pm, Sebastian Huber wrote: > > Hello, > > thanks for the hints. > > So, running dropbear in a single-address space and no process environment seems to be doable. However, it requires probably some possible large code modifications, e.g. > > * encapsulate the global state in a context structure and pass a pointer to this structure around, > * add cleanup code instead of exit(). > > If I work on this, would it be possible to upstream these changes? > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.huber at embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. > From jamie at shareable.org Fri Jan 8 02:32:43 2016 From: jamie at shareable.org (Jamie Lokier) Date: Thu, 7 Jan 2016 18:32:43 +0000 Subject: Single-address space, no processes? In-Reply-To: References: <567AA21F.7090703@embedded-brains.de> <568A712A.8060705@embedded-brains.de> Message-ID: <20160107183243.GF32300@jl-vm1.vm.bytemark.co.uk> Matt Johnston wrote: > It mightn't be necessary to pass pointers around everywhere if > ses/svr_ses/cli_ses could be thread-local pointer variables - how widely > supported is thread-local storage? If you can get a "current thread id" or set one "thread-local value", you can make thread-local variables in portable C using macros without compiler support. It's not as fast as compiler supported thread-local storage, but it's portable other than function to get the id, and provided you can set the value, it's not necessarily slow. Best, -- Jamie From mfwitten at gmail.com Tue Jan 12 00:37:09 2016 From: mfwitten at gmail.com (Michael Witten) Date: Mon, 11 Jan 2016 16:37:09 -0000 Subject: [PATCH 00/16] Improvements, mainly to user name handling and scp. Message-ID: <2666123da20b47a589b819f37bd4cc54-mfwitten@gmail.com> In-Reply-To<20151229150334.GB27198 at ucc.gu.uwa.edu.au> References: <20151229150334.GB27198 at ucc.gu.uwa.edu.au> On Tue, 29 Dec 2015 23:03:34 +0800, Matt Johnston wrote: > On Mon, Dec 07, 2015 at 10:42:59PM -0000, Michael Witten wrote: >> User names have hitherto been handled neither consistently nor well; this >> series alleviates at least some of the issues. >> >> Fear not the long patch series! >> >> Most commits involve a fairly small number of changes; while I could have >> consolidated these changes into fewer commits, I think the series as a whole >> provides a better narration for what's going. >> >> Besides a few small improvements along the way, the main thrust is: >> >> * Removing user-name handling from `scp' (in favor of using the >> handling that is already present in `dropbear'/`dbclient'). >> >> * Lazily looking up the current user's name. >> >> * Removing unused code. >> >> Overall, 7 files were changed, with 37 insertions(+) and 158 deletions(-): >> >> cli-main.c | 2 +- >> cli-runopts.c | 32 ++++++-------- >> common-session.c | 1 + >> runopts.h | 2 +- >> scp.c | 125 ++++++++++--------------------------------------------- >> scpmisc.c | 31 +------------- >> scpmisc.h | 2 - >> >> This is the series: >> >> [01] scp: Insert comma into stderr message >> [02] scp: Have `fatal()' append a newline to the message >> [03] scp: only pass `-v' when DEBUG_TRACE is set >> [04] scp: `-l%s' -> `-l %s' >> [05] scp: const/static correctness improvements >> [06] scp: Introduce `get_user_name()' >> [07] scp: Use "unknown" when the user name cannot be retrieved >> [08] scp: style: simplify code by using a tertiary operator >> [09] scp: Use `get_user_name()' more often >> [10] scp: Simplify code now that the user name is never `NULL' >> [11] scp: Remove parsing of `[user@]host' >> [12] scp: Remove unused functions >> [13] scp: Remove `replacearg()' >> [14] runopts: Mark `*cli_runopts.own_user' as `const' >> [15] runopts: There's no reason to make a duplicate of "unknown" >> [16] runopts: Re-introduce the `get_user_name()' function from `scp' development >> >> Lastly, for convenience in reviewing the changes, here is the overall patch: >> >> [ ... ] > > Hi Michael, > > I think the general change of these patches makes sense > (avoiding failure when a local user doesn't exist) but it > needs to be more minimal. scp comes straight from OpenSSH > with some small changes for uClinux etc. I've tried to > avoid additional changes since it really needs updating to a > more recent OpenSSH - the more changes, the larger that work > is. Upstreaming it might be an option. > > Cheers, > Matt Well, even if I go through the trouble of interfacing with this other community (OpenSSH), and thereby successfully introduce these changes 'upstream', it sounds like there's still going to be a lot of work to get the result merged 'downstream' as part of the project that I actually [and, yet, only marginally] care about (Dropbear SSH). This seems like it's going to be a waste of my time, and I've already spent a not-insignificant amount of time on this. My instinct is that we should view Dropbear's copies as being what they, in fact, are: forks with their own history and purpose. Yet, if that view is undesirable, then let's get this set straight now and for the rest of time: * Let's identify all the files that are viewed as being merely patched copies of 'upstream' files. * Let's segregate them obviously, and make clear notes (for the benefit of others) that all substantive changes should be made upstream. + Most portably, these files could be refactored into a subdirectory named 'upstream' or 'third-party'. It would be possible to account for DropBear-specific patches either explicitly (by applying them at build-time), or implicitly (by placing them in a specific branch that is merged with the main line of history via a non-fastforward merge commit). + Alternatively, these files could be included in at least one git submodule (or the mercurial equivalent); this submodule could then track the patches explicitly, and provide a focus for discussing Dropbear-specific patches and upstream synchronization. * Let's bring those 'upstream' copies up-to-date. Only after this effort, will it make sense to me to try to introduce my patches upstream in order to have them merged downstream. Sincerely, Michael Witten From mfwitten at gmail.com Tue Jan 12 00:37:09 2016 From: mfwitten at gmail.com (Michael Witten) Date: Mon, 11 Jan 2016 16:37:09 -0000 Subject: [PATCH 00/16] Improvements, mainly to user name handling and scp. In-Reply-To: <20151229150334.GB27198@ucc.gu.uwa.edu.au> References: <20151229150334.GB27198@ucc.gu.uwa.edu.au> Message-ID: On Tue, 29 Dec 2015 23:03:34 +0800, Matt Johnston wrote: > On Mon, Dec 07, 2015 at 10:42:59PM -0000, Michael Witten wrote: >> User names have hitherto been handled neither consistently nor well; this >> series alleviates at least some of the issues. >> >> Fear not the long patch series! >> >> Most commits involve a fairly small number of changes; while I could have >> consolidated these changes into fewer commits, I think the series as a whole >> provides a better narration for what's going. >> >> Besides a few small improvements along the way, the main thrust is: >> >> * Removing user-name handling from `scp' (in favor of using the >> handling that is already present in `dropbear'/`dbclient'). >> >> * Lazily looking up the current user's name. >> >> * Removing unused code. >> >> Overall, 7 files were changed, with 37 insertions(+) and 158 deletions(-): >> >> cli-main.c | 2 +- >> cli-runopts.c | 32 ++++++-------- >> common-session.c | 1 + >> runopts.h | 2 +- >> scp.c | 125 ++++++++++--------------------------------------------- >> scpmisc.c | 31 +------------- >> scpmisc.h | 2 - >> >> This is the series: >> >> [01] scp: Insert comma into stderr message >> [02] scp: Have `fatal()' append a newline to the message >> [03] scp: only pass `-v' when DEBUG_TRACE is set >> [04] scp: `-l%s' -> `-l %s' >> [05] scp: const/static correctness improvements >> [06] scp: Introduce `get_user_name()' >> [07] scp: Use "unknown" when the user name cannot be retrieved >> [08] scp: style: simplify code by using a tertiary operator >> [09] scp: Use `get_user_name()' more often >> [10] scp: Simplify code now that the user name is never `NULL' >> [11] scp: Remove parsing of `[user@]host' >> [12] scp: Remove unused functions >> [13] scp: Remove `replacearg()' >> [14] runopts: Mark `*cli_runopts.own_user' as `const' >> [15] runopts: There's no reason to make a duplicate of "unknown" >> [16] runopts: Re-introduce the `get_user_name()' function from `scp' development >> >> Lastly, for convenience in reviewing the changes, here is the overall patch: >> >> [ ... ] > > Hi Michael, > > I think the general change of these patches makes sense > (avoiding failure when a local user doesn't exist) but it > needs to be more minimal. scp comes straight from OpenSSH > with some small changes for uClinux etc. I've tried to > avoid additional changes since it really needs updating to a > more recent OpenSSH - the more changes, the larger that work > is. Upstreaming it might be an option. > > Cheers, > Matt Well, even if I go through the trouble of interfacing with this other community (OpenSSH), and thereby successfully introduce these changes 'upstream', it sounds like there's still going to be a lot of work to get the result merged 'downstream' as part of the project that I actually [and, yet, only marginally] care about (Dropbear SSH). This seems like it's going to be a waste of my time, and I've already spent a not-insignificant amount of time on this. My instinct is that we should view Dropbear's copies as being what they, in fact, are: forks with their own history and purpose. Yet, if that view is undesirable, then let's get this set straight now and for the rest of time: * Let's identify all the files that are viewed as being merely patched copies of 'upstream' files. * Let's segregate them obviously, and make clear notes (for the benefit of others) that all substantive changes should be made upstream. + Most portably, these files could be refactored into a subdirectory named 'upstream' or 'third-party'. It would be possible to account for DropBear-specific patches either explicitly (by applying them at build-time), or implicitly (by placing them in a specific branch that is merged with the main line of history via a non-fastforward merge commit). + Alternatively, these files could be included in at least one git submodule (or the mercurial equivalent); this submodule could then track the patches explicitly, and provide a focus for discussing Dropbear-specific patches and upstream synchronization. * Let's bring those 'upstream' copies up-to-date. Only after this effort, will it make sense to me to try to introduce my patches upstream in order to have them merged downstream. Sincerely, Michael Witten From mfwitten at gmail.com Tue Jan 12 01:05:34 2016 From: mfwitten at gmail.com (Michael Witten) Date: Mon, 11 Jan 2016 17:05:34 -0000 Subject: [PATCH 00/16] Improvements, mainly to user name handling and scp. In-Reply-To: <2666123da20b47a589b819f37bd4cc54-mfwitten@gmail.com> References: <20151229150334.GB27198@ucc.gu.uwa.edu.au> <2666123da20b47a589b819f37bd4cc54-mfwitten@gmail.com> Message-ID: <705832d05a9542209ba60db7567b2162-mfwitten@gmail.com> On Mon, 11 Jan 2016 16:37:09 -0000, Michael Witten wrote: > Message-ID: <2666123da20b47a589b819f37bd4cc54-mfwitten at gmail.com> > In-Reply-To<20151229150334.GB27198 at ucc.gu.uwa.edu.au> > References: > <20151229150334.GB27198 at ucc.gu.uwa.edu.au> Woops! I apologize for having sent a malformed email; you'll notice that the header 'In-Reply-To' is missing the colon. Please ignore that email, the one with the following Message-ID: <2666123da20b47a589b819f37bd4cc54-mfwitten at gmail.com> Instead, make replies to the email that has the following Message-ID: Terribly sorry, Michael Witten From matt at ucc.asn.au Tue Jan 19 00:45:27 2016 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 19 Jan 2016 00:45:27 +0800 Subject: [PATCH 00/16] Improvements, mainly to user name handling and scp. In-Reply-To: <2666123da20b47a589b819f37bd4cc54-mfwitten@gmail.com> References: <2666123da20b47a589b819f37bd4cc54-mfwitten@gmail.com> Message-ID: On Tue 12/1/2016, at 12:37 am, Michael Witten wrote: > Well, even if I go through the trouble of interfacing with this > other community (OpenSSH), and thereby successfully introduce > these changes 'upstream', it sounds like there's still going to > be a lot of work to get the result merged 'downstream' as > part of the project that I actually [and, yet, only marginally] > care about (Dropbear SSH). > > This seems like it's going to be a waste of my time, and I've > already spent a not-insignificant amount of time on this. > > My instinct is that we should view Dropbear's copies as being > what they, in fact, are: forks with their own history and > purpose. I've added a note at the top of the scp files. Even if changes are being stored in a more structured manner they would be best kept minimal - less things to think about. I've pushed a smaller change that should avoid scp requiring valid usernames. I've committed the newline for fatal(). I don't think the change to make cli-main/runopts use get_user_name() is worthwhile - it's easier to reason about program logic if everything is set up at startup rather than lazily evaluated. If it were a case where performance mattered it might be useful, not in this case. Cheers, Matt From sl-bay at orange.fr Tue Feb 9 06:25:19 2016 From: sl-bay at orange.fr (sl Bay) Date: Mon, 8 Feb 2016 23:25:19 +0100 (CET) Subject: How to force dbclient to use password authentication Message-ID: <1352235288.22777.1454970319345.JavaMail.www@wwinf1n20> Hi, ? Here my config, I have 3 NAS servers using dropbear version 2014.63 ? For development testing, I have 2 NAS using key authentication and the other only by using password (nas3). For this last one, there is no issue when I try to connect it directly by using Putty but I fail if I use dbclient from a TTY session opened on one of both other NAS servers (nas1 or nas2). ? Command used : export DROPBEAR_PASSWORD="xxxxxxxxxxxxxxxx" && dbclient -p 22 root at nas3 I found why. As I use also pageant, dbclient send the key loaded on pageant instead of using the password set in the shell variable. On the server side, I note an endless loop as /.ssh/authorized_keys does not exist and repeat this sequence : TRACE (8333): enter recv_msg_userauth_request TRACE (8333): enter checkusername TRACE (8333): shell is /bin/sh TRACE (8333): test shell is '/bin/sh' TRACE (8333): matching shell TRACE (8333): uid = 0 TRACE (8333): leave checkusername TRACE (8333): enter pubkeyauth TRACE (8333): enter checkpubkey TRACE (8333): enter checkpubkeyperms TRACE (8333): enter checkfileperm(/) TRACE (8333): leave checkfileperm: success TRACE (8333): enter checkfileperm(//.ssh) TRACE (8333): leave checkfileperm: success TRACE (8333): enter checkfileperm(//.ssh/authorized_keys) TRACE (8333): leave checkfileperm: stat() != 0 TRACE (8333): leave checkpubkeyperms TRACE (8333): bad authorized_keys permissions, or file doesn't exist TRACE (8333): leave checkpubkey: ret=-1 TRACE (8333): enter send_msg_userauth_failure So my issue, is there a way to force dbclient to use only password authentication ? Note: if I open by cascading sessions: from nas1 I open a session on nas2 and then if I try to open a session on nas3, I do not have this issue. ? best rgds ? Stephane ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20160208/93ea016f/attachment.htm From fry.kun at gmail.com Sat Feb 27 14:27:15 2016 From: fry.kun at gmail.com (Konstantin Svist) Date: Fri, 26 Feb 2016 22:27:15 -0800 Subject: Ed25519 support? Message-ID: <56D141C3.2050508@gmail.com> Hi, I'm curious if there are any plans to support Ed25519 keys/handshakes? Thanks, Konstantin From matt at ucc.asn.au Thu Mar 10 20:59:03 2016 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 10 Mar 2016 20:59:03 +0800 Subject: Dropbear 2016.72 Message-ID: <20160310125903.GN23300@ucc.gu.uwa.edu.au> Hi all, Dropbear SSH 2016.72 is released. This has a single change, a security fix. If X11 forwarding is enabled a user could bypass any "command=" restrictions in authorized_keys and run any command as their own user (or perform other operations allowed by the "xauth" binary such as writing files). It does not affect systems where command= restrictions are not used. As usual downloads are at https://matt.ucc.asn.au/dropbear/dropbear.html The patch is https://secure.ucc.asn.au/hg/dropbear/rev/a3e8389e01ff Cheers, Matt 2016.72 - 9 March 2016 - Validate X11 forwarding input. Could allow bypass of authorized_keys command= restrictions, found by github.com/tintinweb. Thanks to Damien Miller for a patch. From annulen at yandex.ru Sat Mar 12 03:45:45 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 11 Mar 2016 22:45:45 +0300 Subject: Dropbear 2016.72 In-Reply-To: <20160310125903.GN23300@ucc.gu.uwa.edu.au> References: <20160310125903.GN23300@ucc.gu.uwa.edu.au> Message-ID: <835601457725545@web9h.yandex.ru> 10.03.2016, 15:59, "Matt Johnston" : > Hi all, > > Dropbear SSH 2016.72 is released. This has a single change, a > security fix. If X11 forwarding is enabled a user could > bypass any "command=" restrictions in authorized_keys and run > any command as their own user (or perform other operations > allowed by the "xauth" binary such as writing files). It > does not affect systems where command= restrictions are not > used. > > As usual downloads are at https://matt.ucc.asn.au/dropbear/dropbear.html > > The patch is https://secure.ucc.asn.au/hg/dropbear/rev/a3e8389e01ff Hi Matt, Are you planning to make a release from master? Thanks! -- Regards, Konstantin From matt at ucc.asn.au Fri Mar 18 23:52:45 2016 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 18 Mar 2016 23:52:45 +0800 Subject: Dropbear 2016.73 Message-ID: <20160318155245.GO23300@ucc.gu.uwa.edu.au> Hi all, Dropbear 2016.73 is released. It has a few new features and other small improvements. Download at https://matt.ucc.asn.au/dropbear/dropbear.html Cheers, Matt 2016.73 - 18 March 2016 - Support syslog in dbclient, option -o usesyslog=yes. Patch from Konstantin Tokarev - Kill a proxycommand when dbclient exits, patch from Konstantin Tokarev - Option to exit when a TCP forward fails, patch from Konstantin Tokarev - New "-o" option parsing from Konstantin Tokarev. This allows handling some extra options in the style of OpenSSH, though implementing all OpenSSH options is not planned. - Fix crash when fallback initshells() is used, reported by Michael Nowak and Mike Tzou - Allow specifying commands eg "dropbearmulti dbclient ..." instead of symlinks - Various cleanups for issues found by a lint tool, patch from Francois Perrad - Fix tab indent consistency, patch from Francois Perrad - Fix issues found by cppcheck, reported by Mike Tzou - Use system memset_s() or explicit_bzero() if available to clear memory. Also make libtomcrypt/libtommath routines use that (or Dropbear's own m_burn()). - Prevent scp failing when the local user doesn't exist. Based on patch from Michael Witten. - Improved Travis CI test running, thanks to Mike Tzou - Improve some code that was flagged by Coverity and Fortify Static Code Analyzer From hans at atbas.org Sun Mar 20 18:05:48 2016 From: hans at atbas.org (Hans Harder) Date: Sun, 20 Mar 2016 11:05:48 +0100 Subject: Dropbear 2016.73 In-Reply-To: <20160318155245.GO23300@ucc.gu.uwa.edu.au> References: <20160318155245.GO23300@ucc.gu.uwa.edu.au> Message-ID: Hi Matt, noticed that in sysoptions.h this is added at line 130 /* These are disabled in Dropbear 2016.73 by default since the spec draft-ietf-curdle-ssh-kex-sha2-02 is under development. */ #define DROPBEAR_DH_GROUP14_256 0 #define DROPBEAR_DH_GROUP16 0 Should that not be in options.h underneath line 174 /* Group14 (2048 bit) is recommended. Group1 is less secure (1024 bit) though is the only option for interoperability with some older SSH programs */ #define DROPBEAR_DH_GROUP1 1 #define DROPBEAR_DH_GROUP14 1 Hans On Fri, Mar 18, 2016 at 4:52 PM, Matt Johnston wrote: > Hi all, > > Dropbear 2016.73 is released. It has a few new features and > other small improvements. > > Download at https://matt.ucc.asn.au/dropbear/dropbear.html > > Cheers, > Matt > > 2016.73 - 18 March 2016 > > - Support syslog in dbclient, option -o usesyslog=yes. Patch from > Konstantin Tokarev > > - Kill a proxycommand when dbclient exits, patch from Konstantin Tokarev > > - Option to exit when a TCP forward fails, patch from Konstantin Tokarev > > - New "-o" option parsing from Konstantin Tokarev. This allows handling > some extra options > in the style of OpenSSH, though implementing all OpenSSH options is not > planned. > > - Fix crash when fallback initshells() is used, reported by Michael Nowak > and Mike Tzou > > - Allow specifying commands eg "dropbearmulti dbclient ..." instead of > symlinks > > - Various cleanups for issues found by a lint tool, patch from Francois > Perrad > > - Fix tab indent consistency, patch from Francois Perrad > > - Fix issues found by cppcheck, reported by Mike Tzou > > - Use system memset_s() or explicit_bzero() if available to clear memory. > Also make > libtomcrypt/libtommath routines use that (or Dropbear's own m_burn()). > > - Prevent scp failing when the local user doesn't exist. Based on patch > from Michael Witten. > > - Improved Travis CI test running, thanks to Mike Tzou > > - Improve some code that was flagged by Coverity and Fortify Static Code > Analyzer > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20160320/2f3f578c/attachment.htm From matt at ucc.asn.au Sun Mar 20 22:57:27 2016 From: matt at ucc.asn.au (Matt Johnston) Date: Sun, 20 Mar 2016 22:57:27 +0800 Subject: Dropbear 2016.73 In-Reply-To: References: <20160318155245.GO23300@ucc.gu.uwa.edu.au> Message-ID: <20160320145727.GP23300@ucc.gu.uwa.edu.au> Hi Hans, sysoptions.h is intentional, those options haven't been tested enough to make them readily accessible. sysoptions.h's warning applies: * You shouldn't edit this file unless you know you need to. When the draft was proposing group14-256 and group16-256 I tested against OpenSSH [1], but the spec has now moved to group16-sha512. Hopefully they should be ready in the next Dropbear release, also with the ability to disable sha1 in other place it is used. Cheers, Matt [1] https://bugzilla.mindrot.org/show_bug.cgi?id=2515 On Sun, Mar 20, 2016 at 11:05:48AM +0100, Hans Harder wrote: > Hi Matt, > > noticed that in sysoptions.h this is added at line 130 > > /* These are disabled in Dropbear 2016.73 by default since the spec > draft-ietf-curdle-ssh-kex-sha2-02 is under development. */ > #define DROPBEAR_DH_GROUP14_256 0 > #define DROPBEAR_DH_GROUP16 0 > > > Should that not be in options.h underneath line 174 > > /* Group14 (2048 bit) is recommended. Group1 is less secure (1024 bit) > though > is the only option for interoperability with some older SSH programs */ > #define DROPBEAR_DH_GROUP1 1 > #define DROPBEAR_DH_GROUP14 1 > > > Hans > > > > > > > On Fri, Mar 18, 2016 at 4:52 PM, Matt Johnston wrote: > > > Hi all, > > > > Dropbear 2016.73 is released. It has a few new features and > > other small improvements. > > > > Download at https://matt.ucc.asn.au/dropbear/dropbear.html > > > > Cheers, > > Matt > > > > 2016.73 - 18 March 2016 > > > > - Support syslog in dbclient, option -o usesyslog=yes. Patch from > > Konstantin Tokarev > > > > - Kill a proxycommand when dbclient exits, patch from Konstantin Tokarev > > > > - Option to exit when a TCP forward fails, patch from Konstantin Tokarev > > > > - New "-o" option parsing from Konstantin Tokarev. This allows handling > > some extra options > > in the style of OpenSSH, though implementing all OpenSSH options is not > > planned. > > > > - Fix crash when fallback initshells() is used, reported by Michael Nowak > > and Mike Tzou > > > > - Allow specifying commands eg "dropbearmulti dbclient ..." instead of > > symlinks > > > > - Various cleanups for issues found by a lint tool, patch from Francois > > Perrad > > > > - Fix tab indent consistency, patch from Francois Perrad > > > > - Fix issues found by cppcheck, reported by Mike Tzou > > > > - Use system memset_s() or explicit_bzero() if available to clear memory. > > Also make > > libtomcrypt/libtommath routines use that (or Dropbear's own m_burn()). > > > > - Prevent scp failing when the local user doesn't exist. Based on patch > > from Michael Witten. > > > > - Improved Travis CI test running, thanks to Mike Tzou > > > > - Improve some code that was flagged by Coverity and Fortify Static Code > > Analyzer > >