From sakoman at gmail.com Fri Oct 5 12:29:38 2007 From: sakoman at gmail.com (Steve Sakoman) Date: Thu, 4 Oct 2007 21:29:38 -0700 Subject: scp to embedded system running dropbear yields results in zero length files Message-ID: <5e088bd90710042129q5223754bs56695c36160b530b@mail.gmail.com> I am one of the early users of the OpenEmbedded Linux build for gumstix ( 2.6.21 kernel, uclibc). The build image includes dropbear 0.49, and it seems to work fine in most cases. I am able to login to the gumstix remotely via ssh. I am able to use ssh on the gumstix to log into my linux box. I am also able to use scp on the gumstix to copy files to my linux box. However using scp to copy files from the Linux box to the gumstix doesn't quite work. The copied file appears on the gumstix in the proper location, but it always has zero length! Any ideas on what might be wrong? Regards, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20071004/e4876046/attachment.htm From oliver.hanka at gi-de.com Fri Oct 5 16:39:30 2007 From: oliver.hanka at gi-de.com (oliver.hanka at gi-de.com) Date: Fri, 5 Oct 2007 10:39:30 +0200 Subject: Is there a patch to add arcfour support? Message-ID: Hello, is a patch out there, which adds arcfour (128bit) support to dropbear? Thanks. Mit freundlichen Gr?ssen / Best regards Oliver Hanka -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20071005/21a3f01f/attachment.htm From sakoman at gmail.com Sat Oct 6 03:06:40 2007 From: sakoman at gmail.com (Steve Sakoman) Date: Fri, 5 Oct 2007 12:06:40 -0700 Subject: scp to embedded system running dropbear yields results in zero length files In-Reply-To: <5e088bd90710042129q5223754bs56695c36160b530b@mail.gmail.com> References: <5e088bd90710042129q5223754bs56695c36160b530b@mail.gmail.com> Message-ID: <5e088bd90710051206j2659ea29q6731ca00f56e7c82@mail.gmail.com> I reverted to dropbear 0.47 and the problem went away. Will try 0.48 a little later today to see which release introduced the problem. Steve On 10/4/07, Steve Sakoman wrote: > > I am one of the early users of the OpenEmbedded Linux build for gumstix ( > 2.6.21 kernel, uclibc). > > The build image includes dropbear 0.49, and it seems to work fine in most > cases. I am able to login to the gumstix remotely via ssh. I am able to > use ssh on the gumstix to log into my linux box. I am also able to use scp > on the gumstix to copy files to my linux box. > > However using scp to copy files from the Linux box to the gumstix doesn't > quite work. The copied file appears on the gumstix in the proper location, > but it always has zero length! > > Any ideas on what might be wrong? > > Regards, > > Steve > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20071005/4f37c900/attachment.htm From matt at ucc.asn.au Tue Oct 16 19:02:03 2007 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 16 Oct 2007 19:02:03 +0800 Subject: Is there a patch to add arcfour support? In-Reply-To: References: Message-ID: <20071016110203.GD32214@ucc.gu.uwa.edu.au> On Fri, Oct 05, 2007 at 10:39:30AM +0200, oliver.hanka at gi-de.com wrote: > Hello, > > is a patch out there, which adds arcfour (128bit) support to dropbear? Not currently, no. I've been meaning to look at it (patches gladly accepted). Cheers, Matt From matt at ucc.asn.au Tue Oct 16 19:05:17 2007 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 16 Oct 2007 19:05:17 +0800 Subject: scp to embedded system running dropbear yields results in zero length files In-Reply-To: <5e088bd90710042129q5223754bs56695c36160b530b@mail.gmail.com> References: <5e088bd90710042129q5223754bs56695c36160b530b@mail.gmail.com> Message-ID: <20071016110517.GE32214@ucc.gu.uwa.edu.au> On Thu, Oct 04, 2007 at 09:29:38PM -0700, Steve Sakoman wrote: > I am one of the early users of the OpenEmbedded Linux build for gumstix ( > 2.6.21 kernel, uclibc). > > The build image includes dropbear 0.49, and it seems to work fine in most > cases. I am able to login to the gumstix remotely via ssh. I am able to > use ssh on the gumstix to log into my linux box. I am also able to use scp > on the gumstix to copy files to my linux box. > > However using scp to copy files from the Linux box to the gumstix doesn't > quite work. The copied file appears on the gumstix in the proper location, > but it always has zero length! > > Any ideas on what might be wrong? I'll see if I can reproduce it here. Just to clarify, were you running scp on the gumstix or the Linux box when it failed? (whether it's a dbclient or dropbear-server problem) Cheers, Matt From sakoman at gmail.com Tue Oct 16 21:16:00 2007 From: sakoman at gmail.com (Steve Sakoman) Date: Tue, 16 Oct 2007 06:16:00 -0700 Subject: scp to embedded system running dropbear yields results in zero length files In-Reply-To: <20071016110517.GE32214@ucc.gu.uwa.edu.au> References: <5e088bd90710042129q5223754bs56695c36160b530b@mail.gmail.com> <20071016110517.GE32214@ucc.gu.uwa.edu.au> Message-ID: <5e088bd90710160616v23f26cb6t19a6cf1cdfcb1369@mail.gmail.com> Matt, Using scp on the Linux box is what fails. I'm pretty sure it is a dropbear server issue, since reverting to dropbear 0.47 works just fine. Steve On 10/16/07, Matt Johnston wrote: > > On Thu, Oct 04, 2007 at 09:29:38PM -0700, Steve Sakoman wrote: > > I am one of the early users of the OpenEmbedded Linux build for gumstix > ( > > 2.6.21 kernel, uclibc). > > > > The build image includes dropbear 0.49, and it seems to work fine in > most > > cases. I am able to login to the gumstix remotely via ssh. I am able > to > > use ssh on the gumstix to log into my linux box. I am also able to use > scp > > on the gumstix to copy files to my linux box. > > > > However using scp to copy files from the Linux box to the gumstix > doesn't > > quite work. The copied file appears on the gumstix in the proper > location, > > but it always has zero length! > > > > Any ideas on what might be wrong? > > I'll see if I can reproduce it here. Just to clarify, were > you running scp on the gumstix or the Linux box when it > failed? (whether it's a dbclient or dropbear-server problem) > > Cheers, > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20071016/657cdd12/attachment.htm From roberto.foglietta at gmail.com Wed Oct 17 21:49:47 2007 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Wed, 17 Oct 2007 15:49:47 +0200 Subject: [PATCH] ssh -Y: always accepts and stores the hostkey Message-ID: Hi to all folks, the attached patch add the -Y option which force the acceptance and the storage of the hostkey. OpenSSH has a rc option which bypass the check. In this patch storage of the unknown or not corresponding hostkeys as been implemented. This option is NOT enabled by default but it becames available editing options.h. Forcing the storage of the hostkey is usefull in some embedded systems in which I have to use dropbear/ssh to get the hostkey and after sftp which checks the stored hostkey. I am conscious that doing this the system could be exposed to man-in-the-middle attack but not more than manually removing know_hosts file. The usage of this option woudl be usefull when user-remote-cli would force the overwriting of the stored hostkey: the ssh first fails because hostkey mismatch, the user will be informed about hostkey mismatch and if the user confirms is not a man-in-the-middle case then another run with -Y force the changes without the necessity of remote-cli knows anything about embedded system apart -Y option. Please apply or comment back. Thanks, -- /roberto -------------- next part -------------- A non-text attachment was scrubbed... Name: dropbear_always_accept_and_store_hostkey.patch Type: text/x-diff Size: 3237 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20071017/af279624/attachment.patch From roberto.foglietta at gmail.com Wed Oct 17 22:14:07 2007 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Wed, 17 Oct 2007 16:14:07 +0200 Subject: [PATCH] ssh -Y: always accepts and stores the hostkey In-Reply-To: References: Message-ID: Sorry guys, this is the RIGHT patch and this is the test procedure: /.ssh # export DROPBEAR_PASSWORD=guest /.ssh # cat known_hosts /.ssh # ssh -Y guest at 172.16.119.6 hostname Host '172.16.119.6' key accepted unconditionally. (fingerprint md5 c9:50:c6:b3:eb:f8:80:be:68:fe:a1:fd:51:fb:d8:15) eemd2364170 /.ssh # cat known_hosts 172.16.119.6 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsYTt7X7ACOWazixl64T5sgBCnuB3OboOc5CJYb+ESaRXTk/d4mduEWmlVanh5CjOen2glvaJvkz5FqCzcq88UD23+aHV9HvxXT= /.ssh # vi known_hosts #altering hostkey /.ssh # cat known_hosts 172.16.119.6 ssh-rsa BAAAB3NzaC1yc2EAAAABIwAAAQEAsYTt7X7ACOWazixl64T5sgBCnuB3OboOc5CJYb+ESaRXTk/d4mduEWmlVanh5CjOen2glvaJvkz5FqCzcq88UD23+aHV9HvxXT= /.ssh # ssh guest at 172.16.119.6 hostname ssh: connection to guest at 172.16.119.6:22 exited: Host key mismatch for 172.16.119.6 ! Fingerprint is md5 c9:50:c6:b3:eb:f8:80:be:68:fe:a1:fd:51:fb:d8:15 Expected md5 92:3a:88:29:46:69:66:67:6d:88:4e:4e:17:1e:17:23 If you know that the host key is correct you can remove the bad entry from ~/.ssh/known_hosts /.ssh # ssh -Y guest at 172.16.119.6 hostname Host '172.16.119.6' key accepted unconditionally. (fingerprint md5 c9:50:c6:b3:eb:f8:80:be:68:fe:a1:fd:51:fb:d8:15) eemd2364170 Cheers, -- /roberto -------------- next part -------------- A non-text attachment was scrubbed... Name: dropbear_always_accept_and_store_hostkey.patch Type: text/x-diff Size: 3238 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20071017/e70dfbe8/attachment.patch From tim.bird at am.sony.com Thu Oct 18 00:27:36 2007 From: tim.bird at am.sony.com (Tim Bird) Date: Wed, 17 Oct 2007 09:27:36 -0700 Subject: [PATCH] ssh -Y: always accepts and stores the hostkey In-Reply-To: References: Message-ID: <471637F8.50901@am.sony.com> Roberto A. Foglietta wrote: > the attached patch add the -Y option which force the acceptance and > the storage of the hostkey. OpenSSH has a rc option which bypass the > check. In this patch storage of the unknown or not corresponding > hostkeys as been implemented. This option is NOT enabled by default > but it becames available editing options.h. This is a very welcome feature. I could have used this a few times in past projects, where I've been automating ssh access to embedded boards. My workaround had been to revert to telnet. Thanks! -- Tim ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America ============================= From hamish at cloud.net.au Thu Oct 18 08:02:31 2007 From: hamish at cloud.net.au (Hamish Moffatt) Date: Thu, 18 Oct 2007 10:02:31 +1000 Subject: [PATCH] ssh -Y: always accepts and stores the hostkey In-Reply-To: References: Message-ID: <4716A297.2010700@cloud.net.au> Roberto A. Foglietta wrote: > /.ssh # ssh -Y guest at 172.16.119.6 hostname > > Host '172.16.119.6' key accepted unconditionally. > (fingerprint md5 c9:50:c6:b3:eb:f8:80:be:68:fe:a1:fd:51:fb:d8:15) > eemd2364170 Note that OpenSSH has a -Y switch with a different meaning, so this may be confusing. Hamish From roberto.foglietta at gmail.com Thu Oct 18 16:33:40 2007 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Thu, 18 Oct 2007 10:33:40 +0200 Subject: [PATCH] ssh -Y: always accepts and stores the hostkey In-Reply-To: <4716A297.2010700@cloud.net.au> References: <4716A297.2010700@cloud.net.au> Message-ID: 2007/10/18, Hamish Moffatt : > Roberto A. Foglietta wrote: > > /.ssh # ssh -Y guest at 172.16.119.6 hostname > > > > Host '172.16.119.6' key accepted unconditionally. > > (fingerprint md5 c9:50:c6:b3:eb:f8:80:be:68:fe:a1:fd:51:fb:d8:15) > > eemd2364170 > > Note that OpenSSH has a -Y switch with a different meaning, so this may > be confusing. Yes, you are right. May be a -yy could be better? New patch in attachment. Cheers, -- /roberto -------------- next part -------------- A non-text attachment was scrubbed... Name: dropbear_always_accept_and_store_hostkey.patch Type: text/x-diff Size: 3188 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20071018/1ca7a989/attachment.patch From hamish at cloud.net.au Thu Oct 18 16:58:58 2007 From: hamish at cloud.net.au (Hamish Moffatt) Date: Thu, 18 Oct 2007 18:58:58 +1000 Subject: [PATCH] ssh -Y: always accepts and stores the hostkey In-Reply-To: References: <4716A297.2010700@cloud.net.au> Message-ID: <20071018085858.GA9226@cloud.net.au> On Thu, Oct 18, 2007 at 10:33:40AM +0200, Roberto A. Foglietta wrote: > 2007/10/18, Hamish Moffatt : > > Roberto A. Foglietta wrote: > > > /.ssh # ssh -Y guest at 172.16.119.6 hostname > > > > > > Host '172.16.119.6' key accepted unconditionally. > > > (fingerprint md5 c9:50:c6:b3:eb:f8:80:be:68:fe:a1:fd:51:fb:d8:15) > > > eemd2364170 > > > > Note that OpenSSH has a -Y switch with a different meaning, so this may > > be confusing. > > Yes, you are right. May be a -yy could be better? > New patch in attachment. That sounds reasonable to me. I wish OpenSSH had this functionality! cheers, Hamish -- Hamish Moffatt VK3SB From eric.berryman at gmail.com Tue Nov 6 05:50:58 2007 From: eric.berryman at gmail.com (Eric Berryman) Date: Mon, 5 Nov 2007 15:50:58 -0500 Subject: command=" " question Message-ID: <56ff363c0711051250p30d85045n25d9d8943d107c0a@mail.gmail.com> Hello! Is it possible with dropbear to have an authorized_keys file like so: ssh-rsa AAAA .... command="screen -r name" ssh-rsa BBBB .... It doesn't seem to recognize the command part, like my non-dropbear ssh machines. I have this set up for all my linux boxes ... it would be great if I could include the embedded linux machines too :) From matt at ucc.asn.au Wed Nov 7 20:52:20 2007 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 7 Nov 2007 20:52:20 +0900 Subject: command=" " question In-Reply-To: <56ff363c0711051250p30d85045n25d9d8943d107c0a@mail.gmail.com> References: <56ff363c0711051250p30d85045n25d9d8943d107c0a@mail.gmail.com> Message-ID: <20071107115220.GF26184@ucc.gu.uwa.edu.au> On Mon, Nov 05, 2007 at 03:50:58PM -0500, Eric Berryman wrote: > Hello! > > Is it possible with dropbear to have an authorized_keys file like so: > > ssh-rsa AAAA .... > command="screen -r name" ssh-rsa BBBB .... > > It doesn't seem to recognize the command part, like my non-dropbear > ssh machines. > I have this set up for all my linux boxes ... it would be great if I > could include the embedded linux machines too :) Dropbear doesn't currently support any authorized_keys options - lines not starting with "ssh-" are skipped. I might add support in a future release (though no promises). Cheers, Matt From roger at planbit.co.uk Fri Nov 30 23:52:35 2007 From: roger at planbit.co.uk (roger at planbit.co.uk) Date: Fri, 30 Nov 2007 14:52:35 -0000 (GMT) Subject: Dropbear 0.50 server returnsexit code 255 to ssh when app returns 0 Message-ID: <57805.88.96.204.222.1196434355.squirrel@portal.planbit.co.uk> Hi, We are running the Dropbear 0.50 SSH server on an ARM9 platform. We are connecting to it from a fast quad-core intel server over 100-Base-T. We found this problem when trying to build Perl for the target. The cross-compile process uploads and runs programs on the target and checks the exit code from the SSH client to check the target program's exit code. The ARM9 platform is running a stock Linux 2.6.18 kernel compiled with the GCC CodeSourcery 2006q3-26 v4.1.1. The host Intel platform is running CentOS5 with OpenSSH_4.3p2. A sample shell script on the target is: #!/bin/bash echo "ARG: $1" exit $1 When we run dropbear 0.50 server on the target without debug enabled, we get exit code 255 from SSH. e.g. # ssh root at 192.168.0.10 /tmp/test.sh 1 ARG: 1 # echo $? 255 # # ssh root at 192.168.0.10 /tmp/test.sh 100 ARG: 1 # echo $? 255 # If we recompile dropbear with debug enabled, but don't pass the -v option when starting dropbear, the behavior is the same. If we run dropbear with the "-F -E -v" options, we get the correct exit codes. # ssh root at 192.168.0.10 /tmp/test.sh 1 TRACE: enter sign_key_free TRACE: enter dsa_key_free TRACE: enter dsa_key_free: key == NULL TRACE: enter rsa_key_free TRACE: leave rsa_key_free TRACE: leave sign_key_free ARG: 1 # echo $? 1 # # ssh root at 192.168.0.10 /tmp/test.sh 100 TRACE: enter sign_key_free TRACE: enter dsa_key_free TRACE: enter dsa_key_free: key == NULL TRACE: enter rsa_key_free TRACE: leave rsa_key_free TRACE: leave sign_key_free ARG: 1 # echo $? 100 # Does anyone have any ideas what could be causing this? Has anyone seen this on other platforms or is happy that dropbear does return the correct exit codes in their tests? Thanks, Roger From roger at planbit.co.uk Sat Dec 1 01:38:03 2007 From: roger at planbit.co.uk (roger at planbit.co.uk) Date: Fri, 30 Nov 2007 16:38:03 -0000 (GMT) Subject: Dropbear 0.50 server returnsexit code 255 to ssh when app returns 0 In-Reply-To: <57805.88.96.204.222.1196434355.squirrel@portal.planbit.co.uk> References: <57805.88.96.204.222.1196434355.squirrel@portal.planbit.co.uk> Message-ID: <53938.88.96.204.222.1196440683.squirrel@portal.planbit.co.uk> More information appended... > Hi, > > We are running the Dropbear 0.50 SSH server on an ARM9 platform. We are > connecting to it from a fast quad-core intel server over 100-Base-T. > > We found this problem when trying to build Perl for the target. The > cross-compile process uploads and runs programs on the target and checks > the exit code from the SSH client to check the target program's exit code. > > The ARM9 platform is running a stock Linux 2.6.18 kernel compiled with the > GCC CodeSourcery 2006q3-26 v4.1.1. > > The host Intel platform is running CentOS5 with OpenSSH_4.3p2. > > A sample shell script on the target is: > > #!/bin/bash > echo "ARG: $1" > exit $1 > > When we run dropbear 0.50 server on the target without debug enabled, we > get exit code 255 from SSH. e.g. > > # ssh root at 192.168.0.10 /tmp/test.sh 1 > ARG: 1 > # echo $? > 255 > # > > # ssh root at 192.168.0.10 /tmp/test.sh 100 > ARG: 1 > # echo $? > 255 > # > > If we recompile dropbear with debug enabled, but don't pass the -v option > when starting dropbear, the behavior is the same. If we run dropbear with > the "-F -E -v" options, we get the correct exit codes. > > # ssh root at 192.168.0.10 /tmp/test.sh 1 > TRACE: enter sign_key_free > TRACE: enter dsa_key_free > TRACE: enter dsa_key_free: key == NULL > TRACE: enter rsa_key_free > TRACE: leave rsa_key_free > TRACE: leave sign_key_free > ARG: 1 > # echo $? > 1 > # > > # ssh root at 192.168.0.10 /tmp/test.sh 100 > TRACE: enter sign_key_free > TRACE: enter dsa_key_free > TRACE: enter dsa_key_free: key == NULL > TRACE: enter rsa_key_free > TRACE: leave rsa_key_free > TRACE: leave sign_key_free > ARG: 1 > # echo $? > 100 > # > > Does anyone have any ideas what could be causing this? > > Has anyone seen this on other platforms or is happy that dropbear does > return the correct exit codes in their tests? > > Thanks, > > Roger > I have upgraded the host to OpenSSH 4.7 and the problem persists. Turning on full logging on the host provides the following end trace on a failing connection (when dropbear is not generating logging output to the serial terminal): debug2: channel 0: open confirm rwindow 8000 rmax 8000 ARG: 100 debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 0: close_fds r -1 w -1 e 7 c -1 debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.1 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status -1 On a working connection, when dropbear is not generating logging output to the serial terminal, following end trace is gathered: debug2: channel 0: written 106 to efd 7 ARG: 100 debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 0: close_fds r -1 w -1 e 7 c -1 debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.5 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 100 With the working connection, we get the "client_input_channel_req" event coming in whereas in the failing connection, it doesn't occur. Does this information give anyone a clue/suggestion as to what may be failing? Thanks. From roger at planbit.co.uk Sat Dec 1 01:41:29 2007 From: roger at planbit.co.uk (roger at planbit.co.uk) Date: Fri, 30 Nov 2007 16:41:29 -0000 (GMT) Subject: Dropbear 0.50 server returnsexit code 255 to ssh when app returns 0 In-Reply-To: <53938.88.96.204.222.1196440683.squirrel@portal.planbit.co.uk> References: <57805.88.96.204.222.1196434355.squirrel@portal.planbit.co.uk> <53938.88.96.204.222.1196440683.squirrel@portal.planbit.co.uk> Message-ID: <55650.88.96.204.222.1196440889.squirrel@portal.planbit.co.uk> > More information appended... > >> Hi, >> >> We are running the Dropbear 0.50 SSH server on an ARM9 platform. We are >> connecting to it from a fast quad-core intel server over 100-Base-T. >> >> We found this problem when trying to build Perl for the target. The >> cross-compile process uploads and runs programs on the target and checks >> the exit code from the SSH client to check the target program's exit >> code. >> >> The ARM9 platform is running a stock Linux 2.6.18 kernel compiled with >> the >> GCC CodeSourcery 2006q3-26 v4.1.1. >> >> The host Intel platform is running CentOS5 with OpenSSH_4.3p2. >> >> A sample shell script on the target is: >> >> #!/bin/bash >> echo "ARG: $1" >> exit $1 >> >> When we run dropbear 0.50 server on the target without debug enabled, we >> get exit code 255 from SSH. e.g. >> >> # ssh root at 192.168.0.10 /tmp/test.sh 1 >> ARG: 1 >> # echo $? >> 255 >> # >> >> # ssh root at 192.168.0.10 /tmp/test.sh 100 >> ARG: 1 >> # echo $? >> 255 >> # >> >> If we recompile dropbear with debug enabled, but don't pass the -v >> option >> when starting dropbear, the behavior is the same. If we run dropbear >> with >> the "-F -E -v" options, we get the correct exit codes. >> >> # ssh root at 192.168.0.10 /tmp/test.sh 1 >> TRACE: enter sign_key_free >> TRACE: enter dsa_key_free >> TRACE: enter dsa_key_free: key == NULL >> TRACE: enter rsa_key_free >> TRACE: leave rsa_key_free >> TRACE: leave sign_key_free >> ARG: 1 >> # echo $? >> 1 >> # >> >> # ssh root at 192.168.0.10 /tmp/test.sh 100 >> TRACE: enter sign_key_free >> TRACE: enter dsa_key_free >> TRACE: enter dsa_key_free: key == NULL >> TRACE: enter rsa_key_free >> TRACE: leave rsa_key_free >> TRACE: leave sign_key_free >> ARG: 1 >> # echo $? >> 100 >> # >> >> Does anyone have any ideas what could be causing this? >> >> Has anyone seen this on other platforms or is happy that dropbear does >> return the correct exit codes in their tests? >> >> Thanks, >> >> Roger >> > > I have upgraded the host to OpenSSH 4.7 and the problem persists. > > Turning on full logging on the host provides the following end trace on a > failing connection (when dropbear is not generating logging output to the > serial terminal): > > debug2: channel 0: open confirm rwindow 8000 rmax 8000 > ARG: 100 > debug2: channel 0: rcvd eof > debug2: channel 0: output open -> drain > debug2: channel 0: obuf empty > debug2: channel 0: close_write > debug2: channel 0: output drain -> closed > debug2: channel 0: rcvd close > debug2: channel 0: close_read > debug2: channel 0: input open -> closed > debug3: channel 0: will not send data after close > debug2: channel 0: almost dead > debug2: channel 0: gc: notify user > debug2: channel 0: gc: user detached > debug2: channel 0: send close > debug2: channel 0: is dead > debug2: channel 0: garbage collecting > debug1: channel 0: free: client-session, nchannels 1 > debug3: channel 0: status: The following connections are open: > #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) > > debug3: channel 0: close_fds r -1 w -1 e 7 c -1 > debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.1 seconds > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 > debug1: Exit status -1 > TYPO: Below should read ..."when dropbear is generating logging"... The cut-and-paste daemon strikes again! > > On a working connection, when dropbear is not generating logging output to > the serial terminal, following end trace is gathered: > > debug2: channel 0: written 106 to efd 7 > ARG: 100 > debug2: channel 0: rcvd eof > debug2: channel 0: output open -> drain > debug2: channel 0: obuf empty > debug2: channel 0: close_write > debug2: channel 0: output drain -> closed > debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 > debug2: channel 0: rcvd close > debug2: channel 0: close_read > debug2: channel 0: input open -> closed > debug3: channel 0: will not send data after close > debug2: channel 0: almost dead > debug2: channel 0: gc: notify user > debug2: channel 0: gc: user detached > debug2: channel 0: send close > debug2: channel 0: is dead > debug2: channel 0: garbage collecting > debug1: channel 0: free: client-session, nchannels 1 > debug3: channel 0: status: The following connections are open: > #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) > > debug3: channel 0: close_fds r -1 w -1 e 7 c -1 > debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.5 seconds > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 > debug1: Exit status 100 > > > With the working connection, we get the "client_input_channel_req" event > coming in whereas in the failing connection, it doesn't occur. > > Does this information give anyone a clue/suggestion as to what may be > failing? > > Thanks. > From philippe.brand at safe-protect.com Tue Dec 4 20:56:56 2007 From: philippe.brand at safe-protect.com (Philippe Brand) Date: Tue, 04 Dec 2007 12:56:56 +0100 Subject: Is this a bug? 2: the return Message-ID: <47554088.5040104@safe-protect.com> Hello there, I think I've come accross a problem with dropbear >=0.49, originating long time ago from a fix done in 0.49 version abtou FD writability. For remote control purpose I'm using dbclient on an appliance (A) to send command to another system (B). A sends to B /usr/bin/dbclient -p $someport -y -i /whatever/.ssh/id_rsa $someuser@$ip "$cmd" $cmd holds /usr/local/bin/someutil someutil is a C compiled program which setuid() then forks and execve a shell script. Parent process does not detach from terminal. As soon as 'someutil' forks, ssh session ends, but 'someutil' continues to run nicely. However I simply loose 'someutil' output. If I replace $cmd by "/usr/local/bin/someutil; touch /tmp/foobar", same things again, but I can see /tmp/foobar is actually touched. Things run nicely using 0.48.1. I personnaly think that original example is wrong, in the way that a simple "sleep 10&" does not detach from terminal. I agree that session should be close if a "nohup sleep 10 >/dev/null 2>&1 &" command was launch but not if a program "simply" forks. I apologize for both my english, being not my natural language, and lack of time inspecting code. >>On Fri, Mar 24, 2006 at 10:09:30PM -0500, Rob Landley wrote: >> If I do the following: >> >> dbclient user at system "sleep 10& echo hello" >> >> It should return right after printing hello, but it doesn't. It waits until >> the child process exits. >> >> This is a known, longstanding but in OpenSSH on Linux. It doesn't do this on >> OpenBSD (the OpenSSH developers insist that it must therefore be a Linux bug, >> but the Linux developers I talked to wondered what they were drinking, if I >> recall correctly from when I asked in 2001.) An xterm won't do this, telnet >> won't do this... Just OpenSSH on Linux (not OpenBSD). And now dropbear. >> >> Is dropbear intentionally copying this bug? > >I've had a quick look, and I think that it is a bug, though >it hasn't been intentionally copied from OpenSSH. The fix >should be relatively straightfoward, I'll make sure it goes >into the next release. Currently Dropbear won't close the FD >for a shell until the process exits. Instead it should just >be testing for writability of the the FD. > >Thanks for the report. > >Matt -- Philippe BRAND Safe-Protect This signature has been created using 100% recycled spams catched by a Safe-Protect BOX. Linux user -------------- next part -------------- A non-text attachment was scrubbed... Name: philippe_brand.vcf Type: text/x-vcard Size: 263 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20071204/a6a80997/attachment.vcf From rob at landley.net Wed Dec 5 05:21:22 2007 From: rob at landley.net (Rob Landley) Date: Tue, 4 Dec 2007 14:21:22 -0600 Subject: Is this a bug? 2: the return In-Reply-To: <47554088.5040104@safe-protect.com> References: <47554088.5040104@safe-protect.com> Message-ID: <200712041421.22938.rob@landley.net> On Tuesday 04 December 2007 05:56:56 Philippe Brand wrote: > Hello there, > > I think I've come accross a problem with dropbear >=0.49, originating > long time ago from a fix done in 0.49 version abtou FD writability. > For remote control purpose I'm using dbclient on an appliance (A) to > send command to another system (B). > > A sends to B > /usr/bin/dbclient -p $someport -y -i /whatever/.ssh/id_rsa > $someuser@$ip "$cmd" > > $cmd holds /usr/local/bin/someutil > > someutil is a C compiled program which setuid() then forks and execve a > shell script. Parent process does not detach from terminal. > As soon as 'someutil' forks, ssh session ends, but 'someutil' continues > to run nicely. However I simply loose 'someutil' output. It's not a question of "fork", it's a question of the parent process exiting. When the program you run via ssh exits, ssh should exit. It doesn't matter what background processes it left running. Does your program do what you want if you use "telnet" instead of ssh? Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From philippe.brand at safe-protect.com Thu Dec 6 01:18:31 2007 From: philippe.brand at safe-protect.com (Philippe Brand) Date: Wed, 05 Dec 2007 17:18:31 +0100 Subject: Is this a bug? 2: the return In-Reply-To: <200712041421.22938.rob@landley.net> References: <47554088.5040104@safe-protect.com> <200712041421.22938.rob@landley.net> Message-ID: <4756CF57.3050300@safe-protect.com> Rob Landley wrote: > > It's not a question of "fork", it's a question of the parent process exiting. > When the program you run via ssh exits, ssh should exit. It doesn't matter > what background processes it left running. > > Does your program do what you want if you use "telnet" instead of ssh? > > I completly agree, fork() has nothing to do there, as my latest attemps shows it. My main concerns is that parent process does *not* exit. debug traces on remote system continues to shows up after ssh session is killed on calling system. Some additional notes: In fact everything works fine if dbclient command is run interactively from shell (>=0.48.1). Problem only occurs when command is run from cgi (for dropbear versions >=0.49, as 0.48.1 works fine called from cgi). I recompiled dbclient 0.50 using DEBUG_TRACE and -v Interactive trace / Cgi trace (beginning of trace stricly identical for both methods) .... enter cli_sessionloop enter read_packet enter decrypt_packet leave decrypt_packet leave read_packet enter process_packet process_packet: packet type = 91 enter recv_msg_channel_open_confirmation new chan remote 0 local 0 setnonblocking: 1 leave setnonblocking setnonblocking: 0 leave setnonblocking setnonblocking: 2 leave setnonblocking enter send_chansess_shell_req enter encrypt_packet() encrypt_packet type is 98 enter buf_compress leave buf_compress enter writemac leave writemac enter enqueue leave enqueue leave encrypt_packet() leave send_chansess_shell_req leave recv_msg_channel_open_confirmation leave process_packet check_close: writefd 1, readfd 0, errfd 2, sent_close 0, recv_close 0 writebuf size 0 extrabuf size 0 enter cli_sessionloop enter write_packet empty queue dequeing leave write_packet Here comes differences: check_close: writefd 1, readfd 0, errfd 2, sent_close 0, recv_close 0 send normal readfd writebuf size 0 extrabuf size 0 enter send_msg_channel_data enter cli_sessionloop enter send_msg_channel_data isextended 0 fd 0 enter read_packet maxlen 16375 enter decrypt_packet CLOSE some fd 0 leave decrypt_packet leave send_msg_channel_data: len 0 read err 17 or EOF for fd 0 leave read_packet check_close: writefd 1, readfd -1, errfd 2, sent_close 0, recv_close 0 enter process_packet writebuf size 0 extrabuf size 0 process_packet: packet type = 94 enter recv_msg_channel_data length 41 leave recv_msg_channel_data leave process_packet check_close: writefd 1, readfd 0, errfd 2, sent_close 0, recv_close 0 writebuf size 41 extrabuf size 0 enter cli_sessionloop enter writechannel fd 1 FIRST stdout()MESSAGE COMIONG FROM someutil writechannel wrote 41 leave writechannel So it seems readfd is set when ran from cgi (using system() call, but tried other methods too). Tried also launching same command through crontab, same effect. >From cgi, tried also to launch remote shell script directly without using C container (thus dbclient from cgi, same effect). -- Philippe BRAND -------------- next part -------------- A non-text attachment was scrubbed... Name: philippe_brand.vcf Type: text/x-vcard Size: 275 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20071205/0a506ae6/attachment.vcf From harryrat at postnuklear.de Fri Dec 14 06:52:46 2007 From: harryrat at postnuklear.de (Harald Radke) Date: Thu, 13 Dec 2007 22:52:46 +0100 Subject: Dropbear 0.50 compiling issues Message-ID: <200712132252.46587.harryrat@postnuklear.de> Hi there! I am quite new, so plz be a little patient with me (; I downloaded the dropbear 0.5 source, unpacked it and ./configure --prefix=/usr when doing make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" compiling bails out with: ----------------------- gcc -I. -I. -I./libtomcrypt/src/headers/ -Os -W -Wall -DDROPBEAR_SERVER -DDBMULTI_dropbear -DDROPBEAR_MULTI -c -o cli-auth.c: In function 'recv_msg_userauth_specific_60': cli-auth.c:109: error: 'cli_ses' undeclared (first use in this function) cli-auth.c:109: error: (Each undeclared identifier is reported only once cli-auth.c:109: error: for each function it appears in.) cli-auth.c: In function 'recv_msg_userauth_failure': cli-auth.c:147: error: 'cli_ses' undeclared (first use in this function) cli-auth.c: In function 'recv_msg_userauth_success': cli-auth.c:233: error: 'cli_ses' undeclared (first use in this function) cli-auth.c: In function 'cli_auth_try': cli-auth.c:249: error: 'cli_ses' undeclared (first use in this function) make: *** [cli-auth.o] Error 1 When leaving dbclient out of that list, it works. ( so I have a "2-pass" make run |-: ) Another problem: Using Dropbear > 0.48 with scp to the dropbear site, transfer takes place, but the file on destination side has zero length...I tried 0.49, same prob...with 0.48 it was fine.... I use uclibc Related to that: I saw the following when compiling above: scpmisc.c: In function 'addargs': scpmisc.c:148: warning: implicit declaration of function 'vasprintf' maybe this is related to the scp issue? Any help would be appreciated Thx Harry From roberto.foglietta at gmail.com Sun Dec 23 02:43:46 2007 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Sat, 22 Dec 2007 18:43:46 +0100 Subject: PATCH: sftp subsystem request via ssh In-Reply-To: References: Message-ID: <476D4CD2.80300@gmail.com> Roberto A. Foglietta wrote: > Hi to all folks, > > I develop this patch in order to avoid -s usage when > > sftp -s /remote/path/sftp-server -S /local/path/dbclient > > now if -s is not specified a subsystem request would be sent > > Cheers, > please use this one, the previous was not applying cleanly to 0.50 Cheers, /Roberto -------------- next part -------------- A non-text attachment was scrubbed... Name: dropbear_sftp_subsystem_request.patch Type: text/x-patch Size: 446 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20071222/4c9c8a37/attachment.bin