From rob at landley.net Fri Jul 1 08:43:05 2011 From: rob at landley.net (Rob Landley) Date: Thu, 30 Jun 2011 19:43:05 -0500 Subject: dropbear and -lcrypt In-Reply-To: <20110630144310.GF30714@ucc.gu.uwa.edu.au> References: <4D802987.2070001@gentoo.org> <4E07D1EF.8070704@landley.net> <20110630144310.GF30714@ucc.gu.uwa.edu.au> Message-ID: <4E0D1819.1030205@landley.net> On 06/30/2011 09:43 AM, Matt Johnston wrote: >> I use the attached patch to build a static dropbear 0.53.1 in Aboriginal >> Linux. I have no idea if it's the _right_ fix because autoconf is an >> abomination that dropbear didn't used to use, but which it got infected >> by a few years ago for no obvious reason. > > Dropbear has used autoconf since the first public release in > 2003*, mainly just for differences on non-Linux unixes. *shrug* Possibly the Linux build didn't use it in previous releases? (I remember you had to edit options by hand...) > The build's a bit horrible, but that's all just GNU make. I've been talking with several people about trying to find some replacement for the giant harball of autoconf/automake/gmake/libtool the way git replaced CVS. Alas, the tool we need doesn't exist yet, and convincing a big project like Linux to switch over to provide an example to everybody else will be a hard sell if Linus Torvalds doesn't personally write said tool again... But we live in hope. :) Rob From rob at landley.net Fri Jul 1 23:50:13 2011 From: rob at landley.net (Rob Landley) Date: Fri, 01 Jul 2011 10:50:13 -0500 Subject: dropbear and -lcrypt In-Reply-To: <20110630144434.GG30714@ucc.gu.uwa.edu.au> References: <4D802987.2070001@gentoo.org> <4E07D1EF.8070704@landley.net> <20110630144310.GF30714@ucc.gu.uwa.edu.au> <20110630144434.GG30714@ucc.gu.uwa.edu.au> Message-ID: <4E0DECB5.6040105@landley.net> On 06/30/2011 09:44 AM, Matt Johnston wrote: > On Thu, Jun 30, 2011 at 10:43:10PM +0800, Matt Johnston wrote: >> Yes, that was a bit unfortunate. I've attached a patch that > > Here's the patch, missed it. > > Matt It worked for me. Rob From rob at landley.net Tue Jul 5 09:56:28 2011 From: rob at landley.net (Rob Landley) Date: Mon, 04 Jul 2011 20:56:28 -0500 Subject: no newline at teh end of list.h? Message-ID: <4E126F4C.7010008@landley.net> I'm getting a lot of these warnings: gcc -I./libtomcrypt/src/headers/ -I. -I. -I ../zlib -Os -DDROPBEAR_SERVER -DDROPBEAR_CLIENT -DPROGRESS_METER -DDBMULTI_dropbear -DDBMULTI_dbclient -DDBMULTI_dropbearkey -DDBMULTI_dropbearconvert -DDBMULTI_scp -DDROPBEAR_MULTI -c -o fake-rfc2553.o fake-rfc2553.c In file included from tcpfwd.h:28, from runopts.h:32, from common-runopts.c:26: list.h:28:30: warning: no newline at end of file That look familiar to anybody else? Rob From dropbear at guylhem.net Wed Jul 6 17:33:47 2011 From: dropbear at guylhem.net (Guylhem Aznar) Date: Wed, 6 Jul 2011 05:33:47 -0400 Subject: can't do local port forwarding / question Message-ID: Hello To save memory, I am trying to replace openssh-server by dropbear on a small VPS (openvz) where I mostly run connectivity tools like tinyproxy (http proxy). However I just can't make port forwarding work. To make sure the issue came from dropbear, I tried with tinyproxy listening on port 3128, dropbear running on port 220 and openssh-server running on port 222: "ssh -p 222 -L 1938:localhost:1938" works, ie I can use localhost:3128 on my browser to access the net. I checked with sites showing the ip - I'm using the VPS IP. "ssh -p 220 -L 1938:localhost:1938" doesn't works, I can't access the net with localhost:3128. When I do, and I see errors such as : channel 9: open failed: connect failed: channel 7: open failed: connect failed: channel 8: open failed: connect failed: channel 9: open failed: connect failed: I'm running dropbear with : /usr/sbin/dropbear -d /etc/dropbear/dropbear_dss_host_key -r /etc/dropbear/dropbear_rsa_host_key -p 127.0.0.1:22 -W 65536 -p 220 -a I though "-a" was everything I needed. I tried to look on google with the error message and various keywords such as dropbear port forwarding but couldn't find anything. I've spend half a day on that, and it still doesn't work, so any help would be welcome. I think I can't use remote port forwarding because I'm behind a NAT At the moment, I believe the option to forward local ports is not supported - like the export of the local and remote IP in "$SSH_CONNECTION", something that could be interesting to add for login shell scripts. BTW Is this SSH_CONNECTION feature planned? Thanks Guylhem From matt at ucc.asn.au Wed Jul 6 21:30:51 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 6 Jul 2011 21:30:51 +0800 Subject: can't do local port forwarding / question In-Reply-To: References: Message-ID: <20110706133051.GC30714@ucc.gu.uwa.edu.au> On Wed, Jul 06, 2011 at 05:33:47AM -0400, Guylhem Aznar wrote: > However I just can't make port forwarding work. To make sure the issue > came from dropbear, I tried with tinyproxy listening on port 3128, > dropbear running on port 220 and openssh-server running on port 222: ... > channel 9: open failed: connect failed: > channel 7: open failed: connect failed: > channel 9: open failed: connect failed: ... > BTW Is this SSH_CONNECTION feature planned? Try running dropbear with '-F -E' and see if it prints any error messages. I don't see why it wouldn't work, though did you mean "-L 1938:localhost:3128", and "localhost:1938" in the browser? You shouldn't need -a as an option since you're connecting to localhost. Which version of Dropbear are you using? $SSH_CONNECTION was added in 0.53. Cheers, Matt From dropbear at guylhem.net Thu Jul 7 03:28:16 2011 From: dropbear at guylhem.net (Guylhem Aznar) Date: Wed, 6 Jul 2011 15:28:16 -0400 Subject: can't do local port forwarding / question In-Reply-To: <20110706133051.GC30714@ucc.gu.uwa.edu.au> References: <20110706133051.GC30714@ucc.gu.uwa.edu.au> Message-ID: Hello > Try running dropbear with '-F -E' and see if it prints any > error messages. I don't see why it wouldn't work, though Sorry, it doesnt (besides the usual messages such as No backgrouding, Child connection from..., pubkey auth succeeded) I just get errors like: # channel 5: open failed: connect failed: (full log send by private message to avoid clogging the list) > did you mean "-L 1938:localhost:3128", and "localhost:1938" > in the browser My mistake - it's a typo. Should be 3128 all the way, but your version should work too. I also tried in my .ssh/config LocalForward 3128 localhost:3128 It works with openssh, not with dropbear. I don't understand why. > You shouldn't need -a as an option since > you're connecting to localhost. It was just an wild attempt with command line options :-) > Which version of Dropbear are you using? $SSH_CONNECTION was > added in 0.53. It is 0.52, default from debian squeeze. I can try to 0.53 but unless that was tweaked I feed it won't work. Guylhem From dropbear at guylhem.net Thu Jul 7 11:06:58 2011 From: dropbear at guylhem.net (Guylhem Aznar) Date: Wed, 6 Jul 2011 23:06:58 -0400 Subject: can't do local port forwarding / question In-Reply-To: References: <20110706133051.GC30714@ucc.gu.uwa.edu.au> Message-ID: Hello Following closer examination, the difference was due to ipv6 connectivity : with localhost defined both to 127.0r.0.1 and ::1 in /etc/hosts on the server, dropbear used ::1 because due to some VPS tweaks it occurred in the file before 127.0.0.1 did. (the hosting companies overwrites and messed up some files like /etc/hosts and /etc/interfaces - I had only known about the latter until now) My solution was to comment that out, and hope it will survive their tweaks. If it doesn't, I'll define 127.0.0.1 in the .ssh/config. Thanks a lot for the help! Guylhem From sshore at iders.ca Thu Jul 7 22:30:57 2011 From: sshore at iders.ca (Scottie Shore) Date: Thu, 7 Jul 2011 14:30:57 +0000 Subject: [PATCH] Fix dropbearmulti install when using DESTDIR Message-ID: Hello, I've noticed that the "installdropbearmulti" target creates symlinks that point to a path relative to $DESTDIR. The attached patch correctly creates symlinks that point to a path relative to /. This patch also creates $DESTDIR/$sbindir and $DESTDIR/$bindir before trying to create symlinks in them. Makefile.in is the only file modified by this patch. If there are any questions, please CC me on replies, as I am not subscribed. Thanks! Scottie Shore iders, inc. Scottie Shore Embedded Software Developer Iders Incorporated 27047 Oakwood Road Oakbank, MB R0E 1J2 Tel (204) 444-5200 ext 282 Fax: (204) 444-5900 [http://www.iders.ca/IDERS_logo.jpg] ________________________________ Iders Incorporated Confidential: ________________________________ This message is intended solely for the use of the designated recipient(s) and their appointed delegates, and may contain confidential information. Any unauthorized disclosure, copying or distribution of its contents is strictly prohibited. If you have received this message in error, please destroy it and advise the sender immediately by phone, Email or facsimile. -------------- next part -------------- A non-text attachment was scrubbed... Name: dropbear.patch Type: text/x-patch Size: 1032 bytes Desc: dropbear.patch Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20110707/7f7d84dc/attachment.bin From dropbear at guylhem.net Sun Jul 17 09:41:15 2011 From: dropbear at guylhem.net (Guylhem Aznar) Date: Sat, 16 Jul 2011 21:41:15 -0400 Subject: ipv6 listen Message-ID: Hello With debian squeeze default dropbear version (v0.52) , I was looking for a way to listen to connections on ipv6 addresses. There seems to be patches proposed on https://lists.openwrt.org/pipermail/openwrt-devel/2009-May/004299.html but I was too lazy tonite. So I did something simpler : running with -p fqdn:22 where fqdn only has a AAAA record defined (no A record). Hopefully it will save some time to someone else :-) Guylhem From codecomplete at free.fr Mon Jul 18 22:02:33 2011 From: codecomplete at free.fr (Gilles) Date: Mon, 18 Jul 2011 16:02:33 +0200 Subject: [0.51] Can I remove dbclient? Message-ID: Hello On an appliance, I noticed that "dblclient" and "dropbearmulti" are duplicates: ======== >root:/bin> ls -il d* 347 -rwxr-xr-x 1 root root 187100 Jun 3 2008 dbclient 352 lrwxrwxrwx 1 root root 18 Jan 1 00:07 dropbear -> /bin/dropbearmulti 353 lrwxrwxrwx 1 root root 18 Jan 1 00:07 dropbearkey -> /bin/dropbearmulti 344 -rwxr-xr-x 1 root root 187100 Jun 3 2008 dropbearmulti ======== To save space, can I safely remove "dbclient" and simply create a symlink to "dropbearmulti"? Thank you. From matt at ucc.asn.au Mon Jul 18 23:50:46 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 18 Jul 2011 23:50:46 +0800 Subject: [0.51] Can I remove dbclient? In-Reply-To: References: Message-ID: <20110718155046.GE30714@ucc.gu.uwa.edu.au> Hi, I don't know what your appliance's manufacturer has done, what device it? I would think you can probably create the symlink, though it'd depend how things were built. Matt On Mon, Jul 18, 2011 at 04:02:33PM +0200, Gilles wrote: > Hello > > On an appliance, I noticed that "dblclient" and "dropbearmulti" are > duplicates: > > ======== > >root:/bin> ls -il d* > 347 -rwxr-xr-x 1 root root 187100 Jun 3 2008 dbclient > > 352 lrwxrwxrwx 1 root root 18 Jan 1 00:07 dropbear > -> /bin/dropbearmulti > > 353 lrwxrwxrwx 1 root root 18 Jan 1 00:07 > dropbearkey -> /bin/dropbearmulti > > 344 -rwxr-xr-x 1 root root 187100 Jun 3 2008 > dropbearmulti > ======== > > To save space, can I safely remove "dbclient" and simply create a > symlink to "dropbearmulti"? > > Thank you. > From codecomplete at free.fr Tue Jul 19 03:35:47 2011 From: codecomplete at free.fr (Gilles) Date: Mon, 18 Jul 2011 21:35:47 +0200 Subject: [0.51] Can I remove dbclient? References: <20110718155046.GE30714@ucc.gu.uwa.edu.au> Message-ID: Hello On Mon, 18 Jul 2011 23:50:46 +0800, Matt Johnston wrote: >I don't know what your appliance's manufacturer has done, >what device it? I would think you can probably create the >symlink, though it'd depend how things were built. It's part of uClinux-dist. I guess I'll just delete dbclient, create a symlink to dropbearmulti instead, and see how it goes. Thanks. From cubemug at 818gift.com Mon Aug 1 02:40:21 2011 From: cubemug at 818gift.com (Cube Mug) Date: Mon, 1 Aug 2011 02:40:21 +0800 (CST) Subject: [SPAM]TwinTessentials booth in 2011 Reed Gift Fair Melbourne - To : dropbear@ucc.asn.au Message-ID: <29411320.1011461312137621236.JavaMail.mailer@voxel> 2011 Reed Gift Fair Melbourne News product : CUBE MUG Date : August 6-10, 2011 Booth Name: TwinTessentials Booth Number: W1086 Hall: Exhibit A at the Melbourne Showgrounds Expo runs : 9am to 6pm on the 6-9th August 2011 9am to 3pm on the 10th August 2011 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20110801/8f762bab/attachment-0001.htm From ska-dietlibc at skarnet.org Wed Aug 3 18:25:09 2011 From: ska-dietlibc at skarnet.org (Laurent Bercot) Date: Wed, 3 Aug 2011 12:25:09 +0200 Subject: [PATCH] Compilation fix when ENABLE_CLI_AGENTFWD undefined Message-ID: <20110803102509.GA5532@skarnet.org> Hello, (I just subscribed to the list, so the following points might already have been addressed; sorry if it's the case.) Here is a patch for dropbear-0.53.1 that fixes a compilation and linking issue that currently comes up when ENABLE_CLI_AGENTFWD is not defined at all. Only the cli-authpubkey.c file is touched. Matt, please review, and apply if it's correct. :) Also, please note that "make distclean", after a dropbear build, fails to remove the following files: - config.log - config.status - libtomcrypt/Makefile - libtommath/Makefile I did not provide a patch for this because it could be intentional; if it is not, please fix it too for completeness. -- Laurent -------------- next part -------------- diff -rNU3 dropbear-0.53.1.old/cli-authpubkey.c dropbear-0.53.1/cli-authpubkey.c --- dropbear-0.53.1.old/cli-authpubkey.c 2011-03-02 14:23:35.000000000 +0100 +++ dropbear-0.53.1/cli-authpubkey.c 2011-07-29 12:52:19.000000000 +0200 @@ -123,6 +123,7 @@ void cli_buf_put_sign(buffer* buf, sign_key *key, int type, const unsigned char *data, unsigned int len) { +#ifdef ENABLE_CLI_AGENTFWD if (key->source == SIGNKEY_SOURCE_AGENT) { /* Format the agent signature ourselves, as buf_put_sign would. */ buffer *sigblob; @@ -134,9 +135,11 @@ buf_free(sigblob); } else { +#endif buf_put_sign(buf, key, type, data, len); +#ifdef ENABLE_CLI_AGENTFWD } - +#endif } /* TODO: make it take an agent reference to use as well */ @@ -186,13 +189,13 @@ int cli_auth_pubkey() { TRACE(("enter cli_auth_pubkey")) - +#ifdef ENABLE_CLI_AGENTFWD if (!cli_opts.agent_keys_loaded) { /* get the list of available keys from the agent */ cli_load_agent_keys(cli_opts.privkeys); cli_opts.agent_keys_loaded = 1; } - +#endif if (cli_opts.privkeys->first) { sign_key * key = (sign_key*)cli_opts.privkeys->first->item; /* Send a trial request */ From lists at wildgooses.com Fri Aug 12 17:37:54 2011 From: lists at wildgooses.com (Ed W) Date: Fri, 12 Aug 2011 10:37:54 +0100 Subject: Support for ecdsa certs Message-ID: <4E44F472.2020809@wildgooses.com> Hi, What is required to extend dropbear to support ecdsa certificates - I'm mainly interested in the client support, but server support would be nice also? Thanks Ed W From dropbear at guylhem.net Mon Aug 22 14:18:07 2011 From: dropbear at guylhem.net (Guylhem Aznar) Date: Mon, 22 Aug 2011 02:18:07 -0400 Subject: delay question Message-ID: Hello ssh to a dropbear server takes several seconds - which can be shaved on a openssh server by disabling dns lookup. Is it possible in dropbear to reduce the connection delay in a similar manner? What else is causing the delays in a passwordless connection? Has a patch been proposed? Thanks Guylhem From stalkerboi at gmail.com Tue Aug 23 11:26:03 2011 From: stalkerboi at gmail.com (Amer) Date: Tue, 23 Aug 2011 11:26:03 +0800 Subject: Dropbear ignores some env variables Message-ID: Hello. I just started using dropbear (compiled from latest source) only recently so pardon me if this has been brought up before I noticed that on some distro, debian based ones mainly such as Ubuntu, dropbear doesn't read and set environment variables like PATH and locales. When I access my server via dropbear, I found out that my locales weren't correctly set. Same with PATH. This however doesn't happen if I log in through openssh. Is this a known issue? From rob at landley.net Wed Aug 24 02:50:03 2011 From: rob at landley.net (Rob Landley) Date: Tue, 23 Aug 2011 13:50:03 -0500 Subject: delay question In-Reply-To: References: Message-ID: <4E53F65B.1050107@landley.net> On 08/22/2011 01:18 AM, Guylhem Aznar wrote: > Hello > > ssh to a dropbear server takes several seconds - which can be shaved > on a openssh server by disabling dns lookup. > > Is it possible in dropbear to reduce the connection delay in a similar manner? > What else is causing the delays in a passwordless connection? In options.h search for #define DO_HOST_LOOKUP and comment it out. It's a compile-time option. Rob From rob at landley.net Wed Aug 24 02:56:19 2011 From: rob at landley.net (Rob Landley) Date: Tue, 23 Aug 2011 13:56:19 -0500 Subject: Dropbear ignores some env variables In-Reply-To: References: Message-ID: <4E53F7D3.8030700@landley.net> On 08/22/2011 10:26 PM, Amer wrote: > Hello. I just started using dropbear (compiled from latest source) > only recently so pardon me if this has been brought up before > > I noticed that on some distro, debian based ones mainly such as > Ubuntu, dropbear doesn't read and set environment variables like PATH > and locales. > > When I access my server via dropbear, I found out that my > locales weren't correctly set. Same with PATH. This however doesn't > happen if I log in through openssh. > > Is this a known issue? That's not dropbear, that's your shell. Whether it reads /etc/profile or ~./.bash_profile or what are dependent on how it's invoke, the main distinction being whether it's a "login" shell or not. (Login shells initialize their full environment by running magic shell scripts behidn the scenes, like the ones listed above. Shells called to run shell scripts and such mostly don't, although actually they just read _other_ setup scripts which are usually blank or don't contain so much baggage.) Sounds like openssh is running its shells as login shells when it isn't given a command line, and dropbear isn't. Try adding -l to your shell invocation and see what happens. (go "man bash", hit forward slash, and search for "login". I note that if you're using dash, Ubuntu's Defective Annoying SHell, you're on your own. That thing was a bad idea in the first place.) Rob From dropbear at guylhem.net Wed Aug 24 06:49:42 2011 From: dropbear at guylhem.net (Guylhem Aznar) Date: Tue, 23 Aug 2011 18:49:42 -0400 Subject: delay question In-Reply-To: <4E53F65B.1050107@landley.net> References: <4E53F65B.1050107@landley.net> Message-ID: Hello On Tue, Aug 23, 2011 at 14:50, Rob Landley wrote: > In options.h search for #define DO_HOST_LOOKUP and comment it out. > It's a compile-time option. Oops :-) Thanks for the hint! However a 5 seconds delay remains: Aug 23 18:37:41 dropbear[6505]: Child connection from (...) Aug 23 18:37:45 dropbear[6505]: Pubkey auth succeeded for (...) Any suggestion? From lists at wildgooses.com Wed Aug 24 17:58:03 2011 From: lists at wildgooses.com (Ed W) Date: Wed, 24 Aug 2011 10:58:03 +0100 Subject: delay question In-Reply-To: References: <4E53F65B.1050107@landley.net> Message-ID: <4E54CB2B.9030302@wildgooses.com> On 23/08/2011 23:49, Guylhem Aznar wrote: > Hello > > On Tue, Aug 23, 2011 at 14:50, Rob Landley wrote: >> In options.h search for #define DO_HOST_LOOKUP and comment it out. >> It's a compile-time option. > Oops :-) Thanks for the hint! > > However a 5 seconds delay remains: > > Aug 23 18:37:41 dropbear[6505]: Child connection from (...) > Aug 23 18:37:45 dropbear[6505]: Pubkey auth succeeded for (...) > > Any suggestion? strace and tcpdump it? Ed From matt at ucc.asn.au Wed Aug 24 19:46:21 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 24 Aug 2011 19:46:21 +0800 Subject: delay question In-Reply-To: References: <4E53F65B.1050107@landley.net> Message-ID: <20110824114621.GA6446@ucc.gu.uwa.edu.au> On Tue, Aug 23, 2011 at 06:49:42PM -0400, Guylhem Aznar wrote: > However a 5 seconds delay remains: > > Aug 23 18:37:41 dropbear[6505]: Child connection from (...) > Aug 23 18:37:45 dropbear[6505]: Pubkey auth succeeded for (...) > > Any suggestion? A slow CPU could take 5 seconds to do the big-number maths for the key exchange. Is CPU usage high, and what processor is it using? Cheers, Matt From matt at ucc.asn.au Wed Aug 24 19:50:33 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 24 Aug 2011 19:50:33 +0800 Subject: Dropbear ignores some env variables In-Reply-To: References: Message-ID: <20110824115033.GB6446@ucc.gu.uwa.edu.au> On Tue, Aug 23, 2011 at 11:26:03AM +0800, Amer wrote: > Hello. I just started using dropbear (compiled from latest source) > only recently so pardon me if this has been brought up before > > I noticed that on some distro, debian based ones mainly such as > Ubuntu, dropbear doesn't read and set environment variables like PATH > and locales. When I access my server via dropbear, I found out that my > locales weren't correctly set. Same with PATH. This however doesn't > happen if I log in through openssh. > > Is this a known issue? I think those are set for OpenSSH (and other login modes) by /etc/pam.d/login. Currently Dropbear doesn't have much PAM support (just enough for User:/Password: challenge response authentication) since the API isn't very pleasant. https://bugs.launchpad.net/ubuntu/+source/dropbear/+bug/232064 looks like this problem. Cheers, Matt From matt at ucc.asn.au Wed Aug 24 19:54:43 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 24 Aug 2011 19:54:43 +0800 Subject: Support for ecdsa certs In-Reply-To: <4E44F472.2020809@wildgooses.com> References: <4E44F472.2020809@wildgooses.com> Message-ID: <20110824115442.GC6446@ucc.gu.uwa.edu.au> Hi, Sorry for the delayed reply. I have a very brief look at it. The actual SSH protocol parts probably aren't too hard to implement, just some similar bits to the existing code in *kex.c and dsa.c. However I don't know how good libtomcrypt and libtommath's ECC support is, so possibly that could be a problem. Cheers, Matt On Fri, Aug 12, 2011 at 10:37:54AM +0100, Ed W wrote: > Hi, What is required to extend dropbear to support ecdsa certificates - > I'm mainly interested in the client support, but server support would be > nice also? > > Thanks > > Ed W From lists at wildgooses.com Wed Aug 24 20:03:11 2011 From: lists at wildgooses.com (Ed W) Date: Wed, 24 Aug 2011 13:03:11 +0100 Subject: Support for ecdsa certs In-Reply-To: <20110824115442.GC6446@ucc.gu.uwa.edu.au> References: <4E44F472.2020809@wildgooses.com> <20110824115442.GC6446@ucc.gu.uwa.edu.au> Message-ID: <4E54E87F.3050309@wildgooses.com> Hi, assuming what you say isn't a complete blocker - are you open to "sponsorship" to add it as a feature? Cheers Ed W On 24/08/2011 12:54, Matt Johnston wrote: > Hi, > > Sorry for the delayed reply. I have a very brief look at it. > The actual SSH protocol parts probably aren't too hard to > implement, just some similar bits to the existing code in > *kex.c and dsa.c. However I don't know how good > libtomcrypt and libtommath's ECC support is, so possibly > that could be a problem. > > Cheers, > Matt > > On Fri, Aug 12, 2011 at 10:37:54AM +0100, Ed W wrote: >> Hi, What is required to extend dropbear to support ecdsa certificates - >> I'm mainly interested in the client support, but server support would be >> nice also? >> >> Thanks >> >> Ed W From matt at ucc.asn.au Wed Aug 24 20:22:47 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 24 Aug 2011 20:22:47 +0800 Subject: Support for ecdsa certs In-Reply-To: <4E54E87F.3050309@wildgooses.com> References: <4E44F472.2020809@wildgooses.com> <20110824115442.GC6446@ucc.gu.uwa.edu.au> <4E54E87F.3050309@wildgooses.com> Message-ID: <20110824122247.GD6446@ucc.gu.uwa.edu.au> It's a feature I'd like to add, I'll take a look at how much is involved and get back to you off-list. Cheers, Matt On Wed, Aug 24, 2011 at 01:03:11PM +0100, Ed W wrote: > Hi, assuming what you say isn't a complete blocker - are you open to > "sponsorship" to add it as a feature? > > Cheers > > Ed W > > > On 24/08/2011 12:54, Matt Johnston wrote: > > Hi, > > > > Sorry for the delayed reply. I have a very brief look at it. > > The actual SSH protocol parts probably aren't too hard to > > implement, just some similar bits to the existing code in > > *kex.c and dsa.c. However I don't know how good > > libtomcrypt and libtommath's ECC support is, so possibly > > that could be a problem. > > > > Cheers, > > Matt > > > > On Fri, Aug 12, 2011 at 10:37:54AM +0100, Ed W wrote: > >> Hi, What is required to extend dropbear to support ecdsa certificates - > >> I'm mainly interested in the client support, but server support would be > >> nice also? > >> > >> Thanks > >> > >> Ed W > From dropbear at guylhem.net Thu Aug 25 01:00:34 2011 From: dropbear at guylhem.net (Guylhem Aznar) Date: Wed, 24 Aug 2011 13:00:34 -0400 Subject: delay question In-Reply-To: <20110824114621.GA6446@ucc.gu.uwa.edu.au> References: <4E53F65B.1050107@landley.net> <20110824114621.GA6446@ucc.gu.uwa.edu.au> Message-ID: Hello On Wed, Aug 24, 2011 at 07:46, Matt Johnston wrote: > A slow CPU could take 5 seconds to do the big-number maths > for the key exchange. Is CPU usage high, and what processor > is it using? CPU is 85% idle, and is: # cat /proc/cpuinfo system type : Ikanos Fusiv Core processor : 0 cpu model : MIPS 24K V4.12 BogoMIPS : 330.75 wait instruction : yes unaligned_instructions : 1542619 microsecond timers : yes tlb_entries : 64 extra interrupt vector : yes hardware watchpoint : yes ASEs implemented : mips16 dsp VCED exceptions : not available VCEI exceptions : not available strace started as: ~guylhem/sbin/strace -f -c ~guylhem/bin/chroot ~guylhem /bin/dropbear -b /etc/dropbear/banner.txt -d /etc/dropbear/sshd_dsa_host_key -r /etc/dropbear/sshd_rsa_host_key -m 2 -F reports: % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 75.88 0.000667 334 2 1 bind 24.12 0.000212 27 8 close 0.00 0.000000 0 1 fork With: ~guylhem/sbin/strace -f -ff -r ~guylhem/bin/chroot ~guylhem /bin/dropbear -b /etc/dropbear/banner.txt -d /etc/dropbear/sshd_dsa_host_key -r /etc/dropbear/sshd_rsa_host_key -m 2 -F I see (xxx is the client ipv6): [pid 12140] 6.115917 accept(3, {sa_family=AF_INET6, sin6_port=htons(55563), inet_pton(AF_INET6, "xxxxxxxxxxxxx", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 5 [pid 12140] 0.001617 pipe([6, 7]) = 6 [pid 12140] 0.001625 fork(Process 12171 attached ) = 12171 [pid 12140] 0.006739 close(7) = 0 [pid 12140] 0.001669 close(5) = 0 [pid 12140] 0.000427 _newselect(7, [3 6], NULL, NULL, NULL) = 1 (in [6]) [pid 12140] 3.723798 close(6) = 0 The 6 seconds are the delay between starting the strace and the ssh client. The 3.72 second in the close seems to be the delay I am experiencing (tested several times) There is do difference with a ssh -4 or a ssh -6. With tcpdump, I see a packet containing diffie-hellman-group-1 sent by the dropbear server, 2 packets returned by the client, one being sent by the dropbear server .... then the next one being send approx 4 seconds later. I can send you a .cap if you want I am not sure what to make of these results. The "close" seems to be taking a lot of time. Guylhem From rob at landley.net Thu Aug 25 22:28:47 2011 From: rob at landley.net (Rob Landley) Date: Thu, 25 Aug 2011 09:28:47 -0500 Subject: delay question In-Reply-To: References: <4E53F65B.1050107@landley.net> <20110824114621.GA6446@ucc.gu.uwa.edu.au> Message-ID: <4E565C1F.4030301@landley.net> On 08/24/2011 12:00 PM, Guylhem Aznar wrote: > Hello > > On Wed, Aug 24, 2011 at 07:46, Matt Johnston wrote: >> A slow CPU could take 5 seconds to do the big-number maths >> for the key exchange. Is CPU usage high, and what processor >> is it using? > > CPU is 85% idle, and is: > > # cat /proc/cpuinfo > system type : Ikanos Fusiv Core > processor : 0 > cpu model : MIPS 24K V4.12 > BogoMIPS : 330.75 ... > ~guylhem/sbin/strace -f -ff -r ~guylhem/bin/chroot ~guylhem > /bin/dropbear -b /etc/dropbear/banner.txt -d > /etc/dropbear/sshd_dsa_host_key -r /etc/dropbear/sshd_rsa_host_key -m > 2 -F > I see (xxx is the client ipv6): > > [pid 12140] 6.115917 accept(3, {sa_family=AF_INET6, > sin6_port=htons(55563), inet_pton(AF_INET6, "xxxxxxxxxxxxx", > &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 5 > [pid 12140] 0.001617 pipe([6, 7]) = 6 > [pid 12140] 0.001625 fork(Process 12171 attached > ) = 12171 > [pid 12140] 0.006739 close(7) = 0 > [pid 12140] 0.001669 close(5) = 0 > [pid 12140] 0.000427 _newselect(7, [3 6], NULL, NULL, NULL) = 1 (in [6]) > [pid 12140] 3.723798 close(6) = 0 > > The 6 seconds are the delay between starting the strace and the ssh > client. You have a 6 second delay starting the ssh client, before it actually makes a system call for strace to report? Are you, perchance, running on NFS? > The 3.72 second in the close seems to be the delay I am > experiencing (tested several times) That delay is it waiting on a pipe to the child process. Might be nice to know which child process > > There is do difference with a ssh -4 or a ssh -6. > > With tcpdump, I see a packet containing diffie-hellman-group-1 sent by > the dropbear server, 2 packets returned by the client, one being sent > by the dropbear server .... then the next one being send approx 4 > seconds later. I can send you a .cap if you want > > I am not sure what to make of these results. The "close" seems to be > taking a lot of time. On NFS close is a horrible synchronous operation with a built in flush. Running on NFS is pretty much the only time where close() can return a nonzero error code, which is funny because what are you supposed to DO about it? Don't use NFS. Use v9fs with diod, or network block devices or ANYTHING else really. Even Samba/cifs is better than NFS. Random performance suckage with NFS is more or less normal. (Random failures with NFS are more or less normal.) Rob From dropbear at guylhem.net Fri Aug 26 01:43:28 2011 From: dropbear at guylhem.net (Guylhem Aznar) Date: Thu, 25 Aug 2011 13:43:28 -0400 Subject: delay question In-Reply-To: <4E565C1F.4030301@landley.net> References: <4E53F65B.1050107@landley.net> <20110824114621.GA6446@ucc.gu.uwa.edu.au> <4E565C1F.4030301@landley.net> Message-ID: Hello On Thu, Aug 25, 2011 at 10:28, Rob Landley wrote: >> I am not sure what to make of these results. The "close" seems to be >> taking a lot of time. > > Don't use NFS. Well, I don't! The DSL modem (Fritzbox 7390, quite popular in Australia IIRC) has a SD mounted as an ext2 partition. Everything I run is from this partition, and with a chroot. At the moment, from this chroot mount reports: $ mount rootfs on / type rootfs (rw) /dev/root on / type squashfs (ro) proc on /proc type proc (rw) ramfs on /var type ramfs (rw) /var/dev/nand on /var/media/ftp type yaffs2 (rw) /var/dev/nand on /data/tam type yaffs2 (rw) usbfs on /proc/bus/usb type usbfs (rw) sysfs on /sys type sysfs (rw) /dev/sda1 on /var/media/ftp/SanDisk-SDPlus-01 type ext2 (rw) devpts on /dev/pts type devpts (rw) procfs on /proc type proc (rw) sysfs on /sys type sysfs (rw) usbfs on /proc/bus/usb type usbfs (rw) There is no nfs. Dropbear is executed from within the chroot, to avoid any problem. I just don't understand why this close takes so much time. From acatton at tiolive.com Fri Aug 26 23:29:05 2011 From: acatton at tiolive.com (Antoine Catton) Date: Fri, 26 Aug 2011 17:29:05 +0200 Subject: Running dropbear as unprivileged user to a single user SSH Server Message-ID: <1314372545.11905.23.camel@localhost.localdomain> Hello everybody, I am currently trying to run dropbear as unprivileged user. And the user running it can't write or read in his home directory and have /bin/false shell. And I want to use RSA keys authentication (instead of password authentication) of course. Indeed, I would like to run dropbear as a simple SSH server, which would ignore username. This is the idea of the patch I'm currently writing : * Adding the option -u (which stand for ?user space?) for example. This option would be use this way : dropbear -u userdef_file * The ?userdef_file? would look like this : SHELL=/bin/bash HOME=/home/sample OTHER_ENV=foobar Of course, it would also override the home directory where to look for .ssh/authorized_keys. I think it could be useful for embedded devices to have dropbear running in user space and not supporting multiple user, and maybe for paranoid single user as well. I send this email to ask you if there is already a way to do that, and or if anyone is already writing this functionality? I don't want to duplicate the code. If not, is the way I want to do it wrong? If so, how should I do it? Do you have any suggestion, question ? Thank you. Regards, -- Antoine Catton Nexedi Intern From acatton at tiolive.com Mon Aug 29 17:05:02 2011 From: acatton at tiolive.com (Antoine Catton) Date: Mon, 29 Aug 2011 11:05:02 +0200 Subject: Running dropbear as unprivileged user to a single user SSH Server In-Reply-To: <1314372545.11905.23.camel@localhost.localdomain> References: <1314372545.11905.23.camel@localhost.localdomain> Message-ID: <1314608703.17296.10.camel@localhost.localdomain> Hello, On Fri, 2011-08-26 at 17:29 +0200, Antoine Catton wrote: > Indeed, I would like to run dropbear as a simple SSH server, which would > ignore username. This is the idea of the patch I'm currently writing : > > * Adding the option -u (which stand for ?user space?) for example. This > option would be use this way : dropbear -u userdef_file > * The ?userdef_file? would look like this : > SHELL=/bin/bash > HOME=/home/sample > OTHER_ENV=foobar > > Of course, it would also override the home directory where to look > for .ssh/authorized_keys. > I think the way I wanted to implement it is to complex. Instead of that, I?m adding an option ?-n?. I just looked for a letter which was not used yet. This option will get the SHELL, HOME, PASSWORD (if you don't want to use SSH Keys) from environment variable (for example DROPBEAR_SINGLEUSER_(HOME|PASSWORD|SHELL) ). This way, it won't be a bloatware feature. By the way, I had a simple question. For the moment, I downloaded the latest dropbear tarball [1] and start a git repo with it to develop. Is there a git/mercurial/whatever repo for Dropbear ? (The only repo I saw was the historical CVS one). Thank you. Regards, [1] -- Antoine Catton Nexedi Intern From acatton at tiolive.com Mon Aug 29 21:27:09 2011 From: acatton at tiolive.com (Antoine Catton) Date: Mon, 29 Aug 2011 15:27:09 +0200 Subject: Running dropbear as unprivileged user to a single user SSH Server In-Reply-To: <1314608703.17296.10.camel@localhost.localdomain> References: <1314372545.11905.23.camel@localhost.localdomain> <1314608703.17296.10.camel@localhost.localdomain> Message-ID: <1314624430.17296.21.camel@localhost.localdomain> Hi, Here is in attachement the patch I submit for your review. I wasn't able to figure out how to override the user password. So far, it only overrides home directory and shell, it also ignores the authentification username ; it logs in as the user running dropbear SSH server. Moreover, I'm not familiar with autoconf, I didn't know how to add options to ./configure enabling the right macros (ENABLE_SINGLEUSER and ENABLE_SINGLEUSER_ROOT). I hope you will be able to do that, or give me some advice to do it. Thank you, Regards, -- Antoine Catton Nexedi Intern -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Adding-single-user-mode-feature.patch Type: text/x-patch Size: 5236 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20110829/71975199/attachment.bin From lists at wildgooses.com Tue Aug 30 20:35:26 2011 From: lists at wildgooses.com (Ed W) Date: Tue, 30 Aug 2011 13:35:26 +0100 Subject: Support for ecdsa certs In-Reply-To: <20110824115442.GC6446@ucc.gu.uwa.edu.au> References: <4E44F472.2020809@wildgooses.com> <20110824115442.GC6446@ucc.gu.uwa.edu.au> Message-ID: <4E5CD90E.7080705@wildgooses.com> Hi > Sorry for the delayed reply. I have a very brief look at it. > The actual SSH protocol parts probably aren't too hard to > implement, just some similar bits to the existing code in > *kex.c and dsa.c. However I don't know how good > libtomcrypt and libtommath's ECC support is, so possibly > that could be a problem. Thanks for considering this, I notice that libtomcrypt *claims* to support ECC, so there at least seems some hope? Is there any straightforward way to emulate the code for a key exchange to see if it breaks? Just for reference, the end goal is that you can get quite a dramatic decrease in bandwidth used, with a few tweaks to the SSH config. If you sniff the exchange (which I'm sure you are very familiar with), then openssh spends most of it's startup bandwidth on sending a huge list of key exchange/mac/encryption options. By artificially limiting these to a subset that work with all my systems I can quite dramatically cut the bandwidth at connection (those reading at home, please try it, quite instructive). The trick is getting all the systems to support a reasonable subset of algorithms ... Obviously many folks don't care, but I am increasingly finding myself using cellular networks, then an extra couple of KB per connection, multiply up by some many connections a day and you are quickly into sensible bandwidth. Some of my systems are on satellite, where bandwidth has quite some cost At the moment I'm running some test openssh system with the following config: MACs umac-64 at openssh.com,hmac-sha1,hmac-md5 Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128 KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 I'm interested in comments/critique, but I would desire to reduce the KexAlgorithms further, ideally just the ecdh and the (mandatory?) dh option. Also the certs are somewhat smaller themselves with ecdsa. End result seems distinctly more snappy (I guess you can fit in the tcp slow start window?) Thanks for listening! Ed W From rob at landley.net Tue Aug 30 22:51:17 2011 From: rob at landley.net (Rob Landley) Date: Tue, 30 Aug 2011 09:51:17 -0500 Subject: Running dropbear as unprivileged user to a single user SSH Server In-Reply-To: <1314608703.17296.10.camel@localhost.localdomain> References: <1314372545.11905.23.camel@localhost.localdomain> <1314608703.17296.10.camel@localhost.localdomain> Message-ID: <4E5CF8E5.8040202@landley.net> On 08/29/2011 04:05 AM, Antoine Catton wrote: > Hello, > > On Fri, 2011-08-26 at 17:29 +0200, Antoine Catton wrote: >> Indeed, I would like to run dropbear as a simple SSH server, which would >> ignore username. This is the idea of the patch I'm currently writing : >> >> * Adding the option -u (which stand for ?user space?) for example. This >> option would be use this way : dropbear -u userdef_file >> * The ?userdef_file? would look like this : >> SHELL=/bin/bash >> HOME=/home/sample >> OTHER_ENV=foobar >> >> Of course, it would also override the home directory where to look >> for .ssh/authorized_keys. >> > > I think the way I wanted to implement it is to complex. Instead of that, > I?m adding an option ?-n?. I just looked for a letter which was not used > yet. This option will get the SHELL, HOME, PASSWORD (if you don't want > to use SSH Keys) from environment variable (for example > DROPBEAR_SINGLEUSER_(HOME|PASSWORD|SHELL) ). > This way, it won't be a bloatware feature. Sounds generally useful. Notes: A) DROPBEAR_ is already a reasonably unique prefix, does SINGLEUSER_ add anything? B) Do you want to blank them post-fork so they don't wind up passed through to the resulting client? > By the way, I had a simple question. For the moment, I downloaded the > latest dropbear tarball [1] and start a git repo with it to develop. > Is there a git/mercurial/whatever repo for Dropbear ? (The only repo I > saw was the historical CVS one). If Matt ever shared his repo, I never found it. I just fiddle with the release tarballs. Rob From rob at landley.net Tue Aug 30 22:53:20 2011 From: rob at landley.net (Rob Landley) Date: Tue, 30 Aug 2011 09:53:20 -0500 Subject: Running dropbear as unprivileged user to a single user SSH Server In-Reply-To: <1314624430.17296.21.camel@localhost.localdomain> References: <1314372545.11905.23.camel@localhost.localdomain> <1314608703.17296.10.camel@localhost.localdomain> <1314624430.17296.21.camel@localhost.localdomain> Message-ID: <4E5CF960.4090805@landley.net> On 08/29/2011 08:27 AM, Antoine Catton wrote: > Hi, > > Here is in attachement the patch I submit for your review. > I wasn't able to figure out how to override the user password. So far, > it only overrides home directory and shell, it also ignores the > authentification username ; it logs in as the user running dropbear SSH > server. I've bookmarked this to come back to, but I have to run to work now. > Moreover, I'm not familiar with autoconf, I didn't know how to add > options to ./configure enabling the right macros (ENABLE_SINGLEUSER and > ENABLE_SINGLEUSER_ROOT). > > I hope you will be able to do that, or give me some advice to do it. Autoconf is an abomination that dropbear never should have fallen into the clutches of. When I started using it, it didn't do that. > Thank you, > > Regards, Rob From rob at landley.net Wed Aug 31 19:46:38 2011 From: rob at landley.net (Rob Landley) Date: Wed, 31 Aug 2011 06:46:38 -0500 Subject: Running dropbear as unprivileged user to a single user SSH Server In-Reply-To: <1314624430.17296.21.camel@localhost.localdomain> References: <1314372545.11905.23.camel@localhost.localdomain> <1314608703.17296.10.camel@localhost.localdomain> <1314624430.17296.21.camel@localhost.localdomain> Message-ID: <4E5E1F1E.8020007@landley.net> On 08/29/2011 08:27 AM, Antoine Catton wrote: > Hi, > > Here is in attachement the patch I submit for your review. > I wasn't able to figure out how to override the user password. So far, > it only overrides home directory and shell, it also ignores the > authentification username ; it logs in as the user running dropbear SSH > server. > > Moreover, I'm not familiar with autoconf, I didn't know how to add > options to ./configure enabling the right macros (ENABLE_SINGLEUSER and > ENABLE_SINGLEUSER_ROOT). Why does ENABLE_SINGLEUSER_ROOT exist? If somebody can set environment variables for the root user, there's plenty of other stuff they can do, is there any point in switching this _off_ for root? What's the point of the log messages? (Isn't the point of dropbear that it's small and simple?) In generally you seem to be m_free()-ing a lot right before assigning it, but the context of the hunks you're inserting stuff in aren't doing m_free() before their assignments. Is there a reason for this? Just to look closer at one hunk: > username = buf_getstring(ses.payload, &userlen) > +#ifdef ENABLE_SINGLEUSER > + /* If userspace enabled, ignore username */ > + if (svr_opts.singleuser) { > + m_free(username); > + /* Get the current login of the user running dropbear */ > + username = m_strdup(getlogin()); > + } > +#endif /* ifdef ENABLE_SINGLEUSER */ 1) The comments don't add anything here. (If userspace enabled? Here's what getlogin() does? Here's the end of the #ifdef seven lines earlier?) 2) The first line of that hunk creates a copy of username, then you check if you need to free that copy and make a different copy. Seems like a waste of work to me? 3) The Linux kernel uses a trick where it #defines is_singleuser() in a header somewhere to either a constant 0 (so the compiler's dead code elimination chops out the code) or else to svr_opts.singleuser, so you could just do: if (is_singleuser()) { m_free(username); username = m_strdup(getlogin()); } else username = buf_getstring(ses.payload, &userlen); This is why Linux code isn't #ifdef salad. FYI. Rob From acatton at tiolive.com Wed Aug 31 20:55:18 2011 From: acatton at tiolive.com (Antoine Catton) Date: Wed, 31 Aug 2011 14:55:18 +0200 Subject: Running dropbear as unprivileged user to a single user SSH Server In-Reply-To: <4E5E1F1E.8020007@landley.net> References: <1314372545.11905.23.camel@localhost.localdomain> <1314608703.17296.10.camel@localhost.localdomain> <1314624430.17296.21.camel@localhost.localdomain> <4E5E1F1E.8020007@landley.net> Message-ID: <1314795320.17296.61.camel@localhost.localdomain> On Wed, 2011-08-31 at 06:46 -0500, Rob Landley wrote: > Why does ENABLE_SINGLEUSER_ROOT exist? If somebody can set environment > variables for the root user, there's plenty of other stuff they can do, > is there any point in switching this _off_ for root? > The point of my patch is to run dropbear as single user. So, when you log in ?singleuser dropbear?, you are logged as the user running dropbear. But if the user running dropbear is root, I thought it could be a security issue, and it could lead to my patch refusal. But if it's not, I can remove this part. > What's the point of the log messages? (Isn't the point of dropbear that > it's small and simple?) Actually, I got to admit it was for my personal need to have a feedback (not as developer, as user). But if it's not the point of dropbear, you're right, I should remove these log messages. > > In generally you seem to be m_free()-ing a lot right before assigning > it, but the context of the hunks you're inserting stuff in aren't doing > m_free() before their assignments. Is there a reason for this? Yes, most of my hunks are some value overriding. And this values are read from a buffer or something like that. Moreover, by reading these values, it goes forward on the buffer. So I kept the original code and overridden the values after it. And because this variables are already allocated, I did some m_free(). Maybe there's a nicer way to do it, I don't know. > > Just to look closer at one hunk: > > > username = buf_getstring(ses.payload, &userlen) > > +#ifdef ENABLE_SINGLEUSER > > + /* If userspace enabled, ignore username */ > > + if (svr_opts.singleuser) { > > + m_free(username); > > + /* Get the current login of the user running dropbear */ > > + username = m_strdup(getlogin()); > > + } > > +#endif /* ifdef ENABLE_SINGLEUSER */ > [...] > 2) The first line of that hunk creates a copy of username, then you > check if you need to free that copy and make a different copy. Seems > like a waste of work to me? As I wrote above, I?m overriding ?username? value. But this value is read from a buffer, so it goes forward on this buffer (in this case ses.payload). I got to admit I didn't read the whole code of Dropbear. But, I took a closer look, and I think instead of reading it and overriding it, I could go forward by using ?buf_incrpos(buffer *, int)?. > [...] Okay, I will modify my patch the way you want, and will submit it again. Regards, -- Antoine Catton Nexedi Intern From acatton at tiolive.com Wed Aug 31 21:30:06 2011 From: acatton at tiolive.com (Antoine Catton) Date: Wed, 31 Aug 2011 15:30:06 +0200 Subject: Running dropbear as unprivileged user to a single user SSH Server In-Reply-To: <4E5E1F1E.8020007@landley.net> References: <1314372545.11905.23.camel@localhost.localdomain> <1314608703.17296.10.camel@localhost.localdomain> <1314624430.17296.21.camel@localhost.localdomain> <4E5E1F1E.8020007@landley.net> Message-ID: <1314797407.17296.68.camel@localhost.localdomain> Hello, On Wed, 2011-08-31 at 06:46 -0500, Rob Landley wrote: > 1) The comments don't add anything here. (If userspace enabled? Here's > what getlogin() does? Here's the end of the #ifdef seven lines earlier?) > > 2) The first line of that hunk creates a copy of username, then you > check if you need to free that copy and make a different copy. Seems > like a waste of work to me? > > 3) The Linux kernel uses a trick where it #defines is_singleuser() in a > header somewhere to either a constant 0 (so the compiler's dead code > elimination chops out the code) or else to svr_opts.singleuser, so you > could just do: > > if (is_singleuser()) { > m_free(username); > username = m_strdup(getlogin()); > } else username = buf_getstring(ses.payload, &userlen); > I?m trying to improve my patch. But I just figured out I didn't really get what you wanted. Do you want me to not use C Preprocessor statements ? Do you want to enable root running dropbear in single user mode ? Could you tell me how should I improve this patch ? Thank you. Regards, -- Antoine Catton Nexedi Intern From rob at landley.net Fri Sep 2 00:26:14 2011 From: rob at landley.net (Rob Landley) Date: Thu, 01 Sep 2011 11:26:14 -0500 Subject: Running dropbear as unprivileged user to a single user SSH Server In-Reply-To: <1314797407.17296.68.camel@localhost.localdomain> References: <1314372545.11905.23.camel@localhost.localdomain> <1314608703.17296.10.camel@localhost.localdomain> <1314624430.17296.21.camel@localhost.localdomain> <4E5E1F1E.8020007@landley.net> <1314797407.17296.68.camel@localhost.localdomain> Message-ID: <4E5FB226.5030205@landley.net> On 08/31/2011 08:30 AM, Antoine Catton wrote: > Hello, > > On Wed, 2011-08-31 at 06:46 -0500, Rob Landley wrote: >> 1) The comments don't add anything here. (If userspace enabled? Here's >> what getlogin() does? Here's the end of the #ifdef seven lines earlier?) >> >> 2) The first line of that hunk creates a copy of username, then you >> check if you need to free that copy and make a different copy. Seems >> like a waste of work to me? >> >> 3) The Linux kernel uses a trick where it #defines is_singleuser() in a >> header somewhere to either a constant 0 (so the compiler's dead code >> elimination chops out the code) or else to svr_opts.singleuser, so you >> could just do: >> >> if (is_singleuser()) { >> m_free(username); >> username = m_strdup(getlogin()); >> } else username = buf_getstring(ses.payload, &userlen); >> > > I?m trying to improve my patch. But I just figured out I didn't really > get what you wanted. > > Do you want me to not use C Preprocessor statements ? http://doc.cat-v.org/henry_spencer/ifdef_considered_harmful.pdf http://www.linuxjournal.com/article/5780?page=0,3 > Do you want to enable root running dropbear in single user mode ? That's really a question for Matt, I was asking if the complexity of the extra configuration option is worthwhile. If you think root shouldn't be allowed for this mode, then don't allow it. However, if people can set arbitrary environment variables for a daemon running as root, then they can LD_PRELOAD their way to arbitrary behavior. > Could you tell me how should I improve this patch ? Simplify it as much as possible. (Simplifying the patch itself merely makes it less intrusive, simplifying the resulting dropbear code is far more impressive.) But again, Matt's the guy with the final say here... Rob From dropbear at guylhem.net Fri Sep 2 01:11:53 2011 From: dropbear at guylhem.net (Guylhem Aznar) Date: Thu, 1 Sep 2011 13:11:53 -0400 Subject: Running dropbear as unprivileged user to a single user SSH Server In-Reply-To: <4E5FB226.5030205@landley.net> References: <1314372545.11905.23.camel@localhost.localdomain> <1314608703.17296.10.camel@localhost.localdomain> <1314624430.17296.21.camel@localhost.localdomain> <4E5E1F1E.8020007@landley.net> <1314797407.17296.68.camel@localhost.localdomain> <4E5FB226.5030205@landley.net> Message-ID: Here're my 2 cents on the subject : what about adding a way to pass overrides parameters instead? This patch is interesting for what it would allow but such functions might be in a better place outside dropbear, in a more general setting. The exemple I presented to the author is the relation between a HTTP proxy (ex: stunnel) and a HTTP server. The HTTP proxy can pass X-Forwarded-For IP to the HTTP server, which, if configured to accept that, will be use in the logs files. A command line flags seems wrong to me. Adding the possibility to pass parameters to dropbear *before* it sends the SSH banner, ex: OVERRIDE_USER=xx, OVERRIDE_SHELL=yy would cover more use cases, while remaining very light. This would just require a wrapper to *send* informations to the tcp port- and the patch could simply be something like "if dropbear receives something before the connection do... otherwise business as usual". "accept override" would be a perfect command line flag for dropbear, instead of specifying which are the overrides. Guylhem From dargaud at lpsc.in2p3.fr Mon Sep 5 21:46:59 2011 From: dargaud at lpsc.in2p3.fr (Guillaume Dargaud) Date: Mon, 5 Sep 2011 15:46:59 +0200 Subject: Compression when using dropbear as an ssh/scp client ? Message-ID: <201109051547.00189.dargaud@lpsc.in2p3.fr> Hello all, I'm using dropbear compiled from buildroot: $ grep DROP .config .config:BR2_PACKAGE_DROPBEAR=y .config:BR2_PACKAGE_DROPBEAR_DISABLE_REVERSEDNS=y .config:# BR2_PACKAGE_DROPBEAR_SMALL is not set From the machine with dropbear, I seem unable to activate compression: # scp -C -p -i /etc/dropbear/dropbear_dss_host_key /root/*.dat user at remote: WARNING: Ignoring unknown argument '-C' 20110905-125726.dat 100% 16KB 16.5KB/s 00:00 20110905-125745.dat 100% 16KB 16.5KB/s 00:00 20110905-125803.dat 100% 16KB 16.5KB/s 00:00 But the option is present: # scp usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file] [-l limit] [-o ssh_option] [-P port] [-S program] [[user@]host1:]file1 [...] [[user@]host2:]file2 It's actually the same thing with ssh: # ssh -C -i /etc/dropbear/dropbear_dss_host_key noy at lpsc-ssh WARNING: Ignoring unknown argument '-C' Except that I don't even see -C as an option if I do "ssh --help" Compression actually works fine when using dropbear as a server: $ ssh -Cv root at embedded ... debug1: kex: server->client aes128-ctr hmac-md5 zlib at openssh.com debug1: kex: client->server aes128-ctr hmac-md5 zlib at openssh.com ... debug1: Enabling compression at level 6. -- Guillaume Dargaud http://www.gdargaud.net/ From j.dave.smith at siemens-enterprise.com Wed Sep 7 05:09:34 2011 From: j.dave.smith at siemens-enterprise.com (Smith, JDave) Date: Tue, 6 Sep 2011 23:09:34 +0200 Subject: Handling recv oversized packets Message-ID: <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97A8E@MCHP057A.global-ad.net> Hi What happens if a received SSH packet is greater than the max length for received packets? From something I have seen in the code (common-channel) I am concerned that this causes dropbear to simply terminate. My concern is that this leaves dropbear implementations open to DOS attacks. I am not an expert in C and the code I have checked is v0.52 so I may be wrong or not up-to-date... Note that we have a customer who is extremely security conscious and would view this as an issue, and since security considerations are on the rise in the market they would probably not be alone (at least not for very long). JD -- J Dave Smith Consultant Engineer Devices - IP Phone Siemens Enterprise Communications Limited Tel: + 44 (0) 1908 817380 Email: j.dave.smith at siemens-enterprise.com www.siemens.co.uk/enterprise Communication for the open minded Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG. This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the addressee. If you are not the addressee please note that any distribution, reproduction, copying, publication or use of this communication or the information is prohibited. If you have received this communication in error, please contact us immediately and also delete the communication from your computer. We accept no liability for any loss or damage suffered by any person arising from use of this email. P Please consider the environment - do you really need to print this email? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20110906/8463f749/attachment.htm From redhatter at gentoo.org Wed Sep 7 06:47:27 2011 From: redhatter at gentoo.org (Stuart Longland) Date: Wed, 07 Sep 2011 08:47:27 +1000 Subject: Handling recv oversized packets In-Reply-To: <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97A8E@MCHP057A.global-ad.net> References: <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97A8E@MCHP057A.global-ad.net> Message-ID: <4E66A2FF.5080707@gentoo.org> Before I answer, one point I'd like to raise: > This communication contains information which is confidential and may > also be privileged. It is for the exclusive use of the addressee. If you > are not the addressee please note that any distribution, reproduction, > copying, publication or use of this communication or the information is > prohibited. If you have received this communication in error, please > contact us immediately and also delete the communication from your > computer. We accept no liability for any loss or damage suffered by any > person arising from use of this email. The above being the case, why on EARTH did you send this to a PUBLIC mailing list? It's like ringing up on a national talk-back radio show then telling the announcer, having just spoken to them on air for about 2 minutes, that what you've told everyone listening on the air is private between you and the announcer only, not to be rebroadcast. Commercial in-confidence information has no place on such a mailing list, and such walls-of-text as those above, look utterly ridiculous in such a forum. I will proceed to answer, ignoring the above, as it is widely publicised that this mailing list goes to multiple undisclosed parties and is also archived for world-wide perusal. If there are any commercial ramifications, they are your problem, not mine as you were warned. (Okay? now to dismount from this soap box?) On 09/07/11 07:09, Smith, JDave wrote: > Hi > > What happens if a received SSH packet is greater than the max length for > received packets? From something I have seen in the code > (common-channel) I am concerned that this causes dropbear to simply > terminate. My concern is that this leaves dropbear implementations open > to DOS attacks. I am not an expert in C and the code I have checked is > v0.52 so I may be wrong or not up-to-date... I'd be curious to know where you're looking. No doubt others more knowledgeable about the code will probably know exactly where to look for the answer, but if I read this correctly: http://cvs.ucc.asn.au/cgi-bin/viewvc.cgi/anoncvs/projects/dropbear/channel.c?view=markup > 701 /* if the client is going to send us more data than we've allocated, then > 702 * it has ignored the windowsize, so we "MAY ignore all extra data" */ > 703 maxdata = channel->writebuf->size - channel->writebuf->pos; > 704 if (datalen > maxdata) { > 705 TRACE(("Warning: recv_msg_channel_data: extra data past window")); > 706 datalen = maxdata; > 707 } then the situation is handled by *ignoring* the extra data. > Note that we have a customer who is extremely security conscious and > would view this as an issue, and since security considerations are on > the rise in the market they would probably not be alone (at least not > for very long). They certainly aren't? and I'm happy to be corrected on my assessment above. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' I haven't lost my mind... ...it's backed up on a tape somewhere. From j.dave.smith at siemens-enterprise.com Wed Sep 7 07:21:01 2011 From: j.dave.smith at siemens-enterprise.com (Smith, JDave) Date: Wed, 7 Sep 2011 01:21:01 +0200 Subject: Handling recv oversized packets In-Reply-To: <4E66A2FF.5080707@gentoo.org> References: <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97A8E@MCHP057A.global-ad.net> <4E66A2FF.5080707@gentoo.org> Message-ID: <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97ABF@MCHP057A.global-ad.net> Thanks for the info Stuart I must admit I did not think to take off our standard disclaimer before sending out this message as an email to the mail distributer. I think I have learnt my lesson - thanks... As I said, I went looking in common_channel.c and spotted 678 /* Shared for data and stderr data - when we receive data, put it in a buffer 679 * for writing to the local file descriptor */ 680 void common_recv_msg_channel_data(struct Channel *channel, int fd, 681 circbuffer * cbuf) { : 701 datalen = buf_getint(ses.payload); 702 TRACE(("length %d", datalen)) 703 704 maxdata = cbuf_getavail(cbuf); 705 706 /* Whilst the spec says we "MAY ignore data past the end" this could 707 * lead to corrupted file transfers etc (chunks missed etc). It's better to 708 * just die horribly */ 709 if (datalen > maxdata) { 710 dropbear_exit("Oversized packet"); 711 } As I said, I am not a coding expert and I really want to be proved wrong. So is the above not applicable to my concern? JD PS. Do you really still use tape for backups, my head is in the clouds ;-) -----Original Message----- From: dropbear-bounces at ucc.asn.au [mailto:dropbear-bounces at ucc.asn.au] On Behalf Of Stuart Longland Sent: 06 September 2011 23:47 To: dropbear at ucc.asn.au Subject: Re: Handling recv oversized packets Before I answer, one point I'd like to raise: > This communication contains information which is confidential and may > also be privileged. It is for the exclusive use of the addressee. If you > are not the addressee please note that any distribution, reproduction, > copying, publication or use of this communication or the information is > prohibited. If you have received this communication in error, please > contact us immediately and also delete the communication from your > computer. We accept no liability for any loss or damage suffered by any > person arising from use of this email. The above being the case, why on EARTH did you send this to a PUBLIC mailing list? It's like ringing up on a national talk-back radio show then telling the announcer, having just spoken to them on air for about 2 minutes, that what you've told everyone listening on the air is private between you and the announcer only, not to be rebroadcast. Commercial in-confidence information has no place on such a mailing list, and such walls-of-text as those above, look utterly ridiculous in such a forum. I will proceed to answer, ignoring the above, as it is widely publicised that this mailing list goes to multiple undisclosed parties and is also archived for world-wide perusal. If there are any commercial ramifications, they are your problem, not mine as you were warned. (Okay... now to dismount from this soap box...) On 09/07/11 07:09, Smith, JDave wrote: > Hi > > What happens if a received SSH packet is greater than the max length for > received packets? From something I have seen in the code > (common-channel) I am concerned that this causes dropbear to simply > terminate. My concern is that this leaves dropbear implementations open > to DOS attacks. I am not an expert in C and the code I have checked is > v0.52 so I may be wrong or not up-to-date... I'd be curious to know where you're looking. No doubt others more knowledgeable about the code will probably know exactly where to look for the answer, but if I read this correctly: http://cvs.ucc.asn.au/cgi-bin/viewvc.cgi/anoncvs/projects/dropbear/channel.c?view=markup > 701 /* if the client is going to send us more data than we've allocated, then > 702 * it has ignored the windowsize, so we "MAY ignore all extra data" */ > 703 maxdata = channel->writebuf->size - channel->writebuf->pos; > 704 if (datalen > maxdata) { > 705 TRACE(("Warning: recv_msg_channel_data: extra data past window")); > 706 datalen = maxdata; > 707 } then the situation is handled by *ignoring* the extra data. > Note that we have a customer who is extremely security conscious and > would view this as an issue, and since security considerations are on > the rise in the market they would probably not be alone (at least not > for very long). They certainly aren't... and I'm happy to be corrected on my assessment above. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' I haven't lost my mind... ...it's backed up on a tape somewhere. From redhatter at gentoo.org Wed Sep 7 07:39:11 2011 From: redhatter at gentoo.org (Stuart Longland) Date: Wed, 07 Sep 2011 09:39:11 +1000 Subject: Handling recv oversized packets In-Reply-To: <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97ABF@MCHP057A.global-ad.net> References: <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97A8E@MCHP057A.global-ad.net> <4E66A2FF.5080707@gentoo.org> <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97ABF@MCHP057A.global-ad.net> Message-ID: <4E66AF1F.2080106@gentoo.org> On 09/07/11 09:21, Smith, JDave wrote: > Thanks for the info Stuart > > I must admit I did not think to take off our standard disclaimer before sending out this message as an email to the mail distributer. I think I have learnt my lesson - thanks... > > As I said, I went looking in common_channel.c and spotted > > 678 /* Shared for data and stderr data - when we receive data, put it in a buffer > 679 * for writing to the local file descriptor */ > 680 void common_recv_msg_channel_data(struct Channel *channel, int fd, > 681 circbuffer * cbuf) { > : > 701 datalen = buf_getint(ses.payload); > 702 TRACE(("length %d", datalen)) > 703 > 704 maxdata = cbuf_getavail(cbuf); > 705 > 706 /* Whilst the spec says we "MAY ignore data past the end" this could > 707 * lead to corrupted file transfers etc (chunks missed etc). It's better to > 708 * just die horribly */ > 709 if (datalen > maxdata) { > 710 dropbear_exit("Oversized packet"); > 711 } > > As I said, I am not a coding expert and I really want to be proved wrong. So is the above not applicable to my concern? One can only hope dropbear_exit is to terminate the connection and not the daemon. I haven't spotted where common_channel.c is lurking in CVS. Is it too difficult to move up to the latest release? Perhaps the "problem" was fixed there, as I don't see it in CVS? > PS. Do you really still use tape for backups, my head is in the clouds ;-) You betcha? tapes for data storage and vinyl for audio. :-) Regards, -- Stuart Longland (aka Redhatter, VK4MSL) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' I haven't lost my mind... ...it's backed up on a tape somewhere. From matt at ucc.asn.au Wed Sep 7 18:58:48 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 7 Sep 2011 18:58:48 +0800 Subject: Handling recv oversized packets In-Reply-To: <4E66AF1F.2080106@gentoo.org> References: <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97A8E@MCHP057A.global-ad.net> <4E66A2FF.5080707@gentoo.org> <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97ABF@MCHP057A.global-ad.net> <4E66AF1F.2080106@gentoo.org> Message-ID: <20110907105848.GS1128@ucc.gu.uwa.edu.au> On Wed, Sep 07, 2011 at 09:39:11AM +1000, Stuart Longland wrote: > > One can only hope dropbear_exit is to terminate the connection and not > the daemon. I haven't spotted where common_channel.c is lurking in CVS. That's correct - dropbear_exit() exits the current process, but each connection runs as a separate process. So all the bad input can do is close the current connection, the same as with any TCP stream. > Is it too difficult to move up to the latest release? Perhaps the > "problem" was fixed there, as I don't see it in CVS? The CVS repository is 7 years out of date. Currently there's monotone.ucc.asn.au branch au.asn.ucc.matt.dropbear, though unfortunately the web interface is broken. I'm intending to migrate it to Mercurial but all my attempts so far haven't been successful at keeping branch history intact. Cheers, Matt From matt at ucc.asn.au Wed Sep 7 18:59:36 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 7 Sep 2011 18:59:36 +0800 Subject: Compression when using dropbear as an ssh/scp client ? In-Reply-To: <201109051547.00189.dargaud@lpsc.in2p3.fr> References: <201109051547.00189.dargaud@lpsc.in2p3.fr> Message-ID: <20110907105936.GT1128@ucc.gu.uwa.edu.au> Dropbear client always uses compression if possible, when it is compiled in. The -C argument is ignored. Cheers, Matt On Mon, Sep 05, 2011 at 03:46:59PM +0200, Guillaume Dargaud wrote: > Hello all, > I'm using dropbear compiled from buildroot: > $ grep DROP .config > .config:BR2_PACKAGE_DROPBEAR=y > .config:BR2_PACKAGE_DROPBEAR_DISABLE_REVERSEDNS=y > .config:# BR2_PACKAGE_DROPBEAR_SMALL is not set > > From the machine with dropbear, I seem unable to activate compression: > # scp -C -p -i /etc/dropbear/dropbear_dss_host_key /root/*.dat user at remote: > WARNING: Ignoring unknown argument '-C' > 20110905-125726.dat 100% 16KB 16.5KB/s 00:00 > 20110905-125745.dat 100% 16KB 16.5KB/s 00:00 > 20110905-125803.dat 100% 16KB 16.5KB/s 00:00 > > But the option is present: > # scp > usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file] > [-l limit] [-o ssh_option] [-P port] [-S program] > [[user@]host1:]file1 [...] [[user@]host2:]file2 > > It's actually the same thing with ssh: > # ssh -C -i /etc/dropbear/dropbear_dss_host_key noy at lpsc-ssh > WARNING: Ignoring unknown argument '-C' > > Except that I don't even see -C as an option if I do "ssh --help" > > > Compression actually works fine when using dropbear as a server: > $ ssh -Cv root at embedded > ... > debug1: kex: server->client aes128-ctr hmac-md5 zlib at openssh.com > debug1: kex: client->server aes128-ctr hmac-md5 zlib at openssh.com > ... > debug1: Enabling compression at level 6. > > -- > Guillaume Dargaud > http://www.gdargaud.net/ From matt at ucc.asn.au Wed Sep 7 19:08:15 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 7 Sep 2011 19:08:15 +0800 Subject: delay question In-Reply-To: References: <4E53F65B.1050107@landley.net> <20110824114621.GA6446@ucc.gu.uwa.edu.au> <4E565C1F.4030301@landley.net> Message-ID: <20110907110814.GU1128@ucc.gu.uwa.edu.au> On Thu, Aug 25, 2011 at 01:43:28PM -0400, Guylhem Aznar wrote: > There is no nfs. Yes - in my experience well set up NFS isn't slow, though you have to have very particular versions of Linux for it to all work properly. That said, NFS certainly has nothing to do with this. > Dropbear is executed from within the chroot, to avoid any problem. I > just don't understand why this close takes so much time. It isn't the close() taking time, it's the stuff happening before the close. strace -T would show you time time for the close() itself. [pid 12140] 0.001625 fork(Process 12171 attached ) = 12171 Process 12140 isn't very interesting, that's just the Dropbear listener. I think you want to see what process 12171 is doing. That would end up in a separate log file due to the -ff, do you still have that? The output of "ssh -vvv" to the host might be useful too. I still reckon it'll be big number crypto maths that's using CPU time - modems are slow and Dropbear isn't amazingly CPU efficient. Matt From dargaud at lpsc.in2p3.fr Thu Sep 8 00:07:01 2011 From: dargaud at lpsc.in2p3.fr (Guillaume Dargaud) Date: Wed, 7 Sep 2011 18:07:01 +0200 Subject: scp asks for host key during /etc/init.d Message-ID: <201109071807.01470.dargaud@lpsc.in2p3.fr> Hello all, I have a system that needs to download a file right after boot, so I setup a small service in /etc/init.d/S89getfile that does a simple: scp -p -i /etc/dropbear/dropbear_dss_host_key user at remote:Config.ini /root/ But upon boot I see a message about the key not being in the trusted host file and would you like to add it, which fails since there's not even a keyboard on that system. If I run that exact same script after I login, it runs fine so I know both files /root/.ssh/known_hosts and authorized_keys are setup properly. There's only one user (root). Is it possible that during the boot sequence scp doesn't look in the right place for the trusted host file ? I tried adding -y but that's an shh, not scp option. I also tried -o"-y" without success. Would this work: -oStrictHostKeyChecking=no Thanks. -- Guillaume Dargaud http://www.gdargaud.net/ From dargaud at lpsc.in2p3.fr Thu Sep 8 00:09:55 2011 From: dargaud at lpsc.in2p3.fr (Guillaume Dargaud) Date: Wed, 7 Sep 2011 18:09:55 +0200 Subject: Compression when using dropbear as an ssh/scp client ? In-Reply-To: <20110907105936.GT1128@ucc.gu.uwa.edu.au> References: <201109051547.00189.dargaud@lpsc.in2p3.fr> <20110907105936.GT1128@ucc.gu.uwa.edu.au> Message-ID: <201109071809.55667.dargaud@lpsc.in2p3.fr> > Dropbear client always uses compression if possible, when it > is compiled in. The -C argument is ignored. What's a simple way to check that the compression is indeed used ? The size displayed is always the uncompressed one and there's no verbose option. Without resorting to wireshark-fu if possible !!! -- Guillaume Dargaud http://www.gdargaud.net/ From ska-dietlibc at skarnet.org Thu Sep 8 10:51:02 2011 From: ska-dietlibc at skarnet.org (Laurent Bercot) Date: Thu, 8 Sep 2011 04:51:02 +0200 Subject: scp asks for host key during /etc/init.d In-Reply-To: <201109071807.01470.dargaud@lpsc.in2p3.fr> References: <201109071807.01470.dargaud@lpsc.in2p3.fr> Message-ID: <20110908025102.GA18678@skarnet.org> > Is it possible that during the boot sequence scp doesn't look in the right place for the trusted host file ? A boot environment and a login environment are very different things. For instance, in your boot environment, you have no defined USER or HOME environment variables. scp has no way of knowing that your known_hosts file is in /root/.ssh if there's no HOME=/root variable to tell it so. Adjust the environment in your scp command line. Make sure it does not leak to the rest of the boot scripts, though. -- Laurent From rob at landley.net Sun Sep 11 09:57:26 2011 From: rob at landley.net (Rob Landley) Date: Sat, 10 Sep 2011 20:57:26 -0500 Subject: Compression when using dropbear as an ssh/scp client ? In-Reply-To: <201109071809.55667.dargaud@lpsc.in2p3.fr> References: <201109051547.00189.dargaud@lpsc.in2p3.fr> <20110907105936.GT1128@ucc.gu.uwa.edu.au> <201109071809.55667.dargaud@lpsc.in2p3.fr> Message-ID: <4E6C1586.3040902@landley.net> On 09/07/2011 11:09 AM, Guillaume Dargaud wrote: >> Dropbear client always uses compression if possible, when it >> is compiled in. The -C argument is ignored. > > What's a simple way to check that the compression is indeed used ? > The size displayed is always the uncompressed one and there's no verbose option. > > Without resorting to wireshark-fu if possible !!! Does the dropbear binary link against zlib? (What does ldd say?) Rob From rob at landley.net Sun Sep 11 10:18:02 2011 From: rob at landley.net (Rob Landley) Date: Sat, 10 Sep 2011 21:18:02 -0500 Subject: Converting dropbear to mercurial. In-Reply-To: <20110907105848.GS1128@ucc.gu.uwa.edu.au> References: <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97A8E@MCHP057A.global-ad.net> <4E66A2FF.5080707@gentoo.org> <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97ABF@MCHP057A.global-ad.net> <4E66AF1F.2080106@gentoo.org> <20110907105848.GS1128@ucc.gu.uwa.edu.au> Message-ID: <4E6C1A5A.9050904@landley.net> On 09/07/2011 05:58 AM, Matt Johnston wrote: >> Is it too difficult to move up to the latest release? Perhaps the >> "problem" was fixed there, as I don't see it in CVS? > > The CVS repository is 7 years out of date. Currently there's > monotone.ucc.asn.au branch au.asn.ucc.matt.dropbear, though > unfortunately the web interface is broken. I'm intending to > migrate it to Mercurial but all my attempts so far haven't > been successful at keeping branch history intact. Have you tried http://mercurial.selenic.com/wiki/ConvertExtension ? I don't know the state of monotone support in mercurial, but I've never used monotone, so... Rob From matt at ucc.asn.au Sun Sep 11 21:48:31 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Sun, 11 Sep 2011 21:48:31 +0800 Subject: Converting dropbear to mercurial. In-Reply-To: <3C66135B-0909-49C5-B87F-7DDB09FA2CA1@gmail.com> References: <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97A8E@MCHP057A.global-ad.net> <4E66A2FF.5080707@gentoo.org> <8BCCE8EDFDFFF0409691CC7F0D193D5A0771B97ABF@MCHP057A.global-ad.net> <4E66AF1F.2080106@gentoo.org> <20110907105848.GS1128@ucc.gu.uwa.edu.au> <4E6C1A5A.9050904@landley.net> <3C66135B-0909-49C5-B87F-7DDB09FA2CA1@gmail.com> Message-ID: <20110911134830.GF1128@ucc.gu.uwa.edu.au> On Sat, Sep 10, 2011 at 10:07:49PM -0500, Augie Fackler wrote: > > Have you tried http://mercurial.selenic.com/wiki/ConvertExtension ? > > > > I don't know the state of monotone support in mercurial, but I've never > > used monotone, so... > > Convert should work. If not, feel encouraged to give me the right mtn spell to get a clone of your mtn and I'll gladly poke it to see what's wrong. The monotone converter gets confused by me doing rename "" -> "libtomcrypt" on one side of the merge in revision fdf4a7a3b97ae5046139915de7e40399cceb2c01. That happens via monotone's "merge_into_dir" command - I moved the root directory of the ...ltc.dropbear branch into a subdirectory of the main dropbear branch. The end result is that an old version of "changes" appears in the toplevel directory of au.asn.ucc.matt.dropbear branch, as well as the correct version at "libtomcrypt/changes". (The same happens for various other files there too). Looking at the code in montone.py's getchanges() I can't see how it would work correctly. It's iterating over all renames/adds/deletes, but in a merge each operation will be relative a particular parent revision denoted by the "old_revision" lines. See http://matt.ucc.asn.au/dropbear/test/fdf4a7a-merge_into_dir.txt for the Monotone revision (from "mtn automate get_revision"). I've tried a few different tweaks but none seemed to improve things. Unfortunately a simple synthetic testcase doesn't hit the same problem either :( I might try making a simpler getchanges() version that ignores renames and just uses mtn automate's get_manifest_of to figure out the files - my repository I can live without rename/copy tracking. If you want to look at it I also needed the following for the empty fromdir case to avoid paths with a leading slash. if fromdir == "": renamed[tofile] = fromdir + tofile[len(todir)+1:] else: renamed[tofile] = fromdir + tofile[len(todir):] I also had to comment out the mercurial_source in convcmd.py - otherwise it would abort before the monotone source was tried. I'll report that one as a separate bug, I assume it would affect any converter below mercurial_source. I've put a cut down repository at http://matt.ucc.asn.au/dropbear/test/small-dropbear.mtn Cheers, Matt From rory at trs80.net Tue Sep 13 09:23:42 2011 From: rory at trs80.net (Rory Toma) Date: Mon, 12 Sep 2011 18:23:42 -0700 Subject: Question on using ssh-agent with dropbear and keys Message-ID: <4E6EB09E.5040609@trs80.net> I searched the web and looked for info and a FAQ, and still can't get this to work. I'm trying to ssh from my "normal" box to my dropbear box. I've done: ssh-keygen -b 768 to create my public and private keys. I copied out the id_rsa.pub file (which is the "ssh-rsa foo at bar.net" type) I set ownership of .ssh and all files to root, with all files being 600 and .ssh being 700. (also tried 644 on the files) Anyway I get: debug1: Offering public key: ./id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password This has always just worked going from openssh->openssh. What is different here? Is there some dropbearism I'm missing? thx From rob at landley.net Wed Sep 14 05:13:14 2011 From: rob at landley.net (Rob Landley) Date: Tue, 13 Sep 2011 16:13:14 -0500 Subject: Question on using ssh-agent with dropbear and keys In-Reply-To: <4E6EB09E.5040609@trs80.net> References: <4E6EB09E.5040609@trs80.net> Message-ID: <4E6FC76A.4030901@landley.net> On 09/12/2011 08:23 PM, Rory Toma wrote: > I searched the web and looked for info and a FAQ, and still can't get > this to work. > > I'm trying to ssh from my "normal" box to my dropbear box. > > I've done: > > ssh-keygen -b 768 to create my public and private keys. Dropbear doesn't store its keys in the same format as openssh does. You're using the openssh key generator instead of dropbearkey, look at the "dropbearconvert" program. > I copied out the id_rsa.pub file (which is the "ssh-rsa > foo at bar.net" type) By "copied out" do you mean you installed it on the remote system you're trying to ssh into under the name "~/.ssh/authorized_keys"? > I set ownership of .ssh and all files to root, I set them to belong to the user I'm trying to ssh into. (Root can read everything anyway, that's sort of the point of root. If you're using a crazy SELinux system where that's not true, ask the NSA to help you.) > with all files being 600 > and .ssh being 700. (also tried 644 on the files) > > Anyway I get: > > debug1: Offering public key: ./id_rsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: publickey,password It doesn't look like it's failed yet? publickey can continue... > This has always just worked going from openssh->openssh. What is > different here? Is there some dropbearism I'm missing? My guess is on-disk key storage format. > thx Rob From dargaud at lpsc.in2p3.fr Mon Sep 19 15:08:02 2011 From: dargaud at lpsc.in2p3.fr (Guillaume Dargaud) Date: Mon, 19 Sep 2011 09:08:02 +0200 Subject: Compression when using dropbear as an ssh/scp client ? In-Reply-To: <4E6C1586.3040902@landley.net> References: <201109051547.00189.dargaud@lpsc.in2p3.fr> <201109071809.55667.dargaud@lpsc.in2p3.fr> <4E6C1586.3040902@landley.net> Message-ID: <201109190908.02993.dargaud@lpsc.in2p3.fr> Hello Rob, > Does the dropbear binary link against zlib? (What does ldd say?) # ldd /usr/sbin/dropbear libcrypt.so.0 => /lib/libcrypt.so.0 (0x48016000) libutil.so.0 => /lib/libutil.so.0 (0x4803b000) libz.so.1 => /usr/lib/libz.so.1 (0x4804d000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4806f000) libc.so.0 => /lib/libc.so.0 (0x48099000) libm.so.0 => /lib/libm.so.0 (0x480f0000) ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x48000000) Anyway, after some testing, I find it more efficient and easier to fine-tune it with a: List=*.dat tar -vc $List | nice gzip | ssh -y -i /etc/dropbear/dropbear_dss_host_key user at remote "cd data && tar -zxf -" && rm $List -- Guillaume Dargaud http://www.gdargaud.net/ From dave.taht at gmail.com Wed Sep 28 19:58:24 2011 From: dave.taht at gmail.com (Dave Taht) Date: Wed, 28 Sep 2011 04:58:24 -0700 Subject: [PATCH] Set TOS (TCLASS) bits under ipv6 Message-ID: Setting the TCLASS (TOS) field requires different setsockopt params on ipv6 than ipv4. as per: http://www.bufferbloat.net/projects/cerowrt/issues/249 --- dbutil.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/dbutil.c b/dbutil.c index b3a119f..2739d2f 100644 --- a/dbutil.c +++ b/dbutil.c @@ -161,10 +161,12 @@ static void set_sock_priority(int sock) { val = 1; setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (void*)&val, sizeof(val)); - /* set the TOS bit. note that this will fail for ipv6, I can't find any - * equivalent. */ + /* bruteforce the TOS bit for ipv4 or ipv6. Note that for versions of + Linux prior to 2.6.39 this will stomp on the ECN bit under IPv6 */ + #ifdef IPTOS_LOWDELAY val = IPTOS_LOWDELAY; + setsockopt(sock, IPPROTO_IPV6, IPV6_TCLASS, (void*)&val, sizeof(val)); setsockopt(sock, IPPROTO_IP, IP_TOS, (void*)&val, sizeof(val)); #endif -- 1.7.4.1 -- Dave T?ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com From dave.taht at gmail.com Wed Sep 28 19:59:02 2011 From: dave.taht at gmail.com (Dave Taht) Date: Wed, 28 Sep 2011 04:59:02 -0700 Subject: [PATCH] Set TOS (TCLASS) bits under ipv6 In-Reply-To: References: Message-ID: It would be mildly better to set the bulk bit for scp transfers where possible. On Wed, Sep 28, 2011 at 4:58 AM, Dave Taht wrote: > Setting the TCLASS (TOS) field requires different setsockopt > params on ipv6 than ipv4. > > as per: > > http://www.bufferbloat.net/projects/cerowrt/issues/249 > --- > ?dbutil.c | ? ?6 ++++-- > ?1 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/dbutil.c b/dbutil.c > index b3a119f..2739d2f 100644 > --- a/dbutil.c > +++ b/dbutil.c > @@ -161,10 +161,12 @@ static void set_sock_priority(int sock) { > ? ? ? ?val = 1; > ? ? ? ?setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (void*)&val, sizeof(val)); > > - ? ? ? /* set the TOS bit. note that this will fail for ipv6, I can't find any > - ? ? ? ?* equivalent. */ > + ? ? ? /* bruteforce the TOS bit for ipv4 or ipv6. Note that for versions of > + ? ? ? ? ? Linux prior to 2.6.39 this will stomp on the ECN bit under IPv6 */ > + > ?#ifdef IPTOS_LOWDELAY > ? ? ? ?val = IPTOS_LOWDELAY; > + ? ? ? setsockopt(sock, IPPROTO_IPV6, IPV6_TCLASS, (void*)&val, sizeof(val)); > ? ? ? ?setsockopt(sock, IPPROTO_IP, IP_TOS, (void*)&val, sizeof(val)); > ?#endif > > -- > 1.7.4.1 > > > -- > Dave T?ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://the-edge.blogspot.com > -- Dave T?ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com From matt at ucc.asn.au Wed Sep 28 20:47:50 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 28 Sep 2011 20:47:50 +0800 Subject: [PATCH] Set TOS (TCLASS) bits under ipv6 In-Reply-To: References: Message-ID: <20110928124750.GR1128@ucc.gu.uwa.edu.au> Hi, Thanks for the patch, it answers my commented question six years later :) What are the implications of "stomping on" the ECN bit on pre-2.6.39 kernels? I agree flags for SCP would make sense, I'll take a look where to do that. I'm not sure how to handle SFTP since lookup commands should remain responsive, especially for things like sshfs. I don't know whether changing socket options frequently works OK. Cheers, Matt On Wed, Sep 28, 2011 at 04:58:24AM -0700, Dave Taht wrote: > Setting the TCLASS (TOS) field requires different setsockopt > params on ipv6 than ipv4. > > as per: > > http://www.bufferbloat.net/projects/cerowrt/issues/249 > --- > dbutil.c | 6 ++++-- > 1 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/dbutil.c b/dbutil.c > index b3a119f..2739d2f 100644 > --- a/dbutil.c > +++ b/dbutil.c > @@ -161,10 +161,12 @@ static void set_sock_priority(int sock) { > val = 1; > setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (void*)&val, sizeof(val)); > > - /* set the TOS bit. note that this will fail for ipv6, I can't find any > - * equivalent. */ > + /* bruteforce the TOS bit for ipv4 or ipv6. Note that for versions of > + Linux prior to 2.6.39 this will stomp on the ECN bit under IPv6 */ > + > #ifdef IPTOS_LOWDELAY > val = IPTOS_LOWDELAY; > + setsockopt(sock, IPPROTO_IPV6, IPV6_TCLASS, (void*)&val, sizeof(val)); > setsockopt(sock, IPPROTO_IP, IP_TOS, (void*)&val, sizeof(val)); > #endif > > -- > 1.7.4.1 > > > -- > Dave T?ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://the-edge.blogspot.com From dave.taht at gmail.com Wed Sep 28 21:03:01 2011 From: dave.taht at gmail.com (Dave Taht) Date: Wed, 28 Sep 2011 06:03:01 -0700 Subject: [PATCH] Set TOS (TCLASS) bits under ipv6 In-Reply-To: <20110928124750.GR1128@ucc.gu.uwa.edu.au> References: <20110928124750.GR1128@ucc.gu.uwa.edu.au> Message-ID: On Wed, Sep 28, 2011 at 5:47 AM, Matt Johnston wrote: > Hi, > > Thanks for the patch, it answers my commented question six > years later :) I was stumped on this one for even longer than that, so I'm pushing out the knowledge (and patches) as fast as I can. > What are the implications of "stomping on" > the ECN bit on pre-2.6.39 kernels? pre-2.6.39, you could actually set the IPv6 ECN bits from userspace, which was bad in most ways (good in another, in that you could test ECN from userspace programs). Notably as ECN is a negotiated inside-of-tcp option, then passed to the outside dscp field, calling setsockopt to reset it to effectively *off* is not a problem. setting ECN to *on* (e.g IP_TOS_LOWDELAY | 3) IS a problem, but we're not doing that... I tried to find ways to determine if I could find the existing ECN setting, to or in the bits... and failed. That said, ECN is not widely deployed (yet), and losing ECN capability in this case (on older kernels) only reverts the tcp connection to the default behavior of forcing a traffic shaper, to drop, rather than ECN mark packets. So there should be no ill effect on existing code with this change, and treating ssh packets over ipv6 as interactive helps a lot in the general case (and in the case of 6to4, the encapsulated packet header is copied to the outer header, so encapsulated 6to4 packets also can get prioritized right) > I agree flags for SCP would make sense, I'll take a look > where to do that. I think openssh does half the job (the scp side sets bulk), I haven't looked at it yet (mostly working on cerowrt right now) > I'm not sure how to handle SFTP since > lookup commands should remain responsive, especially for > things like sshfs. I don't know whether changing socket > options frequently works OK. It would be a good experiment! I've got the current patch working in a cerowrt smoketest, seeing it also do more of the right thing in a sftp environment I can easily test. The 'experimental' part is when the setsockopt change would be asserted on the flow, thus reprioritizing packets possibly in flight? > > Cheers, > Matt > > On Wed, Sep 28, 2011 at 04:58:24AM -0700, Dave Taht wrote: >> Setting the TCLASS (TOS) field requires different setsockopt >> params on ipv6 than ipv4. >> >> as per: >> >> http://www.bufferbloat.net/projects/cerowrt/issues/249 >> --- >> ?dbutil.c | ? ?6 ++++-- >> ?1 files changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/dbutil.c b/dbutil.c >> index b3a119f..2739d2f 100644 >> --- a/dbutil.c >> +++ b/dbutil.c >> @@ -161,10 +161,12 @@ static void set_sock_priority(int sock) { >> ? ? ? val = 1; >> ? ? ? setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (void*)&val, sizeof(val)); >> >> - ? ? /* set the TOS bit. note that this will fail for ipv6, I can't find any >> - ? ? ?* equivalent. */ >> + ? ? /* bruteforce the TOS bit for ipv4 or ipv6. Note that for versions of >> + ? ? ? ? ? Linux prior to 2.6.39 this will stomp on the ECN bit under IPv6 */ >> + >> ?#ifdef IPTOS_LOWDELAY >> ? ? ? val = IPTOS_LOWDELAY; >> + ? ? setsockopt(sock, IPPROTO_IPV6, IPV6_TCLASS, (void*)&val, sizeof(val)); >> ? ? ? setsockopt(sock, IPPROTO_IP, IP_TOS, (void*)&val, sizeof(val)); >> ?#endif >> >> -- >> 1.7.4.1 >> >> >> -- >> Dave T?ht >> SKYPE: davetaht >> US Tel: 1-239-829-5608 >> http://the-edge.blogspot.com > -- Dave T?ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com From gmart at coinet.com Thu Sep 29 02:31:30 2011 From: gmart at coinet.com (Gary) Date: Wed, 28 Sep 2011 18:31:30 +0000 (UTC) Subject: Long delay during login References: <200506131021.53380.srowe@cambridgebroadband.com> <20050622053521.GG14943@ucc.gu.uwa.edu.au> Message-ID: Matt Johnston ucc.asn.au> writes: On Mon, Jun 13, 2005 at 10:21:53AM +0100, Simon Rowe wrote: > We're seeing a long delay when logging in using dropbear on to our embedded > system (60MHz PowerPC). Looking at the debug from the client end it appears > that the issue is the Diffie-Hellman key negotiation within dropbear > > debug1: expecting SSH2_MSG_KEXDH_REPLY > > [delay of about 8 seconds] > > Is there anything we can change to reduce this delay? Same problem here. My bet is that it's blocking on the random device. For me ssh'ng to a busy machine is fast, ssh'ng to an idle machine almost always has a BIG delay.