From matt at ucc.asn.au Mon Apr 1 23:01:42 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 1 Apr 2013 23:01:42 +0800 Subject: Timeout dead connections In-Reply-To: <20130328112455.GG28516@ucc.gu.uwa.edu.au> References: <51530F2B.1060907@westermo.se> <20130327154751.GD28516@ucc.gu.uwa.edu.au> <515405A2.2010707@westermo.se> <20130328112455.GG28516@ucc.gu.uwa.edu.au> Message-ID: <20130401150142.GJ28516@ucc.gu.uwa.edu.au> 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.walstrom at 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 > > >>> > > From matt at ucc.asn.au Mon Apr 1 23:03:27 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 1 Apr 2013 23:03:27 +0800 Subject: Timeout dead connections In-Reply-To: <20130401150142.GJ28516@ucc.gu.uwa.edu.au> References: <51530F2B.1060907@westermo.se> <20130327154751.GD28516@ucc.gu.uwa.edu.au> <515405A2.2010707@westermo.se> <20130328112455.GG28516@ucc.gu.uwa.edu.au> <20130401150142.GJ28516@ucc.gu.uwa.edu.au> Message-ID: <20130401150327.GK28516@ucc.gu.uwa.edu.au> 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.walstrom at 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 > > > >>> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: utmp-exit-cleanup-2013.56.diff Type: text/x-diff Size: 3653 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130401/3cd14d9a/attachment.diff From scase at vccs.edu Tue Apr 2 10:35:10 2013 From: scase at vccs.edu (Scott Case) Date: Mon, 1 Apr 2013 22:35:10 -0400 Subject: segfault RH EL5 /dev/urandom read-only Message-ID: <89EE86E7253448479891C016A240A69601782C2F@fs00949.vccs.edu> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130401/f5fd172a/attachment.htm From matt at ucc.asn.au Tue Apr 2 18:57:05 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 02 Apr 2013 18:57:05 +0800 Subject: segfault RH EL5 /dev/urandom read-only In-Reply-To: <89EE86E7253448479891C016A240A69601782C2F@fs00949.vccs.edu> References: <89EE86E7253448479891C016A240A69601782C2F@fs00949.vccs.edu> Message-ID: <862c4ac4-e0fb-4f8b-a1fd-45b66125a0e5@email.android.com> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130402/cdddb051/attachment.htm From ed.sutter at alcatel-lucent.com Fri Apr 5 06:07:15 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Thu, 04 Apr 2013 18:07:15 -0400 Subject: embedded dropbear... Message-ID: <515DF993.4080907@alcatel-lucent.com> Hi, I'm taking a shot at porting the ssh server portion of this package to a non-posix multitasking RTOS on a CPU running ~500Mhz. I've made reasonable progress, but now I'm stumbling on an error coming out of gen_kexdh_vals()... The call to mp_exptmod() does not return MP_OKAY; hence dropbear_exit() is called. I'm currently building this with GCC for a PPC405. This is a 32-bit core in big-endian mode. I defined LTC_NO_ASM to disable anything that's not portable, but that didn't seem to make a difference. Any thoughts on what might be causing this? Thanks in advance, Ed BTW... Minor point: this function (gen_kexdh_vals()) has the wrong TRACE() text at the top... TRACE(("enter send_msg_kexdh_reply")) From mattias.walstrom at westermo.se Fri Apr 5 16:25:49 2013 From: mattias.walstrom at westermo.se (=?ISO-8859-1?Q?Mattias_Walstr=F6m?=) Date: Fri, 05 Apr 2013 10:25:49 +0200 Subject: Timeout dead connections In-Reply-To: <20130401150142.GJ28516@ucc.gu.uwa.edu.au> References: <51530F2B.1060907@westermo.se> <20130327154751.GD28516@ucc.gu.uwa.edu.au> <515405A2.2010707@westermo.se> <20130328112455.GG28516@ucc.gu.uwa.edu.au> <20130401150142.GJ28516@ucc.gu.uwa.edu.au> Message-ID: <515E8A8D.3050300@westermo.se> 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.walstrom at 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 >>>>>> >>> From matt at ucc.asn.au Fri Apr 5 19:18:26 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 05 Apr 2013 19:18:26 +0800 Subject: Timeout dead connections In-Reply-To: <515E8A8D.3050300@westermo.se> References: <51530F2B.1060907@westermo.se> <20130327154751.GD28516@ucc.gu.uwa.edu.au> <515405A2.2010707@westermo.se> <20130328112455.GG28516@ucc.gu.uwa.edu.au> <20130401150142.GJ28516@ucc.gu.uwa.edu.au> <515E8A8D.3050300@westermo.se> Message-ID: 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.walstrom at 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 >>>>>>> >>>> From roytam at gmail.com Fri Apr 5 20:03:02 2013 From: roytam at gmail.com (Roy Tam) Date: Fri, 5 Apr 2013 20:03:02 +0800 Subject: Timeout dead connections In-Reply-To: References: <51530F2B.1060907@westermo.se> <20130327154751.GD28516@ucc.gu.uwa.edu.au> <515405A2.2010707@westermo.se> <20130328112455.GG28516@ucc.gu.uwa.edu.au> <20130401150142.GJ28516@ucc.gu.uwa.edu.au> <515E8A8D.3050300@westermo.se> Message-ID: 2013/4/5 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. I got same issue with 2012.55-1.3 at 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. > > 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.walstrom at 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 >>>>>>>> >>>>> > From matt at ucc.asn.au Fri Apr 5 21:29:07 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 05 Apr 2013 21:29:07 +0800 Subject: Timeout dead connections In-Reply-To: References: <51530F2B.1060907@westermo.se> <20130327154751.GD28516@ucc.gu.uwa.edu.au> <515405A2.2010707@westermo.se> <20130328112455.GG28516@ucc.gu.uwa.edu.au> <20130401150142.GJ28516@ucc.gu.uwa.edu.au> <515E8A8D.3050300@westermo.se> Message-ID: Roy Tam wrote: >I got same issue with 2012.55-1.3 at 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.walstrom at 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 >>>>>>>>> >>>>>> >> From roytam at gmail.com Fri Apr 5 21:47:38 2013 From: roytam at gmail.com (Roy Tam) Date: Fri, 5 Apr 2013 21:47:38 +0800 Subject: Timeout dead connections In-Reply-To: References: <51530F2B.1060907@westermo.se> <20130327154751.GD28516@ucc.gu.uwa.edu.au> <515405A2.2010707@westermo.se> <20130328112455.GG28516@ucc.gu.uwa.edu.au> <20130401150142.GJ28516@ucc.gu.uwa.edu.au> <515E8A8D.3050300@westermo.se> Message-ID: 2013/4/5 Matt Johnston : > > > Roy Tam wrote: >>I got same issue with 2012.55-1.3 at 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 I tried "dpkg-buildpackage -rfakeroot" dropbear-2013.56 and installed dropbear_2013.56-0.1_i386.deb restarted dropbear services, open 2 putty connection to that host, and press [X] button on one of them, then run "w" on another one, it show 2 sessions. In "ps auxww", it shows 3 lines of: /usr/sbin/dropbear -d /etc/dropbear/dropbear_dss_host_key -r /etc/dropbear/dropbear_rsa_host_key -p 22 -W 65536 So, the problem still exists. > > 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.walstrom at 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 >>>>>>>>>> >>>>>>> >>> > From mattias.walstrom at westermo.se Fri Apr 5 21:52:42 2013 From: mattias.walstrom at westermo.se (=?UTF-8?B?TWF0dGlhcyBXYWxzdHLDtm0=?=) Date: Fri, 05 Apr 2013 15:52:42 +0200 Subject: Timeout dead connections In-Reply-To: References: <51530F2B.1060907@westermo.se> <20130327154751.GD28516@ucc.gu.uwa.edu.au> <515405A2.2010707@westermo.se> <20130328112455.GG28516@ucc.gu.uwa.edu.au> <20130401150142.GJ28516@ucc.gu.uwa.edu.au> <515E8A8D.3050300@westermo.se> Message-ID: <515ED72A.7020400@westermo.se> I am not using Keepalive. Why is keepalive required? If reading the manual understood that was to make sure firewalls did not close the connection. Shouldn't a TCP socket timeout in maximum 15 minutes by itself? Mattias On 2013-04-05 13:18, Matt Johnston wrote: > 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.walstrom at 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 >>>>>>>> >>>>> > From mattias.walstrom at westermo.se Fri Apr 5 22:03:05 2013 From: mattias.walstrom at westermo.se (=?UTF-8?B?TWF0dGlhcyBXYWxzdHLDtm0=?=) Date: Fri, 05 Apr 2013 16:03:05 +0200 Subject: Timeout dead connections In-Reply-To: <515ED72A.7020400@westermo.se> References: <51530F2B.1060907@westermo.se> <20130327154751.GD28516@ucc.gu.uwa.edu.au> <515405A2.2010707@westermo.se> <20130328112455.GG28516@ucc.gu.uwa.edu.au> <20130401150142.GJ28516@ucc.gu.uwa.edu.au> <515E8A8D.3050300@westermo.se> <515ED72A.7020400@westermo.se> Message-ID: <515ED999.1080900@westermo.se> Actually.. when I looked at it again. My first session has been closed, it took some while, but at last it seems like it was closed. I just read more about TCP timeouts, must have mixed things up. It is rather long, but it seems that dropbear now clean upp after itself. Now in who, I can see that my first entry (made Apr 5 07:24:09) is now removed. admin pts/0 00:00 Apr 5 15:56:06 y.y.y.y admin pts/1 05:39 Apr 5 09:39:05 y.y.y.y admin pts/2 03:05 Apr 5 12:52:47 y.y.y.y Mattias On 2013-04-05 15:52, Mattias Walstr?m wrote: > I am not using Keepalive. Why is keepalive required? If reading the manual understood that was to make sure firewalls did not close the connection. > > Shouldn't a TCP socket timeout in maximum 15 minutes by itself? > > Mattias > > > On 2013-04-05 13:18, Matt Johnston wrote: >> 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.walstrom at 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 >>>>>>>>> >>>>>> >> > From hans at atbas.org Sun Apr 7 22:03:37 2013 From: hans at atbas.org (Hans Harder) Date: Sun, 7 Apr 2013 16:03:37 +0200 Subject: Patch for stricthostkey and a multihop fix Message-ID: 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 correctly....if 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.000000000 -0700 +++ work/cli-kex.c 2013-04-07 03:01:31.000000000 -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.000000000 -0700 +++ work/cli-runopts.c 2013-04-07 03:08:59.000000000 -0600 @@ -62,6 +62,7 @@ static void printhelp() { "-N Don't run a remote command\n" "-f Run in background after auth\n" "-y Always accept remote host key if unknown\n" + "-Y Always ignore the remote host key\n" "-s Request 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 written = snprintf(ret+total, size, "-i %s ", key->filename); dropbear_assert((unsigned int)written < size); total += written; } - + + /* if args where passed, total will be not zero, and it will have a space at the end, so remove that */ + if (total) total--; + + /* make sure arg string is ended, especially if no args were passed. */ + ret[total]='\0'; + return ret; } diff -ruBpN dropbear-2013.56/runopts.h work/runopts.h --- dropbear-2013.56/runopts.h 2013-03-21 08:29:35.000000000 -0700 +++ work/runopts.h 2013-04-07 01:55:25.000000000 -0700 @@ -121,6 +121,7 @@ typedef struct cli_runopts { char *cmd; int wantpty; int always_accept_key; + int strict_hostkey; int no_cmd; int backgrounded; int is_subsystem; From matt at ucc.asn.au Thu Apr 11 08:16:01 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 11 Apr 2013 08:16:01 +0800 Subject: Patch for stricthostkey and a multihop fix In-Reply-To: References: Message-ID: <20130411001600.GA28516@ucc.gu.uwa.edu.au> 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 > correctly....if 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.000000000 -0700 > +++ work/cli-kex.c 2013-04-07 03:01:31.000000000 -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.000000000 -0700 > +++ work/cli-runopts.c 2013-04-07 03:08:59.000000000 -0600 > @@ -62,6 +62,7 @@ static void printhelp() { > "-N Don't run a remote command\n" > "-f Run in background after auth\n" > "-y Always accept remote > host key if unknown\n" > + "-Y Always ignore the > remote host key\n" > "-s Request 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 written = snprintf(ret+total, size, "-i %s ", > key->filename); > dropbear_assert((unsigned int)written < size); > total += written; > } > - > + > + /* if args where passed, total will be not zero, and it will > have a space at the end, so remove that */ > + if (total) total--; > + > + /* make sure arg string is ended, especially if no args were passed. */ > + ret[total]='\0'; > + > return ret; > } > > diff -ruBpN dropbear-2013.56/runopts.h work/runopts.h > --- dropbear-2013.56/runopts.h 2013-03-21 08:29:35.000000000 -0700 > +++ work/runopts.h 2013-04-07 01:55:25.000000000 -0700 > @@ -121,6 +121,7 @@ typedef struct cli_runopts { > char *cmd; > int wantpty; > int always_accept_key; > + int strict_hostkey; > int no_cmd; > int backgrounded; > int is_subsystem; From heehooman at gmail.com Thu Apr 11 15:26:08 2013 From: heehooman at gmail.com (hhm) Date: Thu, 11 Apr 2013 03:26:08 -0400 Subject: [PATCH] add dropbearmulti arg1 support Message-ID: This patch adds support for calling dropbearmulti with a program name as its *first* parameter. This enables use of dropbearmulti without any symlinks. The following are examples of where this can be useful: 1) on file systems which do not support symlinks (FAT for example) 2) for convenience; needing only one file Enjoy ============================= diff -u a/dbmulti.c b/dbmulti.c --- a/dbmulti.c +++ b/dbmulti.c @@ -33,10 +33,33 @@ int main(int argc, char ** argv) { char * progname; +#ifdef DROPBEARMULTI_ARG1 + int arg1; +#endif - if (argc > 0) { - /* figure which form we're being called as */ - progname = basename(argv[0]); + if (argc > 0 +#ifdef DROPBEARMULTI_ARG1 + || argc < 0 +#endif + ) { +#ifdef DROPBEARMULTI_ARG1 + if (argc > 0) { + arg1 = 0; +#endif + /* figure which form we're being called as */ + progname = basename(argv[0]); +#ifdef DROPBEARMULTI_ARG1 + } else { + char buf[64]; + arg1 = -1; + progname = argv[1]; + snprintf(buf, sizeof buf, "%s %s", argv[0], progname); /* this appears in usages, maybe should just use original argv0 if needed by a sub-program */ + argv[1] = buf; /* new argv[0] */ + argv += 1; + argc = -argc; /* restore argc to pre-signaling state */ + argc -= 1; + } +#endif #ifdef DBMULTI_dropbear if (strcmp(progname, "dropbear") == 0) { @@ -66,8 +89,19 @@ #endif } +#ifdef DROPBEARMULTI_ARG1 + if (!arg1 && argc > 1) { /* matched none of the prognames, has args on cmdline */ + argc = -argc; /* negate argc as signal */ + return main(argc, argv); + } +#endif + fprintf(stderr, "Dropbear SSH multi-purpose v%s\n" - "Make a symlink pointing at this binary with one of the following names:\n" + "Make a symlink pointing at this binary" +#ifdef DROPBEARMULTI_ARG1 + ", or pass a name to it as the first parameter," +#endif + " with one of the following names:\n" #ifdef DBMULTI_dropbear "'dropbear' - the Dropbear server\n" #endif diff -u a/MULTI b/MULTI --- a/MULTI +++ b/MULTI @@ -21,6 +21,12 @@ ./dropbear +Alternatively, call dropbearmulti with the name of an executable as its first argument (if this option was chosen): + +./dropbearmulti dropbear +./dropbearmulti dbclient +etc + "make install" doesn't currently work for multi-binary configuration, though in most situations where it is being used, the target and build systems will differ. diff -u a/options.h b/options.h --- a/options.h +++ b/options.h @@ -14,6 +14,11 @@ #define DROPBEAR_DEFPORT "22" #endif +#ifndef DROPBEARMULTI_ARG1 +/* Dropbearmulti program invocation via argv1 */ +#define DROPBEARMULTI_ARG1 +#endif + #ifndef DROPBEAR_DEFADDRESS /* Listen on all interfaces */ #define DROPBEAR_DEFADDRESS "" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130411/87ecb123/attachment.htm From hans at atbas.org Fri Apr 12 02:08:42 2013 From: hans at atbas.org (Hans Harder) Date: Thu, 11 Apr 2013 20:08:42 +0200 Subject: Patch for stricthostkey and a multihop fix In-Reply-To: <20130411001600.GA28516@ucc.gu.uwa.edu.au> References: <20130411001600.GA28516@ucc.gu.uwa.edu.au> Message-ID: Hi Matt, No problem, that solution is even better.... I was also thinking about another option for hostkey checking One of the problems I have with logical hostnames, is that you get a selected number of different hostkeys back. On a 2 node cluster I can get 2 different hostkeys for the same logical hostname. So it would be nice to have a way that I can say that it should not abort on the 1st hostname match if the key does not match, but continue to look for a matching hostname AND hostkey. Any ideas on how we could still use a hostkey check with that, instead of being forced to ignore them ? I was thinking about parsing the known_hosts until a match was done with the hostname AND the hostkey So not aborting if the first hostkey of a hostname did not match. Should not be to difficult in making a patch for that... Its more difficult to think of a way of how a user would provide that on the cmdline... Something else....the TODO file is not up to date... I took a look to see if I could help out with something, and I saw the authorized_keys restrictions.... But you already done that :) Cheers, Hans On Thu, Apr 11, 2013 at 2:16 AM, Matt Johnston wrote: > 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 >> correctly....if 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.000000000 -0700 >> +++ work/cli-kex.c 2013-04-07 03:01:31.000000000 -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.000000000 -0700 >> +++ work/cli-runopts.c 2013-04-07 03:08:59.000000000 -0600 >> @@ -62,6 +62,7 @@ static void printhelp() { >> "-N Don't run a remote command\n" >> "-f Run in background after auth\n" >> "-y Always accept remote >> host key if unknown\n" >> + "-Y Always ignore the >> remote host key\n" >> "-s Request 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 written = snprintf(ret+total, size, "-i %s ", >> key->filename); >> dropbear_assert((unsigned int)written < size); >> total += written; >> } >> - >> + >> + /* if args where passed, total will be not zero, and it will >> have a space at the end, so remove that */ >> + if (total) total--; >> + >> + /* make sure arg string is ended, especially if no args were passed. */ >> + ret[total]='\0'; >> + >> return ret; >> } >> >> diff -ruBpN dropbear-2013.56/runopts.h work/runopts.h >> --- dropbear-2013.56/runopts.h 2013-03-21 08:29:35.000000000 -0700 >> +++ work/runopts.h 2013-04-07 01:55:25.000000000 -0700 >> @@ -121,6 +121,7 @@ typedef struct cli_runopts { >> char *cmd; >> int wantpty; >> int always_accept_key; >> + int strict_hostkey; >> int no_cmd; >> int backgrounded; >> int is_subsystem; From rob at landley.net Fri Apr 12 02:00:33 2013 From: rob at landley.net (Rob Landley) Date: Thu, 11 Apr 2013 13:00:33 -0500 Subject: [PATCH] add dropbearmulti arg1 support In-Reply-To: (from heehooman@gmail.com on Thu Apr 11 02:26:08 2013) References: Message-ID: <1365703233.18069.81@driftwood> On 04/11/2013 02:26:08 AM, hhm wrote: > This patch adds support for calling dropbearmulti with a program name > as > its *first* parameter. > > This enables use of dropbearmulti without any symlinks. The following > are > examples of where this can be useful: > 1) on file systems which do not support symlinks (FAT for example) > 2) for convenience; needing only one file mv dropbearmulti ssh Rob From ed.sutter at alcatel-lucent.com Fri Apr 12 05:56:54 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Thu, 11 Apr 2013 17:56:54 -0400 Subject: embedded dropbear Message-ID: <516731A6.6090105@alcatel-lucent.com> Hi, I managed to get dropbear-ssh running under a uC/OS-II thread. Obviously had to do a lot of hacking to make this work, and I'm sure its not the most efficient way of doing it. Not being an ssh/cryptography wizard by any stretch of the imagination, I have two questions that may be trivial... 1.. Because I'm not on a Unix-ish system, I don't have any of the /proc stuff or /dev/urandom for seedrandom(). Is it essential that this function have *that* much random input? How does this affect the security of the connection? 2.. I essentially hard-coded the -r option (ssh server) to use a pre-established rsa_host_key file. Should this file be built once for a given system, and then reused or is this something that should be recreated each time the server is started? Thanks in advance, Ed From rob at landley.net Fri Apr 12 06:30:44 2013 From: rob at landley.net (Rob Landley) Date: Thu, 11 Apr 2013 17:30:44 -0500 Subject: embedded dropbear In-Reply-To: <516731A6.6090105@alcatel-lucent.com> (from ed.sutter@alcatel-lucent.com on Thu Apr 11 16:56:54 2013) Message-ID: <1365719444.18069.90@driftwood> On 04/11/2013 04:56:54 PM, Ed Sutter wrote: > Hi, > I managed to get dropbear-ssh running under a uC/OS-II thread. > Obviously had to do a lot of hacking to make this work, and > I'm sure its not the most efficient way of doing it. > > Not being an ssh/cryptography wizard by any stretch of the > imagination, I have two questions that may be trivial... > > 1.. > Because I'm not on a Unix-ish system, I don't have any of > the /proc stuff or /dev/urandom for seedrandom(). Is it > essential that this function have *that* much random > input? How does this affect the security of the connection? If you can predict the random seed, you can decrypt the entire connection. All the other cryptography is based on exchanging unguessable numbers in both directions. Public key cryptography does a one-way mathematical trick on a really big number to split it into two smaller numbers, so that each one is the antidote to the other's poison. You scramble a message with one, you need the OTHER to unscramble it. (You can't undo it with the one that created it, that's the clever bit.) You keep one of this pair of numbers secret (doesn't matter which, they're symmetrical) as your private key and give the other out as your public key. Anybody can use your public key to send you a message which only you can read with your private key. And anyone can read messages you send with your private key but only you could have sent them. So in one direction it provides authentication, in the other it provides privacy. When you want a bidirectional connection providing both, each side produces a pair of of keys (four keys total), then exchanges one and keeps the other. Then you encrypt each packet TWICE, with your private key and with the other guy's public key. At the other end they decrypt with your public key (so the message could only have been created with your private key, so it came from you) and their own private key (so only they can read it). Doesn't matter what order the two encryption/decryptions occur in as long as both sides agree. Public key cryptography is really computationally expensive (I.E. slow) so what they do is exchange symmetrical keys with it, which are another unguessable secret number that's much faster to use, but which requires both sides to know the _same_ unguessable secret. (The poison is its own antidote, the key that encrypted is also the key that undoes it. Simpler/faster math that way, but it means you need an established relationship to use it.) The rest of the connection is then encrypted with the symmetric keys. (Well, it generates and exchanges fresh symmetric keys every once in a while so that listeners won't have TOO much of the same kind of data to try various clever attacks with to guess that key.) The public key cryptography is just used to establish and verify the connection at the start. > 2.. > I essentially hard-coded the -r option (ssh server) to use a > pre-established rsa_host_key file. Should this file be built > once for a given system, and then reused or is this something > that should be recreated each time the server is started? The host key uniquely identifies the host. It's what gives you the "host key has changed!" warning when somebody reinstalls the server. Otherwise, anybody could intercept the connection, insert their own ssh server, have you log into it, forward the credentials use use to the other server to log into that, and pass data through in both directions while logging all of it. This is called a "man in the middle" attack, and you prevent it by giving each server a unique way to identify itself that only itknows. (Basically you encrypt a packet at it using its public key, and it decrypts it using its private key and sends back the correct response based on its contents.) And that's cryptography 101. :) Rob From ed.sutter at alcatel-lucent.com Fri Apr 12 19:59:50 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Fri, 12 Apr 2013 07:59:50 -0400 Subject: embedded dropbear In-Reply-To: <1365719444.18069.90@driftwood> References: <1365719444.18069.90@driftwood> Message-ID: <5167F736.8050800@alcatel-lucent.com> Great explanation Rob, Thanks much.. Ed > On 04/11/2013 04:56:54 PM, Ed Sutter wrote: >> Hi, >> I managed to get dropbear-ssh running under a uC/OS-II thread. >> Obviously had to do a lot of hacking to make this work, and >> I'm sure its not the most efficient way of doing it. >> >> Not being an ssh/cryptography wizard by any stretch of the >> imagination, I have two questions that may be trivial... >> >> 1.. >> Because I'm not on a Unix-ish system, I don't have any of >> the /proc stuff or /dev/urandom for seedrandom(). Is it >> essential that this function have *that* much random >> input? How does this affect the security of the connection? > > If you can predict the random seed, you can decrypt the entire > connection. All the other cryptography is based on exchanging > unguessable numbers in both directions. > > Public key cryptography does a one-way mathematical trick on a really > big number to split it into two smaller numbers, so that each one is > the antidote to the other's poison. You scramble a message with one, > you need the OTHER to unscramble it. (You can't undo it with the one > that created it, that's the clever bit.) > > You keep one of this pair of numbers secret (doesn't matter which, > they're symmetrical) as your private key and give the other out as > your public key. Anybody can use your public key to send you a message > which only you can read with your private key. And anyone can read > messages you send with your private key but only you could have sent > them. So in one direction it provides authentication, in the other it > provides privacy. > > When you want a bidirectional connection providing both, each side > produces a pair of of keys (four keys total), then exchanges one and > keeps the other. Then you encrypt each packet TWICE, with your private > key and with the other guy's public key. At the other end they decrypt > with your public key (so the message could only have been created with > your private key, so it came from you) and their own private key (so > only they can read it). Doesn't matter what order the two > encryption/decryptions occur in as long as both sides agree. > > Public key cryptography is really computationally expensive (I.E. > slow) so what they do is exchange symmetrical keys with it, which are > another unguessable secret number that's much faster to use, but which > requires both sides to know the _same_ unguessable secret. (The poison > is its own antidote, the key that encrypted is also the key that > undoes it. Simpler/faster math that way, but it means you need an > established relationship to use it.) > > The rest of the connection is then encrypted with the symmetric keys. > (Well, it generates and exchanges fresh symmetric keys every once in a > while so that listeners won't have TOO much of the same kind of data > to try various clever attacks with to guess that key.) The public key > cryptography is just used to establish and verify the connection at > the start. > >> 2.. >> I essentially hard-coded the -r option (ssh server) to use a >> pre-established rsa_host_key file. Should this file be built >> once for a given system, and then reused or is this something >> that should be recreated each time the server is started? > > The host key uniquely identifies the host. It's what gives you the > "host key has changed!" warning when somebody reinstalls the server. > > Otherwise, anybody could intercept the connection, insert their own > ssh server, have you log into it, forward the credentials use use to > the other server to log into that, and pass data through in both > directions while logging all of it. This is called a "man in the > middle" attack, and you prevent it by giving each server a unique way > to identify itself that only itknows. (Basically you encrypt a packet > at it using its public key, and it decrypts it using its private key > and sends back the correct response based on its contents.) > > And that's cryptography 101. :) > > Rob From ed.sutter at alcatel-lucent.com Sat Apr 13 04:05:18 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Fri, 12 Apr 2013 16:05:18 -0400 Subject: session_identification() In-Reply-To: <1365719444.18069.90@driftwood> References: <1365719444.18069.90@driftwood> Message-ID: <516868FE.2080106@alcatel-lucent.com> Hi, Not sure, but I think I stumbled on what may be a problem with the session_identification() function... Shouldn't the strncmp() at the bottom of the function only be executed if the done flag is true? Seems to me that this could cause a crash because ses.remoteident may be NULL. Ed From ed.sutter at alcatel-lucent.com Sat Apr 13 04:27:53 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Fri, 12 Apr 2013 16:27:53 -0400 Subject: session_identification() In-Reply-To: <516868FE.2080106@alcatel-lucent.com> References: <1365719444.18069.90@driftwood> <516868FE.2080106@alcatel-lucent.com> Message-ID: <51686E49.5000708@alcatel-lucent.com> On 4/12/2013 4:05 PM, Ed Sutter wrote: > Hi, > Not sure, but I think I stumbled on what may be a problem with the > session_identification() function... > > Shouldn't the strncmp() at the bottom of the function only be executed > if the done flag is true? Seems to me that this could cause a crash > because > ses.remoteident may be NULL. > > Ed False alarm (Sorry)... I see in the case of the standard build ses.remoteclosed() doesn't return... From matt at ucc.asn.au Mon Apr 15 22:14:58 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 15 Apr 2013 22:14:58 +0800 Subject: Dropbear 2013.57 released Message-ID: <20130415141458.GJ28516@ucc.gu.uwa.edu.au> 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 kexguess2 at 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 From ed.sutter at alcatel-lucent.com Tue Apr 16 00:19:49 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Mon, 15 Apr 2013 12:19:49 -0400 Subject: embedded dropbear... Message-ID: <516C28A5.6090107@alcatel-lucent.com> Hi, I've got what I think is a reasonably stable version of dropbear's SSH server working in a non-posix, thread-based embedded system. I'd like to review the changes I made for anyone that may be considering doing this, but also to see if any flags get raised by the folks that have been using this for a while. Since I don't really know if there's much interest in this within the group, I'll skip a lot of detail for this pass and just note the main points. Then if it turns out that this is of interest we can dig in more (and I'll probably learn something)... GOAL: - A single ssh login at any given time, to connect to an embedded command line interface (no shell, no processes, no posix, etc..). ASSUMPTIONS: - Running a small kernel that supports threads; - Using GCC for powerpc. - I assume very little about any OS support for anything other than libc (in my case I do have an embedded FS, but that's easily bypassed). In other words: no shell process, no fork(), no exec(), no pipes, etc.. This includes no use of fprintf(...) as well. - I do have a TCP/IP stack; using a non-standard select (doesn't support multiple FDs) plus recv/send instead of read/write. - 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. 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. As a session starts up, I call loadhostkeys() and a hacked version of seedrandom() prior to svr_session(). The session_loop() function just blocks waiting for incoming packets from the network. User authentication is handled with a local function that simply verifies that the incoming login and password match; and the majority of the code that forks off the shell is just bypassed. 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(); } 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. 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). I'm guessing that this would be a mess to integrate back into the distribution; however, I'm up for it if folks wanna go for it. Perhaps a "cub" version for embedded systems would be a peer to the main source directory and that would allow both the process and thread based versions to use as much of the same code as possible; but keep the "mess" isolated a bit more. Lemme know what you think, Ed From ed.sutter at alcatel-lucent.com Tue Apr 16 01:00:02 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Mon, 15 Apr 2013 13:00:02 -0400 Subject: embedded dropbear (more)... Message-ID: <516C3212.7060807@alcatel-lucent.com> Hi, Just to put a few things in perspective regarding the likelihood of this working in a really small embedded system... Regarding memory... It really depends on just how small you need to be... One session looks like it uses upwards of 2100 malloc calls. Long term fragmentation from one session to the next is not an issue simply because I have a dedicated heap, which I flush at the end of each session; however my heap analytics show that the high-water level is under 200K of heap. I'm hoping that some of these allocations can be replaced with stack-based arrays, but I haven't looked into that much yet. Regarding speed... No "real" data here, other than to say that I'm on a ~450Mhz PowerPC (no FPU) and it seems to be fine. Ed From ed.sutter at alcatel-lucent.com Tue Apr 16 04:24:46 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Mon, 15 Apr 2013 16:24:46 -0400 Subject: mp_init/mp_clear memory allocation Message-ID: <516C620E.5040500@alcatel-lucent.com> Hi, I started digging into the possibility of reducing the number of malloc/free calls (by replacing small/quick fixed-size allocations with stack arrays), and I think I found one that makes a substantial difference... The call to mp_div_2d() in a loop inside the function mp_to_unsigned_bin()... If I create a version of mp_init() (call it mp_init_nomalloc() that does not allocate and then I put that small array on the stack in mp_div_2d(), I observed a dramatic decrease in the number of malloc/free calls (dropped from about 2100 to about 550) for a single session that simply connects and then exits. This is tough to observe dynamically without a debuggable malloc (which I have); but its always possible that my diagnostics are off too; hence it would be nice to get a second set of eyes looking at this to see if my observation is correct. If it is, then it would apply to any function that does both the mp_init() and the matching mp_clear() in the same block of code. New versions of libtomath/bn_mp_div_2d.c and bn_mp_init.c are attached if someone has time to double check me. Hopefully I won't realize my mistake immediately after I send this as I did before and have to retract my statement!! :-( Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: bn_mp_init.c Type: text/x-csrc Size: 1490 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130415/e6426434/attachment.c -------------- next part -------------- A non-text attachment was scrubbed... Name: bn_mp_div_2d.c Type: text/x-csrc Size: 2481 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130415/e6426434/attachment-0001.c From ed.sutter at alcatel-lucent.com Tue Apr 16 04:36:45 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Mon, 15 Apr 2013 16:36:45 -0400 Subject: build_lut Message-ID: <516C64DD.4030301@alcatel-lucent.com> Sorry for the burst of email, but as I was browsing code that calls mp_init() I may have stumbled on something else... Does anyone know if the "build_lut" function is ever used? Take a quick peek at it and notice this... static int build_lut(int idx, void *modulus, void *mp, void *mu) { unsigned x, y, err, bitlen, lut_gap; void *tmp; tmp = NULL; ... if ((err = mp_init(&tmp)) != CRYPT_OK) { goto ERR; } ... With mp_init() assuming it is getting a pointer to an mp_int structure, this looks bad. True? Ed From ed.sutter at alcatel-lucent.com Tue Apr 16 05:30:04 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Mon, 15 Apr 2013 17:30:04 -0400 Subject: embedded dropbear (more)... In-Reply-To: <516C3212.7060807@alcatel-lucent.com> References: <516C3212.7060807@alcatel-lucent.com> Message-ID: <516C715C.2030904@alcatel-lucent.com> One correction... I realized that I reported my high-water mark with my allocator in 'trace' mode. This significantly screws up the allocation sizes in runtime. After rebuilding with that turned off, the high-water mark that I get is around 77K. > Hi, > Just to put a few things in perspective regarding the likelihood of this > working in a really small embedded system... > > Regarding memory... > It really depends on just how small you need to be... > > One session looks like it uses upwards of 2100 malloc calls. Long term > fragmentation from one session to the next is not an issue simply > because I > have a dedicated heap, which I flush at the end of each session; however > my heap analytics show that the high-water level is under 200K of heap. > I'm hoping that some of these allocations can be replaced with > stack-based arrays, > but I haven't looked into that much yet. > > Regarding speed... > No "real" data here, other than to say that I'm on a ~450Mhz PowerPC > (no FPU) > and it seems to be fine. > > > Ed > > From fabriziobertocci at gmail.com Tue Apr 16 05:47:13 2013 From: fabriziobertocci at gmail.com (Fabrizio Bertocci) Date: Mon, 15 Apr 2013 17:47:13 -0400 Subject: embedded dropbear (more)... In-Reply-To: <516C715C.2030904@alcatel-lucent.com> References: <516C3212.7060807@alcatel-lucent.com> <516C715C.2030904@alcatel-lucent.com> Message-ID: Hmm interesting... now, 77K is kind of 'at reach'... Depending on the chip I am going to finalize the project, but probably with some help from some external RAM & flash I might give it a shot. Thanks a lot for your reports! Fabrizio On Mon, Apr 15, 2013 at 5:30 PM, Ed Sutter wrote: > One correction... > I realized that I reported my high-water mark with my allocator > in 'trace' mode. This significantly screws up the allocation sizes in > runtime. After rebuilding with that turned off, the high-water mark > that I get is around 77K. > > Hi, >> Just to put a few things in perspective regarding the likelihood of this >> working in a really small embedded system... >> >> Regarding memory... >> It really depends on just how small you need to be... >> >> One session looks like it uses upwards of 2100 malloc calls. Long term >> fragmentation from one session to the next is not an issue simply because >> I >> have a dedicated heap, which I flush at the end of each session; however >> my heap analytics show that the high-water level is under 200K of heap. >> I'm hoping that some of these allocations can be replaced with >> stack-based arrays, >> but I haven't looked into that much yet. >> >> Regarding speed... >> No "real" data here, other than to say that I'm on a ~450Mhz PowerPC (no >> FPU) >> and it seems to be fine. >> >> >> Ed >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130415/9441c062/attachment.htm From ed.sutter at alcatel-lucent.com Tue Apr 16 20:27:59 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Tue, 16 Apr 2013 08:27:59 -0400 Subject: embedded dropbear (more)... In-Reply-To: References: <516C3212.7060807@alcatel-lucent.com> <516C715C.2030904@alcatel-lucent.com> Message-ID: <516D43CF.60908@alcatel-lucent.com> Fabrizio, Don't ignore CPU horsepower needs. Ed > Hmm interesting... now, 77K is kind of 'at reach'... > Depending on the chip I am going to finalize the project, but probably > with some help from some external RAM & flash I might give it a shot. > Thanks a lot for your reports! > Fabrizio > > > On Mon, Apr 15, 2013 at 5:30 PM, Ed Sutter > > > wrote: > > One correction... > I realized that I reported my high-water mark with my allocator > in 'trace' mode. This significantly screws up the allocation sizes in > runtime. After rebuilding with that turned off, the high-water mark > that I get is around 77K. > > Hi, > Just to put a few things in perspective regarding the > likelihood of this > working in a really small embedded system... > > Regarding memory... > It really depends on just how small you need to be... > > One session looks like it uses upwards of 2100 malloc calls. > Long term > fragmentation from one session to the next is not an issue > simply because I > have a dedicated heap, which I flush at the end of each > session; however > my heap analytics show that the high-water level is under 200K > of heap. > I'm hoping that some of these allocations can be replaced with > stack-based arrays, > but I haven't looked into that much yet. > > Regarding speed... > No "real" data here, other than to say that I'm on a ~450Mhz > PowerPC (no FPU) > and it seems to be fine. > > > Ed > > > > From matt at ucc.asn.au Tue Apr 16 23:44:00 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 16 Apr 2013 23:44:00 +0800 Subject: embedded dropbear... In-Reply-To: <516C28A5.6090107@alcatel-lucent.com> References: <516C28A5.6090107@alcatel-lucent.com> Message-ID: <20130416154400.GP28516@ucc.gu.uwa.edu.au> 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 From ed.sutter at alcatel-lucent.com Wed Apr 17 01:26:34 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Tue, 16 Apr 2013 13:26:34 -0400 Subject: dropbearkey question... Message-ID: <516D89CA.2040501@alcatel-lucent.com> Hi, I now have the dropbearkey code integrated into my embedded stuff. I assume the idea is to call this function each time the server starts up. Then each time the server starts, future client connections will reject the server connection until $HOME/.ssh/known_hosts is purged of that server's key information. Correct so far? Assuming yes... Then, the user of the client has to accept the new credentials based on the RSA key fingerprint from the server. So, shouldn't the message that comes out of the client reflect the same fingerprint as that which was printed when the key was created on the server? (mine doesn't) Ed From ed.sutter at alcatel-lucent.com Wed Apr 17 01:48:06 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Tue, 16 Apr 2013 13:48:06 -0400 Subject: embedded dropbear... In-Reply-To: <20130416154400.GP28516@ucc.gu.uwa.edu.au> References: <516C28A5.6090107@alcatel-lucent.com> <20130416154400.GP28516@ucc.gu.uwa.edu.au> Message-ID: <516D8ED6.7010707@alcatel-lucent.com> Matt, Answers embedded... Ed > 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? Yea, that shouldn't be too hard to do. The first level of change would be to use threads instead of fork, and also not spawn a shell, just interface to a dumb command interpreter that users could replace with something project specific. My plan is to use this in my uCon tool, so I'll have to go down this path anyway, so maybe that would be the first step toward integrating. 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? No, mostly just 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. Yea I have a few system-specific ways to get a reasonably random value out of my hardware, so that's not a problem; however, its also not portable. >> 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 don't think I changed anything there except for the malloc defines. For all the dropbear code (I include libtom stuff in this) I replaced all uses of malloc (m_malloc, malloc, XMALLOC) with DB_MALLOC (same applies to calloc/realloc/free) throughout. I had to do this so that I could easily redefine all calls to malloc to pass __FILE__ and __LINE__ for debugging. The point here is that it would be nice if ALL use of malloc used the same name. > >> 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. Yea, understood, I buffer up when I know I can. This is just worst case. > >> 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 From ed.sutter at alcatel-lucent.com Wed Apr 17 03:28:51 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Tue, 16 Apr 2013 15:28:51 -0400 Subject: dropbearkey question... In-Reply-To: <516D89CA.2040501@alcatel-lucent.com> References: <516D89CA.2040501@alcatel-lucent.com> Message-ID: <516DA673.2090305@alcatel-lucent.com> I'm confused, so I'd like to re-phrase my question (below) a bit... Assume I start up a dropbear server on a machine (ignore my embedded case). I do that with the following commands... dropbearkey -t dss -f dropbear_dss_host_key dropbearkey -t rsa -f dropbear_rsa_host_key dropbear -F -r dropbear_rsa_host_key -d dropbear_dss_host_key Now I attempt to connect to this server using ssh and I get the message: The authenticity of host '135.222.138.20 (135.222.138.20)' can't be established. RSA key fingerprint is c5:36:7f:8c:c8:d6:d6:0c:53:45:61:76:f6:d0:91:4e. Are you sure you want to continue connecting (yes/no)? Assume I want to be anal and want to verify that I'm *really* connecting to my server. If I have access to the console of the machine running the server, then how do I verify that the fingerprint given to me by the client is in fact from the server that I assume I am connected to? I *thought* I could use "dropbearkey -y dropbear_rsa_host_key" on the server, and it would give me that same fingerprint as is presented at the client in the warning message, but that gives me a different fingerprint. What am I doing wrong here or why am I confused? Ed > Hi, > I now have the dropbearkey code integrated into my embedded stuff. > I assume the idea is to call this function each time the server starts > up. > > Then each time the server starts, future client connections will > reject the > server connection until $HOME/.ssh/known_hosts is purged of that server's > key information. > > Correct so far? > Assuming yes... > > Then, the user of the client has to accept the new credentials based on > the RSA key fingerprint from the server. So, shouldn't the message that > comes out of the client reflect the same fingerprint as that which was > printed when the key was created on the server? > > (mine doesn't) > Ed > From ed.sutter at alcatel-lucent.com Wed Apr 17 04:14:19 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Tue, 16 Apr 2013 16:14:19 -0400 Subject: dropbearkey question... In-Reply-To: <516DA673.2090305@alcatel-lucent.com> References: <516D89CA.2040501@alcatel-lucent.com> <516DA673.2090305@alcatel-lucent.com> Message-ID: <516DB11B.5040805@alcatel-lucent.com> Ok, more information... I see that if I use an ssh client that connects to an ssh server, I do get the expected fingerprints. I also see that if I use the dbclient with the db server I get the expected fingerprint. The problem occurs when I try to use the ssh client to connect to the db server. Any thoughts? > I'm confused, so I'd like to re-phrase my question (below) a bit... > Assume I start up a dropbear server on a machine (ignore my embedded > case). > I do that with the following commands... > > dropbearkey -t dss -f dropbear_dss_host_key > dropbearkey -t rsa -f dropbear_rsa_host_key > dropbear -F -r dropbear_rsa_host_key -d dropbear_dss_host_key > > Now I attempt to connect to this server using ssh and I get the message: > > The authenticity of host '135.222.138.20 (135.222.138.20)' can't be > established. > RSA key fingerprint is > c5:36:7f:8c:c8:d6:d6:0c:53:45:61:76:f6:d0:91:4e. > Are you sure you want to continue connecting (yes/no)? > > Assume I want to be anal and want to verify that I'm *really* > connecting to my server. > If I have access to the console of the machine running the server, > then how do I verify > that the fingerprint given to me by the client is in fact from the > server that I assume I > am connected to? > > I *thought* I could use "dropbearkey -y dropbear_rsa_host_key" on the > server, > and it would give me that same fingerprint as is presented at the > client in the > warning message, but that gives me a different fingerprint. > What am I doing wrong here or why am I confused? > > Ed > > >> Hi, >> I now have the dropbearkey code integrated into my embedded stuff. >> I assume the idea is to call this function each time the server >> starts up. >> >> Then each time the server starts, future client connections will >> reject the >> server connection until $HOME/.ssh/known_hosts is purged of that >> server's >> key information. >> >> Correct so far? >> Assuming yes... >> >> Then, the user of the client has to accept the new credentials based on >> the RSA key fingerprint from the server. So, shouldn't the message that >> comes out of the client reflect the same fingerprint as that which was >> printed when the key was created on the server? >> >> (mine doesn't) >> Ed >> > From ed.sutter at alcatel-lucent.com Wed Apr 17 04:31:07 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Tue, 16 Apr 2013 16:31:07 -0400 Subject: dropbearkey question... In-Reply-To: <516DB11B.5040805@alcatel-lucent.com> References: <516D89CA.2040501@alcatel-lucent.com> <516DA673.2090305@alcatel-lucent.com> <516DB11B.5040805@alcatel-lucent.com> Message-ID: <516DB50B.8040303@alcatel-lucent.com> Found the problem... In my energetic effort to reduce the size of the server, I had #undef DROPBEAR_MD5_HMAC in my options.h file. With that defined, the fingerprints now match. All better now. Sorry for the noise! Ed > Ok, more information... > I see that if I use an ssh client that connects to an ssh server, I do > get the expected > fingerprints. I also see that if I use the dbclient with the db > server I get the > expected fingerprint. The problem occurs when I try to use the ssh > client to connect > to the db server. > Any thoughts? > >> I'm confused, so I'd like to re-phrase my question (below) a bit... >> Assume I start up a dropbear server on a machine (ignore my embedded >> case). >> I do that with the following commands... >> >> dropbearkey -t dss -f dropbear_dss_host_key >> dropbearkey -t rsa -f dropbear_rsa_host_key >> dropbear -F -r dropbear_rsa_host_key -d dropbear_dss_host_key >> >> Now I attempt to connect to this server using ssh and I get the message: >> >> The authenticity of host '135.222.138.20 (135.222.138.20)' can't be >> established. >> RSA key fingerprint is >> c5:36:7f:8c:c8:d6:d6:0c:53:45:61:76:f6:d0:91:4e. >> Are you sure you want to continue connecting (yes/no)? >> >> Assume I want to be anal and want to verify that I'm *really* >> connecting to my server. >> If I have access to the console of the machine running the server, >> then how do I verify >> that the fingerprint given to me by the client is in fact from the >> server that I assume I >> am connected to? >> >> I *thought* I could use "dropbearkey -y dropbear_rsa_host_key" on the >> server, >> and it would give me that same fingerprint as is presented at the >> client in the >> warning message, but that gives me a different fingerprint. >> What am I doing wrong here or why am I confused? >> >> Ed >> >> >>> Hi, >>> I now have the dropbearkey code integrated into my embedded stuff. >>> I assume the idea is to call this function each time the server >>> starts up. >>> >>> Then each time the server starts, future client connections will >>> reject the >>> server connection until $HOME/.ssh/known_hosts is purged of that >>> server's >>> key information. >>> >>> Correct so far? >>> Assuming yes... >>> >>> Then, the user of the client has to accept the new credentials based on >>> the RSA key fingerprint from the server. So, shouldn't the message >>> that >>> comes out of the client reflect the same fingerprint as that which was >>> printed when the key was created on the server? >>> >>> (mine doesn't) >>> Ed >>> >> > From hans at atbas.org Wed Apr 17 05:13:48 2013 From: hans at atbas.org (Hans Harder) Date: Tue, 16 Apr 2013 23:13:48 +0200 Subject: Compile errors on 2013.57 Message-ID: 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.c 2013-04-16 14:44:42.000000000 -0600 +++ common-kex.c 2013-04-16 15:08:54.000000000 -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; From matt at ucc.asn.au Wed Apr 17 08:11:11 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 17 Apr 2013 08:11:11 +0800 Subject: Compile errors on 2013.57 In-Reply-To: References: Message-ID: <20130417001111.GQ28516@ucc.gu.uwa.edu.au> 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.c 2013-04-16 14:44:42.000000000 -0600 > +++ common-kex.c 2013-04-16 15:08:54.000000000 -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; From hans at atbas.org Wed Apr 17 20:12:08 2013 From: hans at atbas.org (Hans Harder) Date: Wed, 17 Apr 2013 14:12:08 +0200 Subject: Patch for usermode server Message-ID: Added check that only the dropbear user is allowed to login if it is running as non-root. Removed the log message, --- loginrec.c 2013-04-15 08:01:58.000000000 -0600 +++ loginrec.c 2013-04-17 06:01:57.000000000 -0600 @@ -329,8 +329,6 @@ login_write (struct logininfo *li) { #ifndef HAVE_CYGWIN if ((int)geteuid() != 0) { - dropbear_log(LOG_WARNING, - "Attempt to write login records by non-root user (aborting)"); return 1; } #endif --- svr-auth.c 2013-04-15 08:01:58.000000000 -0600 +++ svr-auth.c 2013-04-17 06:00:22.000000000 -0600 @@ -226,6 +226,7 @@ static int checkusername(unsigned char * char* listshell = NULL; char* usershell = NULL; + int uid; TRACE(("enter checkusername")) if (userlen > MAX_USERNAME_LEN) { return DROPBEAR_FAILURE; @@ -255,6 +256,18 @@ static int checkusername(unsigned char * return DROPBEAR_FAILURE; } + /* check if we are running as non-root, and login user is different from the server */ + uid=geteuid(); + if (uid != 0 && uid != ses.authstate.pw_uid) { + TRACE(("running as nonroot, only server uid is allowed")) + dropbear_log(LOG_WARNING, + "Login attempt with wrong user %s from %s", + ses.authstate.pw_name, + svr_ses.addrstring); + send_msg_userauth_failure(0, 1); + return DROPBEAR_FAILURE; + } + /* check for non-root if desired */ if (svr_opts.norootlogin && ses.authstate.pw_uid == 0) { TRACE(("leave checkusername: root login disabled")) From hans at atbas.org Wed Apr 17 20:23:52 2013 From: hans at atbas.org (Hans Harder) Date: Wed, 17 Apr 2013 14:23:52 +0200 Subject: Patch multihop scp with different ports Message-ID: 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 at host1/2222,user at 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 at host1#2222,user at 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.000000000 -0600 +++ cli-runopts.c 2013-04-17 06:14:56.000000000 -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; From matt at ucc.asn.au Wed Apr 17 23:18:42 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 17 Apr 2013 23:18:42 +0800 Subject: Patch multihop scp with different ports In-Reply-To: References: Message-ID: <20130417151842.GX28516@ucc.gu.uwa.edu.au> 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 at host1/2222,user at 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 at host1#2222,user at 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.000000000 -0600 > +++ cli-runopts.c 2013-04-17 06:14:56.000000000 -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; From matt at ucc.asn.au Thu Apr 18 23:10:14 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 18 Apr 2013 23:10:14 +0800 Subject: Dropbear 2013.58 released Message-ID: <20130418151014.GC28516@ucc.gu.uwa.edu.au> 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 at 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 From jay at peepo.com Fri Apr 19 16:20:27 2013 From: jay at peepo.com (Jonathan Chetwynd) Date: Fri, 19 Apr 2013 09:20:27 +0100 Subject: howto: send the X commands to the X server on your host. Message-ID: <5170FE4B.2020802@peepo.com> 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? kind regards -- Jonathan Chetwynd http://www.gnote.org Eyetracking in HTML5 From changyy.csie at gmail.com Fri Apr 19 16:24:47 2013 From: changyy.csie at gmail.com (Yuan-Yi Chang) Date: Fri, 19 Apr 2013 16:24:47 +0800 Subject: About "DEFAULT_PATH" and "_PATH_SSH_PROGRAM" variables Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130419/623372cb/attachment.htm From matt at ucc.asn.au Sat Apr 20 10:10:24 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 20 Apr 2013 10:10:24 +0800 Subject: howto: send the X commands to the X server on your host. In-Reply-To: <5170FE4B.2020802@peepo.com> References: <5170FE4B.2020802@peepo.com> Message-ID: <20130420021024.GE28516@ucc.gu.uwa.edu.au> 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 From matt at ucc.asn.au Sat Apr 20 10:12:51 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 20 Apr 2013 10:12:51 +0800 Subject: About "DEFAULT_PATH" and "_PATH_SSH_PROGRAM" variables In-Reply-To: References: Message-ID: <20130420021251.GF28516@ucc.gu.uwa.edu.au> 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 From ed.sutter at alcatel-lucent.com Fri Apr 26 02:57:53 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Thu, 25 Apr 2013 14:57:53 -0400 Subject: question Message-ID: <51797CB1.8080406@alcatel-lucent.com> 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 From ed.sutter at alcatel-lucent.com Fri Apr 26 04:23:49 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Thu, 25 Apr 2013 16:23:49 -0400 Subject: question In-Reply-To: <51797CB1.8080406@alcatel-lucent.com> References: <51797CB1.8080406@alcatel-lucent.com> Message-ID: <517990D5.9030109@alcatel-lucent.com> 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 From aloof.schipperke at gmail.com Mon Apr 29 22:20:32 2013 From: aloof.schipperke at gmail.com (Kevin Johnson) Date: Mon, 29 Apr 2013 08:20:32 -0600 Subject: segfault in svr-authpasswd.c Message-ID: 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 From ed.sutter at alcatel-lucent.com Mon Apr 29 22:48:22 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Mon, 29 Apr 2013 10:48:22 -0400 Subject: Performance testing ssh (was Re: question) In-Reply-To: References: Message-ID: <517E8836.8040507@alcatel-lucent.com> Yep, thanks, I've been running with WireShark... (running it on the same machine as the client, so no need for mirroring here). > > Ed, > > I would also tcpdump all the network traffic during the test... using > a real hub or switch with port mirroring or vswitch promiscuous mode. > > At least then you could eliminate any lower level issues. > > Good luck. > > -- > http://www.realthought.net/ > > El 26/04/2013 05:02, "Ed Sutter" > escribi?: > > 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 > From matt at ucc.asn.au Mon Apr 29 23:35:14 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 29 Apr 2013 23:35:14 +0800 Subject: question In-Reply-To: <517990D5.9030109@alcatel-lucent.com> References: <51797CB1.8080406@alcatel-lucent.com> <517990D5.9030109@alcatel-lucent.com> Message-ID: <20130429153514.GM28516@ucc.gu.uwa.edu.au> 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 > From ed.sutter at alcatel-lucent.com Tue Apr 30 01:53:05 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Mon, 29 Apr 2013 13:53:05 -0400 Subject: question In-Reply-To: <20130429153514.GM28516@ucc.gu.uwa.edu.au> References: <51797CB1.8080406@alcatel-lucent.com> <517990D5.9030109@alcatel-lucent.com> <20130429153514.GM28516@ucc.gu.uwa.edu.au> Message-ID: <517EB381.50602@alcatel-lucent.com> Hmmm... Matt, I think this gives me a good hint as to where the problem is... I have a function that is called by my application when asynchronous data is destined for the SSH connection. Am I correct to assume that this function should block if ses.dataallowed is zero? I added that check to my code, and I'm testing now.. 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 From ed.sutter at alcatel-lucent.com Tue Apr 30 04:43:28 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Mon, 29 Apr 2013 16:43:28 -0400 Subject: question In-Reply-To: <517EB381.50602@alcatel-lucent.com> References: <51797CB1.8080406@alcatel-lucent.com> <517990D5.9030109@alcatel-lucent.com> <20130429153514.GM28516@ucc.gu.uwa.edu.au> <517EB381.50602@alcatel-lucent.com> Message-ID: <517EDB70.40307@alcatel-lucent.com> Matt, My previously mentioned change didn't fix anything; but I've stumbled onto something else... When I send data (using my version of send_msg_channel_data()) I wasn't decrementing the channel->transwindow value by the number of bytes I was sending. As a result, my channel->transwindow value just kept increasing (this surely seems like a bad thing!). Would that cause the connection to eventually just lock up? I added the code that decrements this by the number of bytes I send out, and now I see that the channel->transwindow value hovers around 14K. Testing now... Ed > Hmmm... > Matt, I think this gives me a good hint as to where the problem is... > I have a function that is called by my application when asynchronous > data is destined > for the SSH connection. Am I correct to assume that this function > should block > if ses.dataallowed is zero? I added that check to my code, and I'm > testing now.. > 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 > From ed.sutter at alcatel-lucent.com Tue Apr 30 22:41:24 2013 From: ed.sutter at alcatel-lucent.com (Ed Sutter) Date: Tue, 30 Apr 2013 10:41:24 -0400 Subject: question In-Reply-To: <20130429153514.GM28516@ucc.gu.uwa.edu.au> References: <51797CB1.8080406@alcatel-lucent.com> <517990D5.9030109@alcatel-lucent.com> <20130429153514.GM28516@ucc.gu.uwa.edu.au> Message-ID: <517FD814.2010303@alcatel-lucent.com> 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 From matt at ucc.asn.au Wed May 1 09:37:32 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 1 May 2013 09:37:32 +0800 Subject: question In-Reply-To: <517FD814.2010303@alcatel-lucent.com> References: <51797CB1.8080406@alcatel-lucent.com> <517990D5.9030109@alcatel-lucent.com> <20130429153514.GM28516@ucc.gu.uwa.edu.au> <517FD814.2010303@alcatel-lucent.com> Message-ID: <20130501013732.GO28516@ucc.gu.uwa.edu.au> 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 > From changyy.csie at gmail.com Fri May 3 14:44:21 2013 From: changyy.csie at gmail.com (Yuan-Yi Chang) Date: Fri, 3 May 2013 14:44:21 +0800 Subject: A solution for PAM with nonexistent user Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130503/6ab8eb56/attachment.htm From cickumqt at gmail.com Mon May 13 17:27:49 2013 From: cickumqt at gmail.com (Christopher Meng) Date: Mon, 13 May 2013 17:27:49 +0800 Subject: Add support for aarch64 Message-ID: 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. To fix this, you can: 1. Use at least autoconf 2.69 to reconfigure. 2. A patch at http://ausil.fedorapeople.org/aarch64/dropbear/dropbear-aarch64.patch which updates config.guess and config.sub to recognize aarch64. But I think the latter one is for downstream to include it into the package, for upstream, will you fix this? Thanks! *Yours sincerely,* *Christopher Meng* Always playing in Fedora Project http://cicku.me -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130513/a6bda984/attachment.htm From matt at ucc.asn.au Mon May 13 21:09:27 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 13 May 2013 21:09:27 +0800 Subject: Add support for aarch64 In-Reply-To: References: Message-ID: <20130513130927.GK28516@ucc.gu.uwa.edu.au> 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 From itamar at ispbrasil.com.br Mon May 13 21:24:10 2013 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Mon, 13 May 2013 10:24:10 -0300 Subject: Add support for aarch64 In-Reply-To: <20130513130927.GK28516@ucc.gu.uwa.edu.au> References: <20130513130927.GK28516@ucc.gu.uwa.edu.au> Message-ID: On Mon, May 13, 2013 at 10:09 AM, Matt Johnston wrote: > 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 to verify run grep aarch64 config.guess it should return something like $ grep aarch64 config.guess aarch64:Linux:*:*) aarch64_be:Linux:*:*) UNAME_MACHINE=aarch64_be -- ------------ Itamar Reis Peixoto From matt at ucc.asn.au Mon May 13 21:34:00 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 13 May 2013 21:34:00 +0800 Subject: A solution for PAM with nonexistent user In-Reply-To: References: Message-ID: <20130513133400.GL28516@ucc.gu.uwa.edu.au> 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 From matt at ucc.asn.au Mon May 13 21:40:40 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 13 May 2013 21:40:40 +0800 Subject: segfault in svr-authpasswd.c In-Reply-To: References: Message-ID: <20130513134040.GN28516@ucc.gu.uwa.edu.au> 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 From martin.donnelly at ge.com Thu May 2 18:44:10 2013 From: martin.donnelly at ge.com (Martin Donnelly) Date: Thu, 2 May 2013 11:44:10 +0100 Subject: [PATCH] Notify clients of PAM error messages Message-ID: <20130502104410.GB4887@edna.edi.geip.ge.com> 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 -------------- next part -------------- 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.000000000 +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.c 2013-04-18 15:58:14.000000000 +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.000000000 +0100 +++ dropbear-2013.58/session.h 2013-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.000000000 +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.000000000 +0100 +++ dropbear-2013.58/svr-authpam.c 2013-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; + default: TRACE(("Unknown message type")) rc = PAM_CONV_ERR; From matt at ucc.asn.au Mon May 13 22:06:16 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 13 May 2013 22:06:16 +0800 Subject: [PATCH] Notify clients of PAM error messages In-Reply-To: <20130502104410.GB4887@edna.edi.geip.ge.com> References: <20130502104410.GB4887@edna.edi.geip.ge.com> Message-ID: <20130513140616.GP28516@ucc.gu.uwa.edu.au> 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.000000000 +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.c 2013-04-18 15:58:14.000000000 +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.000000000 +0100 > +++ dropbear-2013.58/session.h 2013-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.000000000 +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.000000000 +0100 > +++ dropbear-2013.58/svr-authpam.c 2013-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; > + > default: > TRACE(("Unknown message type")) > rc = PAM_CONV_ERR; From martin.donnelly at ge.com Mon May 13 22:57:27 2013 From: martin.donnelly at ge.com (Martin Donnelly) Date: Mon, 13 May 2013 15:57:27 +0100 Subject: [PATCH] Notify clients of PAM error messages In-Reply-To: <20130513140616.GP28516@ucc.gu.uwa.edu.au> References: <20130502104410.GB4887@edna.edi.geip.ge.com> <20130513140616.GP28516@ucc.gu.uwa.edu.au> Message-ID: <5190FF57.2030904@ge.com> On 13/05/2013 15:06, Matt Johnston wrote: > 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. > Thanks. > My one concern is how clients might deal with multiple > banner messages - have you tried with many clients? > All testing has been done using the dropbear client, OpenSSH (5.3p1) and PuTTY (0.62). I've tested multiple messages by enabling the server banner as well as having two pam_nologin entries in the PAM account configuration. In each case the SSH_MSG_USERAUTH_BANNER message(s) sent by the server have been displayed correctly by the clients. Cheers - Martin From vapier at gentoo.org Mon May 13 23:32:23 2013 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 13 May 2013 11:32:23 -0400 Subject: Add support for aarch64 In-Reply-To: References: Message-ID: <201305131132.24403.vapier@gentoo.org> On Monday 13 May 2013 05:27:49 Christopher Meng wrote: > 1. Use at least autoconf 2.69 to reconfigure. that is incorrect. it has nothing to do with autoconf 2.69. > 2. A patch at > > http://ausil.fedorapeople.org/aarch64/dropbear/dropbear-aarch64.patch i already pointed out to the fedora in many places that they need to fix their package manager to handle this. patching packages is ridiculous. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130513/213564b7/attachment.pgp From itamar at ispbrasil.com.br Mon May 13 23:39:37 2013 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Mon, 13 May 2013 12:39:37 -0300 Subject: Add support for aarch64 In-Reply-To: <201305131132.24403.vapier@gentoo.org> References: <201305131132.24403.vapier@gentoo.org> Message-ID: On Mon, May 13, 2013 at 12:32 PM, Mike Frysinger wrote: > On Monday 13 May 2013 05:27:49 Christopher Meng wrote: >> 1. Use at least autoconf 2.69 to reconfigure. > > that is incorrect. it has nothing to do with autoconf 2.69. I disagree with you, aarch64 support was included in autoconf 2.69 >> 2. A patch at >> >> http://ausil.fedorapeople.org/aarch64/dropbear/dropbear-aarch64.patch > > i already pointed out to the fedora in many places that they need to fix their > package manager to handle this. patching packages is ridiculous. > -mike patching other things will not fix that, because aarch64 support was added in autoconf 2.69 -- ------------ Itamar Reis Peixoto From vapier at gentoo.org Tue May 14 00:08:40 2013 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 13 May 2013 12:08:40 -0400 Subject: Add support for aarch64 In-Reply-To: References: <201305131132.24403.vapier@gentoo.org> Message-ID: <201305131208.41282.vapier@gentoo.org> On Monday 13 May 2013 11:39:37 Itamar Reis Peixoto wrote: > On Mon, May 13, 2013 at 12:32 PM, Mike Frysinger wrote: > > On Monday 13 May 2013 05:27:49 Christopher Meng wrote: > >> 1. Use at least autoconf 2.69 to reconfigure. > > > > that is incorrect. it has nothing to do with autoconf 2.69. > > I disagree with you, aarch64 support was included in autoconf 2.69 wrong, it did not. you're confusing config.{sub,guess} with autoconf. please read this (one of many) explanations i sent to the redhat guys: https://bitbucket.org/libgd/gd-libgd/issue/36/migrate-to-autoconf-269-for- arm-64-support#comment-3805784 -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130513/61360b07/attachment.pgp From cickumqt at gmail.com Tue May 14 10:01:59 2013 From: cickumqt at gmail.com (Christopher Meng) Date: Tue, 14 May 2013 10:01:59 +0800 Subject: Add support for aarch64 In-Reply-To: <201305131208.41282.vapier@gentoo.org> References: <201305131132.24403.vapier@gentoo.org> <201305131208.41282.vapier@gentoo.org> Message-ID: Mike, actually I don't want to discuss it here, I think it's not a good place. IMO AArch64 is too young to introduce it. When I started my packaging life there is no such arch. You may noticed that from 2013 there are many such requests appeared, all of them have same content and a patch automatically generated by a script. That's what Red Hat people are doing, in fact about 1800 packages have received such request. I cannot say this is right or wrong, solving the problem may via many ways. AArch64 is an new arch we finally have to face. I know what you want to express, In fact it's true that we cannot ask every upstream to update their config. I use autoreconf to reconfigure, but sometimes it cannot solve the problem. So I consider a request at upstream. Applying such a big patch is cumbersome, and of course ridiculous. Some developers at SUSE have already discussed the problem of this. They want to fix it by patching the RPM as you expected. But I don't know the progress now, and in Fedora there is no such patch available now, and maybe for a while. Red Hat people threw out a point: http://lists.fedoraproject.org/pipermail/devel/2013-April/181055.html Please have a look. We also welcome you to discuss this problem with us. We are looking forward to such discussion. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130514/7bc34718/attachment.htm From vapier at gentoo.org Tue May 14 11:24:39 2013 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 13 May 2013 23:24:39 -0400 Subject: Add support for aarch64 In-Reply-To: References: <201305131208.41282.vapier@gentoo.org> Message-ID: <201305132324.40494.vapier@gentoo.org> On Monday 13 May 2013 22:01:59 Christopher Meng wrote: > Mike, actually I don't want to discuss it here, I think it's not a good > place. IMO AArch64 is too young to introduce it. When I started my > packaging life there is no such arch. aarch64 is incidental. this problem has been affecting people pretty much since config.{sub,guess} started being redistributed. the initial x86_64 port went through the same growing pains, as has every person that has released a new cpu (tends to be more of an "embedded problem"). > You may noticed that from 2013 there are many such requests appeared, all > of them have same content and a patch automatically generated by a script. > That's what Red Hat people are doing, in fact about 1800 packages have > received such request. I cannot say this is right or wrong, solving the > problem may via many ways. as soon as you hassle upstream, you're doing it wrong imo. i have seen the same request in various projects i'm incidentally subscribed to and rebuffed each one. > AArch64 is an new arch we finally have to face. I know what you want to > express, In fact it's true that we cannot ask every upstream to update > their config. I use autoreconf to reconfigure, but sometimes > it cannot solve the problem. So I consider a request at upstream. Applying > such a big patch is cumbersome, and of course ridiculous. patching & autoreconf are both unnecessary. just copy config.{sub,guess} from a common system location and blam, you're fixed the vast majority of packages. the only time you need to hassle upstream is when they have custom code that actually does target detection (but those tend to be on the uncommon side). > Some developers at SUSE have already discussed the problem of this. They > want to fix it by patching the RPM as you expected. But I don't know the > progress now, and in Fedora there is no such patch available now, and maybe > for a while. > > Red Hat people threw out a point: > > http://lists.fedoraproject.org/pipermail/devel/2013-April/181055.html yes, i made a similar point on the acl lists (coincidentally just a few days before that fedora post): http://lists.nongnu.org/archive/html/acl-devel/2013-04/msg00003.html trying to hoist package manager limitations onto every upstream project is poor form. the fact that implementing a proper fix is taking time isn't really a valid reason. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130513/a5d1540c/attachment.pgp From rob at landley.net Tue May 14 14:58:52 2013 From: rob at landley.net (Rob Landley) Date: Tue, 14 May 2013 01:58:52 -0500 Subject: Add support for aarch64 In-Reply-To: (from cickumqt@gmail.com on Mon May 13 04:27:49 2013) References: Message-ID: <1368514732.18069.238@driftwood> On 05/13/2013 04:27:49 AM, 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. > > > To fix this, you can: > > 1. Use at least autoconf 2.69 to reconfigure. > 2. A patch at > > http://ausil.fedorapeople.org/aarch64/dropbear/dropbear-aarch64.patch > > which updates config.guess and config.sub to recognize aarch64. Huh, I hadn't even noticed. My automatic native package builds do: for guess in $(find . -name config.guess) do rm -f "$guess" && echo -e "#!/bin/sh\ngcc -dumpmachine" > "$guess" || exit 1 done on each package, because the gnu autoconf stuff is too dumb to live... Rob From vapier at gentoo.org Wed May 15 01:56:49 2013 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 14 May 2013 13:56:49 -0400 Subject: Add support for aarch64 In-Reply-To: <1368514732.18069.238@driftwood> References: <1368514732.18069.238@driftwood> Message-ID: <201305141356.50906.vapier@gentoo.org> On Tuesday 14 May 2013 02:58:52 Rob Landley wrote: > On 05/13/2013 04:27:49 AM, Christopher Meng wrote: > > 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. > > > > > > To fix this, you can: > > > > 1. Use at least autoconf 2.69 to reconfigure. > > 2. A patch at > > > > http://ausil.fedorapeople.org/aarch64/dropbear/dropbear-aarch64.patch > > > > which updates config.guess and config.sub to recognize aarch64. > > Huh, I hadn't even noticed. My automatic native package builds do: > > for guess in $(find . -name config.guess) > do > rm -f "$guess" && > echo -e "#!/bin/sh\ngcc -dumpmachine" > "$guess" || exit 1 > done that doesn't help with your outdated config.sub files which is a lot more what this report is about -- they're cross-compiling for aarch64, not running natively under it. other random notes: - should have an exec in there - bit surprised you didn't use printf rather than the non-portable echo -e - that code isn't tolerant of whitespace splitting assuming you're using bash for the host script: while read line ; do rm -f "${line}" && printf '#!/bin/sh\nexec gcc -dumpmachine\n' > "${line}" || exit 1 done < <(find . -name config.guess) -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130514/affafb96/attachment.pgp From rob at landley.net Wed May 15 12:34:28 2013 From: rob at landley.net (Rob Landley) Date: Tue, 14 May 2013 23:34:28 -0500 Subject: Add support for aarch64 In-Reply-To: <201305141356.50906.vapier@gentoo.org> (from vapier@gentoo.org on Tue May 14 12:56:49 2013) Message-ID: <1368592468.18069.245@driftwood> On 05/14/2013 12:56:49 PM, Mike Frysinger wrote: > that doesn't help with your outdated config.sub files which is a lot > more what > this report is about -- they're cross-compiling for aarch64, not > running > natively under it. I bootstrap native build environments and run 'em under qemu, therefore this is sufficient for my needs. My intended gripe was more along the lines of "autoconf is useless and making it _more_ complicated doesn't improve matters, the correct response to stroppy FSF code is almost always ripping it out". But that's a largeish tangent for this thread/list. > other random notes: > - should have an exec in there Utterly doesn't matter. > - bit surprised you didn't use printf rather than the non-portable > echo -e I implemented -e in busybox and toybox. (And the toybox one understands "--".) Considering I'm running it in an environment I built from source using known package versions... > - that code isn't tolerant of whitespace splitting If you're really going to care about that you need -print0 because a filename can have an embedded newline in it, but none of the packages I've ever encountered do that; the paths it's processing are package-relative. (I'd ask why you're trying to prove you're a better programmer than other people instead of trying to prove you're a better programmer than the computer, but I honestly don't care. This is the dropbear list, this tangent is not about dropbear...) Rob From vapier at gentoo.org Wed May 15 23:46:00 2013 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 15 May 2013 11:46:00 -0400 Subject: Add support for aarch64 In-Reply-To: <1368592468.18069.245@driftwood> References: <1368592468.18069.245@driftwood> Message-ID: <201305151146.01958.vapier@gentoo.org> On Wednesday 15 May 2013 00:34:28 Rob Landley wrote: > (I'd ask why you're trying to prove you're a better programmer than > other people instead of trying to prove you're a better programmer than > the computer, but I honestly don't care. This is the dropbear list, > this tangent is not about dropbear...) i was trying to be helpful and point out common mistakes. i'd ask why you're being a dick for no good reason, but i already know the answer. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130515/090d7021/attachment.pgp From alexain75 at gmail.com Thu May 16 19:54:02 2013 From: alexain75 at gmail.com (Alex) Date: Thu, 16 May 2013 11:54:02 +0000 (UTC) Subject: Google Authenticator Message-ID: 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. From cickumqt at gmail.com Mon May 20 12:49:35 2013 From: cickumqt at gmail.com (Christopher Meng) Date: Mon, 20 May 2013 12:49:35 +0800 Subject: Google Authenticator In-Reply-To: References: Message-ID: Have you enabled dropbear pam support? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130520/ad11f538/attachment.html From cickumqt at gmail.com Mon May 20 14:18:11 2013 From: cickumqt at gmail.com (Christopher Meng) Date: Mon, 20 May 2013 14:18:11 +0800 Subject: Google Authenticator In-Reply-To: References: Message-ID: This hinge on the configure step I think. ./configure with --enable-pam. But I don't know your os packager's doing. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130520/8558b9ad/attachment.htm From matt at ucc.asn.au Mon May 20 17:59:02 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 20 May 2013 17:59:02 +0800 Subject: Google Authenticator In-Reply-To: References: Message-ID: <403264e9-e62a-4a13-8e36-52148f180dfc@email.android.com> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130520/02dbdb8d/attachment.htm From bvwelch at gmail.com Sat May 25 05:42:44 2013 From: bvwelch at gmail.com (William Welch) Date: Fri, 24 May 2013 16:42:44 -0500 Subject: slow logins -- some data for comparison Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130524/cf748beb/attachment.htm From matt at ucc.asn.au Sat May 25 16:41:28 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 25 May 2013 16:41:28 +0800 Subject: slow logins -- some data for comparison In-Reply-To: References: Message-ID: <006c127b-ea47-45e8-b5dc-6eb221b7d606@email.android.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130525/920dd247/attachment.htm From bvwelch at gmail.com Sat May 25 23:01:16 2013 From: bvwelch at gmail.com (William Welch) Date: Sat, 25 May 2013 10:01:16 -0500 Subject: slow logins -- some data for comparison In-Reply-To: <006c127b-ea47-45e8-b5dc-6eb221b7d606@email.android.com> References: <006c127b-ea47-45e8-b5dc-6eb221b7d606@email.android.com> Message-ID: 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 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130525/4b2127dc/attachment.htm From matt at ucc.asn.au Sat May 25 23:19:00 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 25 May 2013 23:19:00 +0800 Subject: slow logins -- some data for comparison In-Reply-To: References: <006c127b-ea47-45e8-b5dc-6eb221b7d606@email.android.com> Message-ID: <20130525151900.GA28909@ucc.gu.uwa.edu.au> 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 > >> > >> From bvwelch at gmail.com Sun May 26 01:52:57 2013 From: bvwelch at gmail.com (William Welch) Date: Sat, 25 May 2013 12:52:57 -0500 Subject: slow logins -- some data for comparison In-Reply-To: <20130525151900.GA28909@ucc.gu.uwa.edu.au> References: <006c127b-ea47-45e8-b5dc-6eb221b7d606@email.android.com> <20130525151900.GA28909@ucc.gu.uwa.edu.au> Message-ID: OK, thanks for the pointers. I realize that you are in no way obligated to incorporate such changes into your official version, but I will try to make these changes in such a way that they may be useful to you... Right now, after a brief review, my thinking is to add tomsfastmath (TFM) to your BUNDLED_LIBTOM list, and enable it in your options.h, with USE_TFM as per the libtomcrypt document. In places where the changes are more involved than just cut & paste, I will if-def with USE_TFM. thanks for any suggestions! 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 > > >> 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 > > >> > > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130525/ce4515bb/attachment-0001.htm From peter at turczak.de Sun May 26 02:14:48 2013 From: peter at turczak.de (Peter Turczak) Date: Sat, 25 May 2013 20:14:48 +0200 Subject: slow logins -- some data for comparison In-Reply-To: References: <006c127b-ea47-45e8-b5dc-6eb221b7d606@email.android.com> <20130525151900.GA28909@ucc.gu.uwa.edu.au> Message-ID: <3E27AD08-F63B-48B2-BCFB-7B4B68DD2BE7@turczak.de> Hi William, a few years ago I did the port of dropbear to use TFM. It was more a proof of concept port, but it worked a treat. There were some functions missing in TFM, which I had to port forward from libtommath. You can find my old tarball here http://peter.turczak.de/dropbear-tfm.tgz . Best regards, Peter On 25.05.2013, at 19:52, William Welch wrote: > OK, thanks for the pointers. I realize that you are in no way obligated to incorporate such changes into your official version, but I will try to make these changes in such a way that they may be useful to you... > > Right now, after a brief review, my thinking is to add tomsfastmath (TFM) to your BUNDLED_LIBTOM list, and enable it in your options.h, with USE_TFM as per the libtomcrypt document. In places where the changes are more involved than just cut & paste, I will if-def with USE_TFM. > > thanks for any suggestions! > > 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 > > >> 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 > > >> > > >> > From bvwelch at gmail.com Thu May 30 00:24:18 2013 From: bvwelch at gmail.com (William Welch) Date: Wed, 29 May 2013 11:24:18 -0500 Subject: slow logins -- some data for comparison In-Reply-To: <20130525151900.GA28909@ucc.gu.uwa.edu.au> References: <006c127b-ea47-45e8-b5dc-6eb221b7d606@email.android.com> <20130525151900.GA28909@ucc.gu.uwa.edu.au> Message-ID: Greetings, An update -- the first step is complete -- modified the source to make use of ltc_mp, but using ltm_desc and USE_LTM. I generated an rsa host key and logged in via ssh, as a basic test case. A couple of small details I am working on -- there are some small differences between the ltc_mp and ltm_desc structures -- near the end of the ltm_desc there are some ifdefs that I haven't figured out yet. Any hints? I also notice two missing functions in the descriptors -- mp_addmod and mp_prime_next_prime. Should I add these to the structures? Where, at the end? If anyone should care to follow along, I could, for example, put the project up on github or wherever you like. Or send patches. Next up will be trying tomsfastmath. 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 > > >> 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 > > >> > > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130529/4151f8b7/attachment.htm From bvwelch at gmail.com Sat Jun 1 05:15:00 2013 From: bvwelch at gmail.com (William Welch) Date: Fri, 31 May 2013 16:15:00 -0500 Subject: slow logins -- some data for comparison In-Reply-To: <20130525151900.GA28909@ucc.gu.uwa.edu.au> References: <006c127b-ea47-45e8-b5dc-6eb221b7d606@email.android.com> <20130525151900.GA28909@ucc.gu.uwa.edu.au> Message-ID: 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 > > >> 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 > > >> > > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130531/6e4d6f54/attachment.htm From matt at ucc.asn.au Sat Jun 1 15:06:58 2013 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 1 Jun 2013 15:06:58 +0800 Subject: slow logins -- some data for comparison In-Reply-To: References: <006c127b-ea47-45e8-b5dc-6eb221b7d606@email.android.com> <20130525151900.GA28909@ucc.gu.uwa.edu.au> Message-ID: <979BE5DB-740E-4D3D-ACE5-2A5C0E14BDF5@ucc.asn.au> 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 > > >> 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 > > >> > > >> > From bvwelch at gmail.com Sat Jun 1 20:30:18 2013 From: bvwelch at gmail.com (William Welch) Date: Sat, 1 Jun 2013 07:30:18 -0500 Subject: slow logins -- some data for comparison In-Reply-To: <979BE5DB-740E-4D3D-ACE5-2A5C0E14BDF5@ucc.asn.au> References: <006c127b-ea47-45e8-b5dc-6eb221b7d606@email.android.com> <20130525151900.GA28909@ucc.gu.uwa.edu.au> <979BE5DB-740E-4D3D-ACE5-2A5C0E14BDF5@ucc.asn.au> Message-ID: Hi Matt, Thank you for your interest. I put the modified files, here: https://github.com/bvwelch/dropbear If you prefer a fork, or other approach, let me know and I will revise the upload. I can go back to my microblaze and capture the dropbear race output, and probably could run gprof on the Microblaze as well. Since this all started by selecting dropbear versus openssh from the typical Buildroot, that means that the same toolchain is used, so my guess is that openssh just has a different algorithm. By the way I tried various versions of gcc toolchains. I did notice that if I disabled group14, I saw about the same login time as dropbear 0.52 -- 45 seconds, and if I switched to fastmath, the time dropped to 30 seconds. But the 'footprint' of dropbear, built with tomsfastmath, is large, since it has a lot of unrolled loops. It may be about as large as openssh. I will check out your other suggestions. Thank you, William On Saturday, June 1, 2013, Matt Johnston wrote: > 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 al -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130601/18eea070/attachment.htm From viric at viric.name Tue Jun 18 03:21:54 2013 From: viric at viric.name (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Mon, 17 Jun 2013 21:21:54 +0200 Subject: Fixing crash on -J (proxycmd) Message-ID: <20130617192154.GH19012@vicerveza.homeunix.net> Hello, since 0.53 (at least), using -J crashes on mips. With valgrind, I tracked this down to a bad free. Here is the patch attached that should fix it. At least, valgrind doesn't complain. I'll test it with mips later. Regards, Llu?s. -------------- next part -------------- diff -r 5ba19d00da08 cli-runopts.c --- a/cli-runopts.c Sun May 26 18:43:00 2013 +0800 +++ b/cli-runopts.c Mon Jun 17 19:19:12 2013 +0000 @@ -383,6 +383,13 @@ exit(EXIT_FAILURE); } +#ifdef ENABLE_CLI_PROXYCMD + if (cli_opts.proxycmd) { + /* To match the common path of m_freeing it */ + cli_opts.proxycmd = m_strdup(cli_opts.proxycmd); + } +#endif + if (cli_opts.remoteport == NULL) { cli_opts.remoteport = "22"; } From viric at viric.name Tue Jun 18 03:51:45 2013 From: viric at viric.name (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Mon, 17 Jun 2013 21:51:45 +0200 Subject: Fixing crash on -J (proxycmd) In-Reply-To: <20130617192154.GH19012@vicerveza.homeunix.net> References: <20130617192154.GH19012@vicerveza.homeunix.net> Message-ID: <20130617195145.GI19012@vicerveza.homeunix.net> Oops, now the patch with tabs. Regards, Llu?s. On Mon, Jun 17, 2013 at 09:21:54PM +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. > > Regards, > Llu?s. -------------- next part -------------- diff -r 5ba19d00da08 cli-runopts.c --- a/cli-runopts.c Sun May 26 18:43:00 2013 +0800 +++ b/cli-runopts.c Mon Jun 17 19:51:08 2013 +0000 @@ -383,6 +383,13 @@ exit(EXIT_FAILURE); } +#ifdef ENABLE_CLI_PROXYCMD + if (cli_opts.proxycmd) { + /* To match the common path of m_freeing it */ + cli_opts.proxycmd = m_strdup(cli_opts.proxycmd); + } +#endif + if (cli_opts.remoteport == NULL) { cli_opts.remoteport = "22"; } From viric at viric.name Wed Jun 19 04:11:35 2013 From: viric at viric.name (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Tue, 18 Jun 2013 22:11:35 +0200 Subject: -lcrypt as dependency in Makefile? (CRYPTLIB) Message-ID: <20130618201135.GT19012@vicerveza.homeunix.net> Hello, the configure script sets up CRYPTLIB="-lcrypt". Then, Makefile.in has something like: dropbearobjs=$(COMMONOBJS) $(CLISVROBJS) $(SVROBJS) @CRYPTLIB@ dropbear: $(dropbearobjs) How is this expected to work? I can't build dropbear due to GNU make not finding the dependency "-lcrypt". Regards, Llu?s. From paul at mad-scientist.net Wed Jun 19 04:20:52 2013 From: paul at mad-scientist.net (Paul Smith) Date: Tue, 18 Jun 2013 16:20:52 -0400 Subject: -lcrypt as dependency in Makefile? (CRYPTLIB) In-Reply-To: <20130618201135.GT19012@vicerveza.homeunix.net> References: <20130618201135.GT19012@vicerveza.homeunix.net> Message-ID: <1371586852.14643.327.camel@pdsdesk> On Tue, 2013-06-18 at 22:11 +0200, Llu?s Batlle i Rossell wrote: > Hello, > > the configure script sets up CRYPTLIB="-lcrypt". > > Then, Makefile.in has something like: > dropbearobjs=$(COMMONOBJS) $(CLISVROBJS) $(SVROBJS) @CRYPTLIB@ > dropbear: $(dropbearobjs) > > How is this expected to work? I can't build dropbear due to GNU make not > finding the dependency "-lcrypt". GNU make supports this syntax. See: http://www.gnu.org/software/make/manual/html_node/Libraries_002fSearch.html If you're getting an error the make cannot find your crypt library in the normal locations, with the standard naming conventions. One issue is that GNU make hasn't kept up with all the advancements related to multiarch environments so if your system uses /lib64 etc. you may need to set up a VPATH search to find the system libraries. From viric at viric.name Wed Jun 19 05:31:35 2013 From: viric at viric.name (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Tue, 18 Jun 2013 23:31:35 +0200 Subject: Fixing crash on -J (proxycmd) In-Reply-To: <20130617195145.GI19012@vicerveza.homeunix.net> References: <20130617192154.GH19012@vicerveza.homeunix.net> <20130617195145.GI19012@vicerveza.homeunix.net> Message-ID: <20130618213135.GV19012@vicerveza.homeunix.net> On Mon, Jun 17, 2013 at 09:51:45PM +0200, Llu?s Batlle i Rossell wrote: > On Mon, Jun 17, 2013 at 09:21:54PM +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. From cickumqt at gmail.com Wed Jun 19 12:24:58 2013 From: cickumqt at gmail.com (Christopher Meng) Date: Wed, 19 Jun 2013 12:24:58 +0800 Subject: -lcrypt as dependency in Makefile? (CRYPTLIB) In-Reply-To: <1371586852.14643.327.camel@pdsdesk> References: <20130618201135.GT19012@vicerveza.homeunix.net> <1371586852.14643.327.camel@pdsdesk> Message-ID: HI Llu?s, Tell us your operating system's name and version. Thanks. From viric at viric.name Wed Jun 19 17:50:18 2013 From: viric at viric.name (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Wed, 19 Jun 2013 11:50:18 +0200 Subject: -lcrypt as dependency in Makefile? (CRYPTLIB) In-Reply-To: References: <20130618201135.GT19012@vicerveza.homeunix.net> <1371586852.14643.327.camel@pdsdesk> Message-ID: <20130619095018.GX19012@vicerveza.homeunix.net> Hello Christopher, On Wed, Jun 19, 2013 at 12:24:58PM +0800, Christopher Meng wrote: > Tell us your operating system's name and version. > > Thanks. It's all solved with VPATH; I was updating dropbear on nixpkgs (nixos.org/nixpkgs), and fixing it for both native and cross building. https://github.com/NixOS/nixpkgs/commit/ae98b6185051ed0a5b7636dc85b696112910e1e8 Regards, Llu?s. From valliappan at tinkerstuff.com Wed Jun 26 14:53:33 2013 From: valliappan at tinkerstuff.com (Valliappan Muthiah) Date: Wed, 26 Jun 2013 14:53:33 +0800 Subject: scp to always accept unknown remote hostkey Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130626/8183863b/attachment.htm