From steve at 4dllc.com Tue Jan 3 22:20:00 2006 From: steve at 4dllc.com (Steve Comfort) Date: Tue, 03 Jan 2006 16:20:00 +0200 Subject: Port Forwarding Message-ID: <43BA8810.8060608@4dllc.com> Hi all, Happy New Year, etc. Will dropbear support port forwarding such as the following SSH example? ssh -N -f -L 8080:www.intranet.local:80 user at firewall I can't find anything about such switches in the man page, and so far scratching around on the net has been inconclusive! Best regards Steve Comfort -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060103/3303d81b/attachment.htm From steve at 4dllc.com Tue Jan 3 22:22:33 2006 From: steve at 4dllc.com (Steve Comfort) Date: Tue, 03 Jan 2006 16:22:33 +0200 Subject: Ignore previous (sorry) Message-ID: <43BA88A9.1030200@4dllc.com> Hi all, Doh. I have just noticed the new release, which seems to add the features... Best regards Steve Comfort From geek at IraqiGeek.com Wed Jan 4 08:02:00 2006 From: geek at IraqiGeek.com (IraqiGeek) Date: Wed, 4 Jan 2006 00:02:00 -0000 Subject: dropbear on LFS Message-ID: <055801c610c2$17f882a0$1401a8c0@Alitablet> Hi all, I have downloaded the 0.47 source tarball and compiled it on my LFS system, which went fine. After installation, I created DSS and RSA key files. Now wehn I execute dropbear, nothing happens, it looks like dropbear has executed, but in reality its not doing anything (I checked with ps-A and pidof). I have used that same LFS system to build ttyLinux, and dropbear runs just fine over there and I can ssh that box. Is there anything I am missing here? anything that I need to do before running dropbear as an SSH server? Regards, IraqiGeek www.iraqigeek.com From cristian.ionescu-idbohrn at axis.com Wed Jan 4 16:52:52 2006 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Wed, 4 Jan 2006 09:52:52 +0100 (CET) Subject: dropbear on LFS In-Reply-To: <055801c610c2$17f882a0$1401a8c0@Alitablet> References: <055801c610c2$17f882a0$1401a8c0@Alitablet> Message-ID: <0601040949410.744@somehost> On Wed, 4 Jan 2006, IraqiGeek wrote: > Now wehn I execute dropbear, nothing happens, it looks like dropbear > has executed, but in reality its not doing anything (I checked with > ps-A and pidof). What do you see when you run it in foreground: # dropbear -F -E Cheers, Cristian From geek at IraqiGeek.com Wed Jan 4 17:21:12 2006 From: geek at IraqiGeek.com (IraqiGeek) Date: Wed, 4 Jan 2006 09:21:12 -0000 Subject: dropbear on LFS References: <055801c610c2$17f882a0$1401a8c0@Alitablet> <0601040949410.744@somehost> Message-ID: <05c201c61110$35fdeb20$1401a8c0@Alitablet> On Wednesday, January 04, 2006 8:52 AM GMT, Cristian Ionescu-Idbohrn wrote: > On Wed, 4 Jan 2006, IraqiGeek wrote: > >> Now wehn I execute dropbear, nothing happens, it looks like dropbear >> has executed, but in reality its not doing anything (I checked with >> ps-A and pidof). > > What do you see when you run it in foreground: > > # dropbear -F -E > > > Cheers, > Cristian I had the key files named as dss_host_key and rsa_host_key under /etc/ssh, while dropbear was looking for dropbear_dss_host_key, dropbear_rsa_host_key under /etc/dropbear. I forgot to change the rules in options.h. Thanks Christian, its all working now. Regards, IraqiGeek www.iraqigeek.com From dropbear at pivert.org Thu Jan 5 01:00:21 2006 From: dropbear at pivert.org (dropbear@pivert.org) Date: Wed, 4 Jan 2006 18:00:21 +0100 Subject: dropbear client : No auth methods could be used Message-ID: <200601041800.22633.dropbear@pivert.org> Hi, I have a problem that I can't solve with dropbear. I have a workstation that I can log to from anywhere, except from my OpenWRT that has dropbear-client instead of OpenSSH. With dropbear, I can only ssh to localhost (dropbear-server). Using dropbear-client and password interactive. root at star:/etc# ssh 192.168.1.3 ssh: connection to root at 192.168.1.3:22 exited: No auth methods could be used. What's my problem ? Thanks ! From matt at ucc.asn.au Thu Jan 5 08:47:28 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 5 Jan 2006 08:47:28 +0800 Subject: dropbear client : No auth methods could be used In-Reply-To: <200601041800.22633.dropbear@pivert.org> References: <200601041800.22633.dropbear@pivert.org> Message-ID: <20060105004728.GN17242@ucc.gu.uwa.edu.au> On Wed, Jan 04, 2006 at 06:00:21PM +0100, dropbear at pivert.org wrote: > Hi, I have a problem that I can't solve with dropbear. > > I have a workstation that I can log to from anywhere, except from my OpenWRT > that has dropbear-client instead of OpenSSH. > With dropbear, I can only ssh to localhost (dropbear-server). > > Using dropbear-client and password interactive. > > root at star:/etc# ssh 192.168.1.3 > ssh: connection to root at 192.168.1.3:22 exited: No auth methods could be used. > > What's my problem ? Which version of dropbear? If it's 0.46, the problem is most likely that the OpenSSH server doesn't allow plain "password" authentication, only "keyboard-interactive". 0.47 supports keyboard-interactive authentication, however I'm don't think 0.47 is in any OpenWRT releases yet. There are probably standalone packages at tracker.openwrt.org. Alternatively, you can enable plain password authentication in the sshd_config file. I _think_ the option is "PasswordAuthentication", though not 100% sure. Cheers, Matt From kaloz at dune.hu Thu Jan 5 09:19:50 2006 From: kaloz at dune.hu (Imre Kaloz) Date: Thu, 05 Jan 2006 02:19:50 +0100 Subject: dropbear client : No auth methods could be used In-Reply-To: <20060105004728.GN17242@ucc.gu.uwa.edu.au> References: <200601041800.22633.dropbear@pivert.org> <20060105004728.GN17242@ucc.gu.uwa.edu.au> Message-ID: On Thu, 05 Jan 2006 01:47:28 +0100, Matt Johnston wrote: > 0.47 supports keyboard-interactive authentication, however > I'm don't think 0.47 is in any OpenWRT releases yet. There > are probably standalone packages at tracker.openwrt.org. Maybe he should "ipkg update" "ipkg install dropbear" :) 0.47 is there for both trunk and whiterussian. Imre From dropbear at pivert.org Thu Jan 5 15:14:49 2006 From: dropbear at pivert.org (dropbear@pivert.org) Date: Thu, 5 Jan 2006 08:14:49 +0100 Subject: dropbear client : No auth methods could be used In-Reply-To: References: <200601041800.22633.dropbear@pivert.org> <20060105004728.GN17242@ucc.gu.uwa.edu.au> Message-ID: <200601050814.49349.dropbear@pivert.org> Hello ! I had a misunderstanding of the "password" authentication and "keyboard-interactive". Yes, this works now with PasswordAuthentication yes in my OpenSSH server. Many thanks. Le Thursday 5 January 2006 02:19, Imre Kaloz a ?crit?: > On Thu, 05 Jan 2006 01:47:28 +0100, Matt Johnston wrote: > > 0.47 supports keyboard-interactive authentication, however > > I'm don't think 0.47 is in any OpenWRT releases yet. There > > are probably standalone packages at tracker.openwrt.org. > > Maybe he should "ipkg update" "ipkg install dropbear" :) > > 0.47 is there for both trunk and whiterussian. > > > Imre From dropbear at pivert.org Thu Jan 5 15:17:28 2006 From: dropbear at pivert.org (dropbear@pivert.org) Date: Thu, 5 Jan 2006 08:17:28 +0100 Subject: dropbear client : No auth methods could be usedHi, In-Reply-To: References: <200601041800.22633.dropbear@pivert.org> <20060105004728.GN17242@ucc.gu.uwa.edu.au> Message-ID: <200601050817.28991.dropbear@pivert.org> Hi, The last version is 0.45-4 on OpenWRT. Thanks. Le Thursday 5 January 2006 02:19, Imre Kaloz a ?crit?: > On Thu, 05 Jan 2006 01:47:28 +0100, Matt Johnston wrote: > > 0.47 supports keyboard-interactive authentication, however > > I'm don't think 0.47 is in any OpenWRT releases yet. There > > are probably standalone packages at tracker.openwrt.org. > > Maybe he should "ipkg update" "ipkg install dropbear" :) > > 0.47 is there for both trunk and whiterussian. > > > Imre From steve at 4dllc.com Fri Jan 6 19:02:30 2006 From: steve at 4dllc.com (Steve Comfort) Date: Fri, 06 Jan 2006 13:02:30 +0200 Subject: Port forwarding Message-ID: <43BE4E46.8020103@4dllc.com> Hi all, We have a WiFi device, onto which we'd like to put a web server for configuration purposes. We obviously want it to be secure, and we don't have enough space to put OpenSSL and an https style browser on the board. So port forwarding seemed to be the answer. It is more than possible that I don't understand port forwarding correctly, but anyways ... I am trying the following command on my PC : ssh -N -f -L 8000:[IP Address of device]:80 root at device My understanding of the above is that if I direct my browser at localhost:8000, ssh/dropbear will forward this connection to port 80 on the board, and that this forwarding will take place once the firewall has been penetrated. (Port 22 is allowed, port 80 is not) ? However, this does not seem to happen. I have compiled Dropbear 0.47 for the device, and I start it with the -a option. I also have ENABLE_SVR_REMOTETCPFWD defined in options.h. The only way I can see the web server, is if I open up port 80 on the firewall. This however somewhat negates the point of having an SSH tunnel. Is my understanding of port forwarding completely flawed, or do I need to add parameters to the -a option on dropbear, or ... what? Any suggestions will be appreciated. Best regards Steve Comfort PS: For you Aussies from a serf efrican - congrats on a great performance by Ricky Ponting this morning :) Maybe we'll manage to beat you in one next month :) (And maybe pigs will fly) From matt at ucc.asn.au Fri Jan 6 19:28:45 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 6 Jan 2006 19:28:45 +0800 Subject: Port forwarding In-Reply-To: <43BE4E46.8020103@4dllc.com> References: <43BE4E46.8020103@4dllc.com> Message-ID: <20060106112845.GK17242@ucc.gu.uwa.edu.au> On Fri, Jan 06, 2006 at 01:02:30PM +0200, Steve Comfort wrote: > Hi all, > > We have a WiFi device, onto which we'd like to put a web server for > configuration purposes. We obviously want it to be secure, and we don't > have enough space to put OpenSSL and an https style browser on the > board. So port forwarding seemed to be the answer. It is more than > possible that I don't understand port forwarding correctly, but anyways ... > > I am trying the following command on my PC : > > ssh -N -f -L 8000:[IP Address of device]:80 root at device The IP address is from the perspective of "device", so try "-L 8000:localhost:80" instead and see how that goes. Let me know if that doesn't work. Matt > PS: For you Aussies from a serf efrican - congrats on a great > performance by Ricky Ponting this morning :) Maybe we'll manage to beat > you in one next month :) (And maybe pigs will fly) Heh, we'll see ;) From georgem at novatech-llc.com Fri Jan 6 23:24:59 2006 From: georgem at novatech-llc.com (George McCollister) Date: Fri, 06 Jan 2006 09:24:59 -0600 Subject: dropbear fails on uClinux ARM NOMMU target with gcc-3.4.5 but not gcc-2.95.3 Message-ID: <43BE8BCB.4070707@novatech-llc.com> I'm building/running the version of dropbear 0.43 included with uClinux-dist-20051014. Target is little endian ARM CPU with no MMU. If I use the arm-elf-tools-20040427 toolchain everything builds and works fine. I cannot to the target using both ssh-rsa and ssh-dss. If I use my binutils-2.15.90.0.1.1 + gcc-3.4.5 toolchain everything builds and runs but... when the host connects with ssh-rsa it errors out with: RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 debug1: ssh_rsa_verify: signature incorrect key_verify failed for server_host_key when the host connects with ssh-dss the target errors out with: /bin/staticdropbear: dss.c: 366: buf_put_dss_sign: Assertion `writelen <= 20' failed. I haven't had any other trouble with the binutils-2.15.90.0.1.1 + gcc-3.4.5 toolchain, but I haven't done anything very math intensive like crypto. Are there any testsuites that can be compiled to exhaustively test the toolchain / target CPU? Below are details: CPU: OKI ML67Q5003 (ARM7TDMI) uClinux-dist-20051014 Kernel: linux-2.6.14 linux-2.6.14-uc0.patch linux-2.6.14-hsc0.patch uClibc: 0.9.27 dropbear: v0.43 from uClinux-dist-20051014. No changes made. I did rm -rf uClinux-dist/user/dropbear and reextracted from uClinux-dist-20051014.tar.bz2 before each test to be sure. Working toolchain: From http://opensrc.sec.samsung.com/download/arm-elf-tools-20040427.sh binutils-2.14 gcc version 2.95.3 20010315 (release)(ColdFire patches - 20010318 from http://fiddes.net/coldfire/)(uClinux XIP and shared lib patches from http://www.snapgear.com/) Non working toolchain: binutils-2.15.90.0.1.1 gcc-3.4.5 Configured with: ./configure --target=arm-elf --prefix=/usr/local --disable-shared --enable-languages=c --enable-target-optspace --with-gnu-ld --disable-nls --disable-__cxa_atexit --disable-c99 --disable-clocale --disable-c-mbchar --disable-long-long --enable-cxx-flags=-D_ISOC99_SOURCE,-D_BSD_SOURCE --with-float=soft Thread model: single elf2flt-20040326 inetd.conf: ssh stream tcp nowait root /bin/staticdropbear -i telnet stream tcp nowait root /bin/telnetd From target (client forcing ssh-rsa): Load /bin/staticdropbear: TEXT=600040-6236a0 DATA=660004-6664b4 BSS=6664b4-67a464 [23] Jan 01 00:01:34 Child connection from 172.16.64.11:34123 [23] Jan 01 00:01:40 exit before auth: error reading: Connection reset by peer From host (client forcing ssh-rsa): ssh -vvv -o HostKeyAlgorithms=ssh-rsa root at 172.16.64.208 OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 172.16.64.208 [172.16.64.208] port 22. debug1: Connection established. debug1: identity file /home/georgem/.ssh/identity type -1 debug1: identity file /home/georgem/.ssh/id_rsa type -1 debug1: identity file /home/georgem/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version dropbear_0.43 debug1: no match: dropbear_0.43 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.9p1 debug2: fd 5 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: hmac-sha1,hmac-md5 debug2: kex_parse_kexinit: hmac-sha1,hmac-md5 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client 3des-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server 3des-cbc hmac-md5 none debug2: dh_gen_key: priv key bits set: 203/384 debug2: bits set: 520/1024 debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug3: check_host_in_hostfile: filename /home/georgem/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: filename /home/georgem/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug2: no key of type 0 for host 172.16.64.208 debug3: check_host_in_hostfile: filename /home/georgem/.ssh/known_hosts2 debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2 debug3: check_host_in_hostfile: filename /home/georgem/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug2: no key of type 2 for host 172.16.64.208 The authenticity of host '172.16.64.208 (172.16.64.208)' can't be established. RSA key fingerprint is 72:21:49:0c:5e:f6:91:20:ff:d5:f2:69:d4:fc:b9:e1. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '172.16.64.208' (RSA) to the list of known hosts. debug2: bits set: 516/1024 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 debug1: ssh_rsa_verify: signature incorrect key_verify failed for server_host_key From target (client forcing ssh-dss): [24] Jan 01 00:34:17 Child connection from 172.16.64.11:34216 /bin/staticdropbear: dss.c: 366: buf_put_dss_sign: Assertion `writelen <= 20' failed. From host (client forcing ssh-dss): ssh -vvv -o HostKeyAlgorithms=ssh-dss root at 172.16.64.208 OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 172.16.64.208 [172.16.64.208] port 22. debug1: Connection established. debug1: identity file /home/georgem/.ssh/identity type -1 debug1: identity file /home/georgem/.ssh/id_rsa type -1 debug1: identity file /home/georgem/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version dropbear_0.43 debug1: no match: dropbear_0.43 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.9p1 debug2: fd 5 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: hmac-sha1,hmac-md5 debug2: kex_parse_kexinit: hmac-sha1,hmac-md5 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client 3des-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server 3des-cbc hmac-md5 none debug2: dh_gen_key: priv key bits set: 191/384 debug2: bits set: 513/1024 debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY Connection closed by 172.16.64.208 Any solutions, conjectures or wild ass guesses are greatly appreciated. Cheers, George McCollister This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. From jamie at shareable.org Fri Jan 6 23:47:43 2006 From: jamie at shareable.org (Jamie Lokier) Date: Fri, 6 Jan 2006 15:47:43 +0000 Subject: dropbear fails on uClinux ARM NOMMU target with gcc-3.4.5 but not gcc-2.95.3 In-Reply-To: <43BE8BCB.4070707@novatech-llc.com> References: <43BE8BCB.4070707@novatech-llc.com> Message-ID: <20060106154743.GB23063@mail.shareable.org> George McCollister wrote: > I'm building/running the version of dropbear 0.43 included with > uClinux-dist-20051014. Target is little endian ARM CPU with no MMU. If I > use the arm-elf-tools-20040427 toolchain everything builds and works > fine. I cannot to the target using both ssh-rsa and ssh-dss. If I use my > binutils-2.15.90.0.1.1 + gcc-3.4.5 toolchain everything builds and runs > but... > > when the host connects with ssh-rsa it errors out with: > > RSA_public_decrypt failed: error:0407006A:rsa > routines:RSA_padding_check_PKCS1_type_1:block type is not 01 > debug1: ssh_rsa_verify: signature incorrect > key_verify failed for server_host_key > > when the host connects with ssh-dss the target errors out with: > > /bin/staticdropbear: dss.c: 366: buf_put_dss_sign: Assertion `writelen > <= 20' failed. > > I haven't had any other trouble with the binutils-2.15.90.0.1.1 + > gcc-3.4.5 toolchain, but I haven't done anything very math intensive > like crypto. Are there any testsuites that can be compiled to > exhaustively test the toolchain / target CPU? There are toolchain testsuites - look at GCC's testsuite. Though, you might find it hard to run in this environment. I've also seen problems with dropbear-0.48 and gcc-3.4.3, but the problems I see are different: spurious memory accesses to addresses that shouldn't be accessed. I switched from gcc-2.95 at the same time as moving from dropbear-0.47, so haven't narrowed down whether it's a compiler problem, or a dropbear problem. Have you tried adding the -fno-strict-aliasing option, or even -O1 or -O0, to compiler flags? Type-based aliasing is an optimisation, turned on at -O2 or higher (unless -fno-strict-aliasing is used), which does tend to break programs which got away with certain things before. Expecially code which accesses memory in a variety of ways to speed up bit-twiddling - typical of crypto code. Maybe that's it? -- Jamie From jamie at shareable.org Fri Jan 6 23:55:47 2006 From: jamie at shareable.org (Jamie Lokier) Date: Fri, 6 Jan 2006 15:55:47 +0000 Subject: dropbear fails on uClinux ARM NOMMU target with gcc-3.4.5 but not gcc-2.95.3 In-Reply-To: <20060106154743.GB23063@mail.shareable.org> References: <43BE8BCB.4070707@novatech-llc.com> <20060106154743.GB23063@mail.shareable.org> Message-ID: <20060106155547.GA30245@mail.shareable.org> Jamie Lokier wrote: > I've also seen problems with dropbear-0.48 and gcc-3.4.3, but the > problems I see are different: spurious memory accesses to addresses > that shouldn't be accessed. > > I switched from gcc-2.95 at the same time as moving from > dropbear-0.47, so haven't narrowed down whether it's a compiler > problem, or a dropbear problem. Ah, in case it wasn't clear, I'm also using ARM NOMMU uCLinux. Evidently not the same toolchain though (different GCC version). Is there an authoritative "good" toolchain? I am quite confused about the different toolchains around for these systems - no version in particular seems to stand out as particularly recommended. -- Jamie From matt at ucc.asn.au Sat Jan 7 00:25:00 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 7 Jan 2006 00:25:00 +0800 Subject: dropbear fails on uClinux ARM NOMMU target with gcc-3.4.5 but not gcc-2.95.3 In-Reply-To: <43BE8BCB.4070707@novatech-llc.com> References: <43BE8BCB.4070707@novatech-llc.com> Message-ID: <20060106162500.GT17242@ucc.gu.uwa.edu.au> On Fri, Jan 06, 2006 at 09:24:59AM -0600, George McCollister wrote: > I'm building/running the version of dropbear 0.43 included with > uClinux-dist-20051014. Target is little endian ARM CPU with no MMU. If I > use the arm-elf-tools-20040427 toolchain everything builds and works > fine. I cannot to the target using both ssh-rsa and ssh-dss. If I use my > binutils-2.15.90.0.1.1 + gcc-3.4.5 toolchain everything builds and runs > but... > > when the host connects with ssh-rsa it errors out with: > > RSA_public_decrypt failed: error:0407006A:rsa > routines:RSA_padding_check_PKCS1_type_1:block type is not 01 > debug1: ssh_rsa_verify: signature incorrect > key_verify failed for server_host_key > > when the host connects with ssh-dss the target errors out with: > > /bin/staticdropbear: dss.c: 366: buf_put_dss_sign: Assertion `writelen > <= 20' failed. Both the DSS and RSA failures look like some particular big-number operation isn't giving the right result. Whether it's a compiler error or a code error is kind of hard to tell. The fact that one compiler works correctly makes me a bit suspicious of the gcc 3.4.5 compiler - crypto code seems to bring out many obscure compiler bugs. It's also plausible that libtommath (or libtomcrypt) is doing some broken struct aliasing or something, that a newer compiler won't cope with. Does CFLAGS=-O0 make a difference? > I haven't had any other trouble with the binutils-2.15.90.0.1.1 + > gcc-3.4.5 toolchain, but I haven't done anything very math intensive > like crypto. Are there any testsuites that can be compiled to > exhaustively test the toolchain / target CPU? LibTomCrypt and LibTomMath (the libraries used by Dropbear) both have testsuites. I'd suggest running testsuites for LibTomMath 0.27 and LibTomCrypt 0.96, as those are the versions bundled with Dropbear 0.43. (http://libtomcrypt.org/download.html and http://math.libtomcrypt.org/download.html) For LibTomMath, just "make test" in the top-level directory. It seems that LibTomMath's testsuite is run with "./mtest/mtest | ./test" - the test will run indefinitely, exiting on an error. mtest just generates a test set to work from. LibTomCrypt requires you to run "make" in the top-level first to build the library. Then copy the attached makefile to demos/test/makefile (there are a couple of errors), then run "make" in demos/test. You should then be able to ./test the program there. I assume some modifications will be required for cross-compiling etc. I can't really think of any other obvious things to try - I don't recall fixing any related issues in newer releases, though newer libtommath/libtomcrypt releases might improve things. Let me know how it goes. Cheers, Matt From georgem at novatech-llc.com Sat Jan 7 00:46:47 2006 From: georgem at novatech-llc.com (George McCollister) Date: Fri, 06 Jan 2006 10:46:47 -0600 Subject: dropbear fails on uClinux ARM NOMMU target with gcc-3.4.5 but not gcc-2.95.3 In-Reply-To: <20060106155547.GA30245@mail.shareable.org> References: <43BE8BCB.4070707@novatech-llc.com> <20060106154743.GB23063@mail.shareable.org> <20060106155547.GA30245@mail.shareable.org> Message-ID: <43BE9EF7.7020108@novatech-llc.com> Jamie Lokier wrote: >Jamie Lokier wrote: > > >>I've also seen problems with dropbear-0.48 and gcc-3.4.3, but the >>problems I see are different: spurious memory accesses to addresses >>that shouldn't be accessed. >> >>I switched from gcc-2.95 at the same time as moving from >>dropbear-0.47, so haven't narrowed down whether it's a compiler >>problem, or a dropbear problem. >> >> > >Ah, in case it wasn't clear, I'm also using ARM NOMMU uCLinux. > >Evidently not the same toolchain though (different GCC version). Is >there an authoritative "good" toolchain? I am quite confused about >the different toolchains around for these systems - no version in >particular seems to stand out as particularly recommended. > >-- Jamie > > Jamie and Matt, I'm going to try O1 and O0. I'll post my results in a few hours. Jamie, You should be confused because it very confusing! This is what I see (maybe I'm confused too). The official uclinux-elf-tools can be found here: http://www.uclinux.org/pub/uClinux/m68k-elf-tools/ The problem is that this toolchain hasn't been updated since 20030314. Infact uClinux doesn't support ARM NOMMU as a target for 2.6.x kernels! Even if you get the patches to fix ARM NOMMU in 2.6.x this toolchain won't build a working kernel. There is an official experimental gcc 3.x toolchain which can be found here: http://www.uclinux.org/pub/uClinux/m68k-elf-tools/gcc-3/ I don't trust this toolchain for a couple of reasons. Mainly it seems this is a m68k toolchain with ARM added as an after thought. Secondly it seems like a bad idea to use this tool chain to compile 2.6.x arm nommu kernels when they don't even offer it as a target in their distribution. Which brings me to: http://opensrc.sec.samsung.com/ The place to get 2.6.x patches to re-add for MMU less ARM. As far as I can tell this is the best place to go for all of your 2.6.x ARM MMU less needs. They provide a 2.95.3 tool chain (this is the one I'm using. Its the only one I've found that actually compiles 2.6.x) They also provide a GCC 3.4.0 tool chain. I wasn't able to get this one to work. (I'll try again now that I've learned a lot). http://opensrc.sec.samsung.com/download.html One thing that has me confused is that between 2.95.x and 3.4.x they switch from target arm-elf to arm-uclinux. I also do not like the 3.4.x version at this site because they try to install themselves under /root. I firmly believe that when you are working with cross compilers and cross compiled kernels you don't want to be root on your host. The last thing I need is to accidently break my linux install by getting arm libraries and binaries mixed up with valid files. One very odd problem seems to be that on the 3.4.x tools chains (including the one I built) you need to modify elf2flt.ld otherwise your user mode applications using the binflt executable format have trouble finding the relocation data. http://mailman.uclinux.org/pipermail/uclinux-dev/2005-June/033243.html With all of the old toolchains, most of which I can't find source/patches/configuration to reproduce I decided enough was enough. By building my own tool chain at least I'll begin to learn whats going on and have the freedom to try different combinations of binutils and gcc and different configuration parameters. Maybe at some point this could even help other people that are having similar issues. Unfortunately this plan isn't perfect as we can see by the fact that dropbear isn't working with my toolchain. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. From jamie at shareable.org Sat Jan 7 01:11:03 2006 From: jamie at shareable.org (Jamie Lokier) Date: Fri, 6 Jan 2006 17:11:03 +0000 Subject: dropbear fails on uClinux ARM NOMMU target with gcc-3.4.5 but not gcc-2.95.3 In-Reply-To: <43BE9EF7.7020108@novatech-llc.com> References: <43BE8BCB.4070707@novatech-llc.com> <20060106154743.GB23063@mail.shareable.org> <20060106155547.GA30245@mail.shareable.org> <43BE9EF7.7020108@novatech-llc.com> Message-ID: <20060106171103.GB4740@mail.shareable.org> George McCollister wrote: > As far as I can tell this is the best place to go for all of your 2.6.x > ARM MMU less needs. > They provide a 2.95.3 tool chain (this is the one I'm using. Its the > only one I've found that actually compiles 2.6.x) I have a 2.95.3 toolchain that came with an SDK, but it crashes when compiling some programs like rsync, so I'm not using it for everything. I wonder if it's the _same_ 2.95.3 as yours? I have a 3.4.3 toolchain called uclinux-tools-20050221 (and it doesn't install in /root), is that one you've come across? > With all of the old toolchains, most of which I can't find > source/patches/configuration to reproduce I decided enough was enough. > By building my own tool chain at least I'll begin to learn whats going > on and have the freedom to try different combinations of binutils and > gcc and different configuration parameters. Maybe at some point this > could even help other people that are having similar issues. > > Unfortunately this plan isn't perfect as we can see by the fact that > dropbear isn't working with my toolchain. > A bigger problem is that all these versions have custom GCC or binutils patches, don't they? I think your message would be a great start to a much-needed thrashing it out on uclinux-dev. How would you feel about taking this conversation over there? At very least, it would be good to have a list of the available toolchains, instead of the very scattered information that's about at the moment. -- Jamie From georgem at novatech-llc.com Sat Jan 7 01:51:53 2006 From: georgem at novatech-llc.com (George McCollister) Date: Fri, 06 Jan 2006 11:51:53 -0600 Subject: dropbear fails on uClinux ARM NOMMU target with gcc-3.4.5 but not gcc-2.95.3 In-Reply-To: <20060106162500.GT17242@ucc.gu.uwa.edu.au> References: <43BE8BCB.4070707@novatech-llc.com> <20060106162500.GT17242@ucc.gu.uwa.edu.au> Message-ID: <43BEAE39.7090006@novatech-llc.com> Matt Johnston wrote: >On Fri, Jan 06, 2006 at 09:24:59AM -0600, George McCollister wrote: > > >>I'm building/running the version of dropbear 0.43 included with >>uClinux-dist-20051014. Target is little endian ARM CPU with no MMU. If I >>use the arm-elf-tools-20040427 toolchain everything builds and works >>fine. I cannot to the target using both ssh-rsa and ssh-dss. If I use my >>binutils-2.15.90.0.1.1 + gcc-3.4.5 toolchain everything builds and runs >>but... >> >>when the host connects with ssh-rsa it errors out with: >> >>RSA_public_decrypt failed: error:0407006A:rsa >>routines:RSA_padding_check_PKCS1_type_1:block type is not 01 >>debug1: ssh_rsa_verify: signature incorrect >>key_verify failed for server_host_key >> >>when the host connects with ssh-dss the target errors out with: >> >>/bin/staticdropbear: dss.c: 366: buf_put_dss_sign: Assertion `writelen >><= 20' failed. >> >> > >Both the DSS and RSA failures look like some particular >big-number operation isn't giving the right result. Whether >it's a compiler error or a code error is kind of hard to >tell. The fact that one compiler works correctly makes me a >bit suspicious of the gcc 3.4.5 compiler - crypto code seems >to bring out many obscure compiler bugs. It's also plausible >that libtommath (or libtomcrypt) is doing some broken struct >aliasing or something, that a newer compiler won't cope >with. > >Does CFLAGS=-O0 make a difference? > > > >>I haven't had any other trouble with the binutils-2.15.90.0.1.1 + >>gcc-3.4.5 toolchain, but I haven't done anything very math intensive >>like crypto. Are there any testsuites that can be compiled to >>exhaustively test the toolchain / target CPU? >> >> > >LibTomCrypt and LibTomMath (the libraries used by Dropbear) >both have testsuites. I'd suggest running testsuites for >LibTomMath 0.27 and LibTomCrypt 0.96, as those are the >versions bundled with Dropbear 0.43. >(http://libtomcrypt.org/download.html >and http://math.libtomcrypt.org/download.html) > >For LibTomMath, just "make test" in the top-level directory. >It seems that LibTomMath's testsuite is run with >"./mtest/mtest | ./test" - the test will run indefinitely, >exiting on an error. mtest just generates a test set to work >from. > >LibTomCrypt requires you to run "make" in the top-level >first to build the library. Then copy the attached makefile >to demos/test/makefile (there are a couple of errors), then >run "make" in demos/test. You should then be able to ./test >the program there. > >I assume some modifications will be required for >cross-compiling etc. > >I can't really think of any other obvious things to try - I >don't recall fixing any related issues in newer releases, >though newer libtommath/libtomcrypt releases might improve >things. > >Let me know how it goes. > >Cheers, >Matt > > > Going from -O2 to -O0 didn't help. I verified dropbear, libtommath, and libtomcrypt are now getting -O0. I'll try scouring through the ARM specific gcc flags and gcc configuration and see if I can find something that will fix it. Cheers, George McCollister This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. From jamie at shareable.org Thu Jan 12 08:30:48 2006 From: jamie at shareable.org (Jamie Lokier) Date: Thu, 12 Jan 2006 00:30:48 +0000 Subject: dropbear fails on uClinux ARM NOMMU target with gcc-3.4.5 but not gcc-2.95.3 In-Reply-To: <43BEAE39.7090006@novatech-llc.com> References: <43BE8BCB.4070707@novatech-llc.com> <20060106162500.GT17242@ucc.gu.uwa.edu.au> <43BEAE39.7090006@novatech-llc.com> Message-ID: <20060112003048.GA23936@mail.shareable.org> Regarding dropbear 0.47 (not 0.43 as this thread started with), I have seen consistent bus errors when compiling with the default options and GCC 3.4.3 on an ARM CPU with no MMU. (GCC from uclinux-tools-20050221). I was unable to use Dropbear's client at all with this compiler. GCC 2.95.3 for the same system was fine. If I add the flag "-fno-strict-aliasing" to CFLAGS in Dropbear's Makefile, then it seems to be fixed. Well, so far I haven't seen any of these bus errors. If that is really fixing the problem, it indicates a type-aliasing error in Dropbear or the associated libraries. These errors can be fixed by accessing the type-aliased memory through a union (as described in the GCC manual), or with sufficiently recent GCC versions, using the "may_alias" attribute. Alternatively, simply using "-fno-strict-aliasing" is fine although it suppress some optimisation possibilities. But look at it this way: the Linux kernel uses that flag, so it can't be too bad. Until they are fixed, I recommend adding -fno-strict-aliasing to Dropbear's CFLAGS. The flag is accepted by GCC 2.95 too, and I think it's redundant with that version. Enjoy, -- Jamie From wcm at guinix.com Tue Jan 17 03:37:35 2006 From: wcm at guinix.com (Wayne Marshall) Date: 16 Jan 2006 11:37:35 -0800 Subject: slackmatic port: dropbear for slackware Message-ID: <20060116113735.3d09831b@alloy.copperisle.com> I've put up a slackmatic port for dropbear in the "guinix" repository: http://www.slackmatic.org/site.cgi?repoview=guinix This port includes support for two run systems: * "classic" slackware rc.d script * daemontools service The "runit-dropbear" port, available separately, provides a runit-based service. I observed the following issues with the current release (0.47): * the progress bar (SCPPROGRESS=1) fails for both glibc and dietlibc builds, due to absence of strlcat() * the scp build fails with dietlibc, due to unresolved and non-standard typedefs (u_int, u_long) Benefits of slackmatic: * BOIM: build once, install many * integrated use of dietlibc * uses standard slackware package management utilities Feedback appreciated! Wayne From lists at 19q.net Tue Jan 17 07:38:45 2006 From: lists at 19q.net (Axel) Date: Tue, 17 Jan 2006 00:38:45 +0100 Subject: public key auth problems Message-ID: <43CC2E85.3050902@19q.net> Hello, I have dropbear 0.47 installed (OpenWRT). The key is type rsa with 2048 bits. The client is MacOSX. My problem is: I can't get pubkey auth to work. There are no error messages concerning pubkey auth. Does someone have a hint for me what maybe wrong? Did I forget something obvious? Thanks. Greets Axel ---on server --- root at linksys:~# dropbear -E -F -s -p 5555 [544] Jan 17 00:30:10 Not forking [545] Jan 17 00:30:58 Child connection from 10.x.y.z:49184 [545] Jan 17 00:31:00 exit before auth (user 'root', 0 fails): Exited normally --- --- on server --- # ls -la /root drwx------ 1 root root 0 Jan 16 21:00 . drwxr-xr-x 1 root root 0 Jan 1 2000 .. drwx------ 1 root root 0 Jan 1 23:06 .ssh [...] # ls -la /root/.ssh drwx------ 1 root root 0 Jan 1 23:06 . drwx------ 1 root root 0 Jan 16 21:00 .. -rw------- 1 root root 397 Jan 16 22:34 authorized_keys --- --- on client --- xl at pax:~$ ssh -i .ssh/privat/linksys -v -p 5555 root at 10.y.z.x OpenSSH_3.8.1p1, OpenSSL 0.9.7i 14 Oct 2005 debug1: Reading configuration data /.ssh/config debug1: Reading configuration data /etc/ssh_config debug1: Connecting to 10.y.z.x [10.y.z.x] port 5555. debug1: Connection established. debug1: identity file .ssh/privat/row type 1 debug1: Remote protocol version 2.0, remote software version dropbear_0.47 debug1: no match: dropbear_0.47 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 debug1: Miscellaneous failure No credentials cache found debug1: Miscellaneous failure No credentials cache found debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client blowfish-cbc hmac-md5 zlib debug1: kex: client->server blowfish-cbc hmac-md5 zlib debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug1: Host '10.y.z.x' is known and matches the RSA host key. debug1: Found key in /.ssh/known_hosts:98 debug1: ssh_rsa_verify: signature correct debug1: Enabling compression at level 6. debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering public key: .ssh/privat/linksys debug1: Authentications that can continue: publickey debug1: No more authentication methods to try. Permission denied (publickey). From matt at ucc.asn.au Tue Jan 17 10:48:13 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 17 Jan 2006 10:48:13 +0800 Subject: public key auth problems In-Reply-To: <43CC2E85.3050902@19q.net> References: <43CC2E85.3050902@19q.net> Message-ID: <20060117024813.GD11179@ucc.gu.uwa.edu.au> On Tue, Jan 17, 2006 at 12:38:45AM +0100, Axel wrote: > Hello, > > I have dropbear 0.47 installed (OpenWRT). The key is type rsa with 2048 > bits. The client is MacOSX. > My problem is: I can't get pubkey auth to work. There are no error > messages concerning pubkey auth. > Does someone have a hint for me what maybe wrong? Did I forget something > obvious? Thanks. > # ls -la /root/.ssh > -rw------- 1 root root 397 Jan 16 22:34 authorized_keys What version of OpenWRT are you using? In whiterussian rc4, Dropbear uses /etc/dropbear/authorized_keys for the keys. For my openwrt install here (rc4), root's homedir is /tmp not /root (specified in /etc/passwd). If you're running rc3 or earlier perhaps try /tmp/.ssh/authorized_keys instead? (note that /tmp is cleared on reboot, hence rc4 using /etc). Cheers, Matt From wimpunk at gmail.com Wed Feb 1 16:46:08 2006 From: wimpunk at gmail.com (Wim Vinckier) Date: Wed, 1 Feb 2006 09:46:08 +0100 Subject: Troubles cross compiling dropbear-0.47 for arm-linux (gcc 3.3.2) Message-ID: <5c43128e0602010046v224cde0bo2196aa4c3c116553@mail.gmail.com> This is the error I get: arm-linux-gcc -I. -I./libtomcrypt/src/headers/ -Os -W -Wall -DDROPBEAR_SERVER -DDROPBEAR_CLIENT -c -o svr-runopts.o svr-runopts.c svr-runopts.c: In function `svr_getopts': svr-runopts.c:108: error: structure has no member named `nolocaltcp' svr-runopts.c:109: error: structure has no member named `noremotetcp' svr-runopts.c:159: error: structure has no member named `nolocaltcp' svr-runopts.c:164: error: structure has no member named `noremotetcp' svr-runopts.c:167: error: structure has no member named `listen_fwd_all' make: *** [svr-runopts.o] Error 1 This is the script I use to configure dropbear export CPPFLAGS='-I../linux-2.6.11.11/include' PATH="$PATH:/usr/local/arm/3.3.2/bin" HOST="arm-linux" ./configure --disable-zlib --host=${HOST} \ It works perfect with dropbear-0.46 but 0.47 fails. Anyone a suggestion? tnx, wim. From matt at ucc.asn.au Wed Feb 1 17:10:01 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 1 Feb 2006 17:10:01 +0800 Subject: Troubles cross compiling dropbear-0.47 for arm-linux (gcc 3.3.2) In-Reply-To: <5c43128e0602010046v224cde0bo2196aa4c3c116553@mail.gmail.com> References: <5c43128e0602010046v224cde0bo2196aa4c3c116553@mail.gmail.com> Message-ID: <20060201091001.GD10407@ucc.gu.uwa.edu.au> On Wed, Feb 01, 2006 at 09:46:08AM +0100, Wim Vinckier wrote: > This is the error I get: > > arm-linux-gcc -I. -I./libtomcrypt/src/headers/ -Os -W -Wall > -DDROPBEAR_SERVER -DDROPBEAR_CLIENT -c -o svr-runopts.o > svr-runopts.c > svr-runopts.c: In function `svr_getopts': > svr-runopts.c:108: error: structure has no member named `nolocaltcp' > svr-runopts.c:109: error: structure has no member named `noremotetcp' > svr-runopts.c:159: error: structure has no member named `nolocaltcp' > svr-runopts.c:164: error: structure has no member named `noremotetcp' > svr-runopts.c:167: error: structure has no member named `listen_fwd_all' > make: *** [svr-runopts.o] Error 1 > > This is the script I use to configure dropbear > > export CPPFLAGS='-I../linux-2.6.11.11/include' > PATH="$PATH:/usr/local/arm/3.3.2/bin" > HOST="arm-linux" > > ./configure --disable-zlib --host=${HOST} \ > > It works perfect with dropbear-0.46 but 0.47 fails. Anyone a suggestion? My mistake, the attached svr-runopts.c should fix things. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: svr-runopts.c Type: text/x-csrc Size: 7744 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060201/41846835/svr-runopts-0001.c From wimpunk at gmail.com Wed Feb 1 18:16:58 2006 From: wimpunk at gmail.com (Wim Vinckier) Date: Wed, 1 Feb 2006 11:16:58 +0100 Subject: Troubles cross compiling dropbear-0.47 for arm-linux (gcc 3.3.2) In-Reply-To: <20060201091001.GD10407@ucc.gu.uwa.edu.au> References: <5c43128e0602010046v224cde0bo2196aa4c3c116553@mail.gmail.com> <20060201091001.GD10407@ucc.gu.uwa.edu.au> Message-ID: <5c43128e0602010216h43a9abd8i28b78229f225820c@mail.gmail.com> On 2/1/06, Matt Johnston wrote: > On Wed, Feb 01, 2006 at 09:46:08AM +0100, Wim Vinckier wrote: > > This is the error I get: > > > > arm-linux-gcc -I. -I./libtomcrypt/src/headers/ -Os -W -Wall > > -DDROPBEAR_SERVER -DDROPBEAR_CLIENT -c -o svr-runopts.o > > svr-runopts.c > > svr-runopts.c: In function `svr_getopts': > > svr-runopts.c:108: error: structure has no member named `nolocaltcp' > > svr-runopts.c:109: error: structure has no member named `noremotetcp' > > svr-runopts.c:159: error: structure has no member named `nolocaltcp' > > svr-runopts.c:164: error: structure has no member named `noremotetcp' > > svr-runopts.c:167: error: structure has no member named `listen_fwd_all' > > make: *** [svr-runopts.o] Error 1 > > > > This is the script I use to configure dropbear > > > > export CPPFLAGS='-I../linux-2.6.11.11/include' > > PATH="$PATH:/usr/local/arm/3.3.2/bin" > > HOST="arm-linux" > > > > ./configure --disable-zlib --host=${HOST} \ > > > > It works perfect with dropbear-0.46 but 0.47 fails. Anyone a suggestion? > > My mistake, the attached svr-runopts.c should fix things. > > Matt > > > Tnx, works perfect now. wim. From unclesmiff at yahoo.com Sun Feb 12 03:10:56 2006 From: unclesmiff at yahoo.com (Smiff) Date: Sat, 11 Feb 2006 11:10:56 -0800 (PST) Subject: dropbear with keys Message-ID: <20060211191056.34640.qmail@web50714.mail.yahoo.com> Hi, I installed dropbear client on computer A. I then used SSH to login to computer B as user1. It worked but it prompted me for a password. I don't want to be prompted, I want to use Public Private key. So I do dropbearkey -t rsa -f myfile. This created a encrypted myfile and printed a key to the screen. I copied the printed key to computer B and pasted it into ~user1/.ssh/authorized_keys file, I also changed /etc/ssh/ssh_config to have PasswordAuthentication no. I then restarted the sshd on computer B. but when I try to SSH into it again, like last time it says "No auth methods could be used" -- I suspect dropbear client (ssh) cannot see it's private key, where must I place the file and what must it be called? --------------------------------- What are the most popular cars? Find out at Yahoo! Autos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060211/7dc08766/attachment.html From matt at ucc.asn.au Sun Feb 12 13:31:55 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sun, 12 Feb 2006 13:31:55 +0800 Subject: dropbear with keys In-Reply-To: <20060211191056.34640.qmail@web50714.mail.yahoo.com> References: <20060211191056.34640.qmail@web50714.mail.yahoo.com> Message-ID: <20060212053155.GS17375@ucc.gu.uwa.edu.au> On Sat, Feb 11, 2006 at 11:10:56AM -0800, Smiff wrote: > Hi, > > I installed dropbear client on computer A. I then used SSH to login to computer B as user1. It worked but it prompted me for a password. > > I don't want to be prompted, I want to use Public Private key. So I do dropbearkey -t rsa -f myfile. This created a encrypted myfile and printed a key to the screen. I copied the printed key to computer B and pasted it into ~user1/.ssh/authorized_keys file, I also changed /etc/ssh/ssh_config to have PasswordAuthentication no. I then restarted the sshd on computer B. > > but when I try to SSH into it again, like last time it says "No auth methods could be used" -- I suspect dropbear client (ssh) cannot see it's private key, where must I place the file and what must it be called? Does "dbclient -i myfile user at remotehost" work? There isn't a default path at the moment. Matt From tglenn at syntech-fuelmaster.com Tue Feb 14 05:14:19 2006 From: tglenn at syntech-fuelmaster.com (Taylor Glenn) Date: Mon, 13 Feb 2006 16:14:19 -0500 Subject: difficulty with public key auth for non-root users Message-ID: Hi, I'm having a bit of trouble getting public keys to work for users other than root. I'm running 0.47 on a gumstix (linux 2.6.11, uClibc-0.9.27). I take an authorized_keys file that works for root, copy it to the user's .ssh directory, chown and set the same relative permissions (700 for ~, ~/.ssh, 600 for ~/.ssh/authorized_keys), and then try to log in as the user--only to get a password prompt. Is there something that I am missing (sorry I was a bit sparse on the details, let me know if you want more)? Can anyone else replicate this behavior? Thanks, Taylor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060213/67422e14/attachment.html From matt at infostream.com.au Thu Feb 16 08:01:13 2006 From: matt at infostream.com.au (Matt Wlazlo) Date: Thu, 16 Feb 2006 11:01:13 +1100 Subject: client crash Message-ID: <20060216110113.1ded94e6@localhost.localdomain> Hi, dbclient connects without a problem, but after a certain amount of output crashes. I've run strace and it seems to fail after write() returns EAGAIN. An example session: [root at PPC /root]# strace -o/work/ssh3.strace ./dbclient matt at matt Password: Last login: Thu Feb 16 10:45:05 2006 from cyc2 [matt at matt ~]$ ls authorized_keys fstab.bak test-message.sh bin \uffff[root at PPC /root]# relevant strace output: read(4, "\272\331\303\215\316QM\"p\250\370\"\2708\332\255\233\n"..., 204) = 204 write(1, " \33[0mgmail.csv\33[0m \33[0"..., 595) = -1 EAGAIN (Resource temporarily unavailable) close(1) = 0 Anyone have any ideas? The client is running on a PPC board. Funny thing is that the server works without a problem. Cheers, Matt. -- Matthew Wlazlo Infostream Pty Ltd Ground Floor, 7 Narabang Way BELROSE NSW 2085 Ph. +61 2 9986 3522 Fax: + 61 2 9986 3599 matt at infostream.com.au www.infostream.com.au From matt at ucc.asn.au Fri Feb 17 18:48:54 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 17 Feb 2006 18:48:54 +0800 Subject: client crash In-Reply-To: <20060216110113.1ded94e6@localhost.localdomain> References: <20060216110113.1ded94e6@localhost.localdomain> Message-ID: <20060217104854.GN17375@ucc.gu.uwa.edu.au> On Thu, Feb 16, 2006 at 11:01:13AM +1100, Matt Wlazlo wrote: > Hi, > > dbclient connects without a problem, but after a certain amount of output > crashes. I've run strace and it seems to fail after write() returns EAGAIN. > relevant strace output: > > read(4, "\272\331\303\215\316QM\"p\250\370\"\2708\332\255\233\n"..., 204) = 204 > write(1, " \33[0mgmail.csv\33[0m \33[0"..., 595) = -1 EAGAIN > (Resource temporarily unavailable) > close(1) = 0 > > > Anyone have any ideas? The client is running on a PPC board. Funny thing > is that the server works without a problem. I don't recall seeing that before. Could you send more of the strace for context, so I can see what FDs are set in the select() before it? What OS/libc is it running on? Cheers, Matt From matt at ucc.asn.au Fri Feb 17 18:53:07 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 17 Feb 2006 18:53:07 +0800 Subject: difficulty with public key auth for non-root users In-Reply-To: References: Message-ID: <20060217105307.GO17375@ucc.gu.uwa.edu.au> On Mon, Feb 13, 2006 at 04:14:19PM -0500, Taylor Glenn wrote: > Hi, > > I'm having a bit of trouble getting public keys to work for users other > than root. I'm running 0.47 on a gumstix (linux 2.6.11, uClibc-0.9.27). > > I take an authorized_keys file that works for root, copy it to the > user's .ssh directory, chown and set the same relative permissions (700 > for ~, ~/.ssh, 600 for ~/.ssh/authorized_keys), and then try to log in > as the user--only to get a password prompt. > > Is there something that I am missing (sorry I was a bit sparse on the > details, let me know if you want more)? Can anyone else replicate this > behavior? I don't see anything obvious that would be wrong - have you checked /var/log/auth.log (or similar) for any warnings/errors from Dropbear? I assume that logging in as the user with a password works fine? The only other common issue is possibly line wrapping/formatting in the authorized_keys file if it was copied/pasted. The homedir for the user is set correctly in /etc/passwd? Cheers, Matt From tglenn at syntech-fuelmaster.com Sat Feb 18 00:25:19 2006 From: tglenn at syntech-fuelmaster.com (Taylor Glenn) Date: Fri, 17 Feb 2006 11:25:19 -0500 Subject: difficulty with public key auth for non-root users Message-ID: Thanks Matt, Turns out I had typo'd the homedir in /etc/passwd, so of course dropbear wasn't seeing the authorized_keys file. Sorry to bug you about that, I feel silly. -Taylor -----Original Message----- From: Matt Johnston [mailto:matt at ucc.asn.au] Sent: Friday, February 17, 2006 5:53 AM To: Taylor Glenn Cc: dropbear at ucc.asn.au Subject: Re: difficulty with public key auth for non-root users On Mon, Feb 13, 2006 at 04:14:19PM -0500, Taylor Glenn wrote: > Hi, > > I'm having a bit of trouble getting public keys to work for users > other than root. I'm running 0.47 on a gumstix (linux 2.6.11, uClibc-0.9.27). > > I take an authorized_keys file that works for root, copy it to the > user's .ssh directory, chown and set the same relative permissions > (700 for ~, ~/.ssh, 600 for ~/.ssh/authorized_keys), and then try to > log in as the user--only to get a password prompt. > > Is there something that I am missing (sorry I was a bit sparse on the > details, let me know if you want more)? Can anyone else replicate this > behavior? I don't see anything obvious that would be wrong - have you checked /var/log/auth.log (or similar) for any warnings/errors from Dropbear? I assume that logging in as the user with a password works fine? The only other common issue is possibly line wrapping/formatting in the authorized_keys file if it was copied/pasted. The homedir for the user is set correctly in /etc/passwd? Cheers, Matt From rushi.lala at gmail.com Fri Mar 3 23:23:18 2006 From: rushi.lala at gmail.com (Rushi Lala) Date: Fri, 3 Mar 2006 15:23:18 +0000 Subject: ssh to 3com (len - macsize) % blocksize != 0) Message-ID: Hello, I am trying to connect to 3COM 3031 router from busybox+dropbear no keys password only authentication and its giving me strange looks :(. any suggestion would be great !! Ta Rushi /* check packet length */ if ((len > MAX_PACKET_LEN) || (len < MIN_PACKET_LEN + macsize) || || ((len - macsize) % blocksize != 0)) { dropbear_exit("bad packet size %d", len); } ~ $ ssh -vvv xxxx at 192.168.0.1 TRACE: non-flag arg: 'xxxx at 192.168.0.1' TRACE: user='xxxx' host='192.168.0.1' port='22' TRACE: enter connect_remote TRACE: leave connect_remote: sock 3 TRACE: enter session_init TRACE: kexinitialise() TRACE: leave session_init TRACE: enter ident_readln TRACE: leave ident_readln: return 16 TRACE: remoteident: SSH-1.5-VRP-3.3 TRACE: enter encrypt_packet() TRACE: encrypt_packet type is 20 TRACE: enter writemac TRACE: leave writemac TRACE: enter enqueue TRACE: leave enqueue TRACE: leave encrypt_packet() TRACE: DATAALLOWED=0 TRACE: -> KEXINIT TRACE: enter write_packet TRACE: empty queue dequeing TRACE: leave write_packet TRACE: enter read_packet TRACE: macsize=0 blocksize=8 len=1 TRACE: enter cli_tty_cleanup TRACE: leave cli_tty_cleanup: not in raw mode TRACE: enter session_cleanup TRACE: enter chancleanup TRACE: leave chancleanup TRACE: leave session_cleanup ssh: connection to xxxx at 192.168.0.1:22 exited: bad packet size 89 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060303/cf564d21/attachment.htm From matt at ucc.asn.au Fri Mar 3 23:45:26 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 3 Mar 2006 23:45:26 +0800 Subject: ssh to 3com (len - macsize) % blocksize != 0) In-Reply-To: References: Message-ID: <20060303154526.GQ24032@ucc.gu.uwa.edu.au> On Fri, Mar 03, 2006 at 03:23:18PM +0000, Rushi Lala wrote: > Hello, > > I am trying to connect to 3COM 3031 router from busybox+dropbear no keys > password only authentication and its giving me strange looks :(. > > any suggestion would be great !! > TRACE: remoteident: SSH-1.5-VRP-3.3 > TRACE: leave session_cleanup > ssh: connection to xxxx at 192.168.0.1:22 exited: bad packet size 89 Dropbear only supports SSH v2, the 3com device seems to only do SSH v1. Through a bit of an oversight, I never added code to check versions when the client connects - I'll make sure the next release does that. Cheers, Matt Johnston From dbc_dropbear at advan.ca Thu Mar 9 23:05:51 2006 From: dbc_dropbear at advan.ca (David Cook) Date: Thu, 09 Mar 2006 10:05:51 -0500 Subject: Port tunnelling over ssh Message-ID: <4410444F.2080707@advan.ca> I have used the following command to create a tunnel for rsync between the OpenWRT box running dropbear and my server. /usr/bin/ssh -i ${SSH_host_key} -p ${SSH_port} ${SSH_server} -l ${SSH_user} -L 873:${LAN_IP}:873 "keepalive ${Customer}" & (I am running a small program "keepalive" on the server to poll the device periodically so NAT tables don't go stale). Even though I specify the lan address (192.168.1.1) the tunnel only appears to work from the originating host by rsyncing to 127.0.0.1. I want to have other devices on the lan rsync to 192.168.1.1 so that my remote rsync server appears to be the gateway on the lan. What am I doing wrong or is this even possible? dbc. From matt at ucc.asn.au Fri Mar 10 10:53:44 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 10 Mar 2006 10:53:44 +0800 Subject: Port tunnelling over ssh In-Reply-To: <4410444F.2080707@advan.ca> References: <4410444F.2080707@advan.ca> Message-ID: <20060310025344.GD24032@ucc.gu.uwa.edu.au> On Thu, Mar 09, 2006 at 10:05:51AM -0500, David Cook wrote: > I have used the following command to create a tunnel for rsync between > the OpenWRT box running dropbear and my server. > /usr/bin/ssh -i ${SSH_host_key} -p ${SSH_port} ${SSH_server} -l > ${SSH_user} -L 873:${LAN_IP}:873 "keepalive ${Customer}" & > > (I am running a small program "keepalive" on the server to poll the > device periodically so NAT tables don't go stale). > > Even though I specify the lan address (192.168.1.1) the tunnel only > appears to work from the originating host by rsyncing to 127.0.0.1. > I want to have other devices on the lan rsync to 192.168.1.1 so that my > remote rsync server appears to be the gateway on the lan. > > What am I doing wrong or is this even possible? Does giving the -a option to dropbear (added in 0.47) do what you want? That'll make it listen on all interfaces, not just localhost. Cheers, Matt From matt at ucc.asn.au Fri Mar 10 14:10:28 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 10 Mar 2006 14:10:28 +0800 Subject: Dropbear 0.48 Message-ID: <20060310061028.GF24032@ucc.gu.uwa.edu.au> Hi all. I've put up Dropbear 0.48, which has a few fixes. It fixes the denial of service attack reported by Pablo Fernandez on bugtraq, which is actually a common problem with various network services (inetd and OpenSSH both seem "vulnerable"). Dropbear now has a per-IP pre-authentication connection limit, which make it harder for someone to use all the pre-auth connection slots. I've also updated scp to the latest OpenSSH version, fixing a security issue. http://matt.ucc.asn.au/dropbear/releases/dropbear-0.48.tar.gz Matt 0.48 - Thurs 9 March 2006 - Check that the circular buffer is properly empty before closing a channel, which could cause truncated transfers (thanks to Tomas Vanek for helping track it down) - Implement per-IP pre-authentication connection limits (after some poking from Pablo Fernandez) - Exit gracefully if trying to connect to as SSH v1 server (reported by Rushi Lala) - Only read /dev/random once at startup when in non-inetd mode - Allow ctrl-c to close a dbclient password prompt (may still have to press enter on some platforms) - Merged in uClinux patch for inetd mode - Updated to scp from OpenSSH 4.3p2 - fixes a security issue where use of system() could cause users to execute arbitrary code through malformed filenames, ref CVE-2006-0225 From openembedded at hrw.one.pl Fri Mar 10 17:39:29 2006 From: openembedded at hrw.one.pl (Marcin Juszkiewicz) Date: Fri, 10 Mar 2006 10:39:29 +0100 Subject: Dropbear 0.48 In-Reply-To: <20060310061028.GF24032@ucc.gu.uwa.edu.au> References: <20060310061028.GF24032@ucc.gu.uwa.edu.au> Message-ID: <200603101039.30417.openembedded@hrw.one.pl> Dnia pi?tek, 10 marca 2006 07:10, Matt Johnston napisa?: > I've put up Dropbear 0.48, which has a few fixes. > I've also updated scp to the latest OpenSSH version, fixing > a security issue. scp fails on compile phase without adding -D_GNU_SOURCE to CFLAGS. scp.o(.text+0x660): In function `bwlimit': scp.c: undefined reference to `TIMEVAL_TO_TIMESPEC' collect2: ld returned 1 exit status make: *** [multibinary] Error 1 -- JID: hrw-jabber.org Sharp Zaurus C-760 (OZ 3.5.x) OpenEmbedded/OpenZaurus/OPIE developer Try not! Do, or do not! There is no try! -- Yoda From matt at ucc.asn.au Sun Mar 12 13:05:59 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sun, 12 Mar 2006 13:05:59 +0800 Subject: Dropbear 0.48.1 - same as 0.48, but scp compiles In-Reply-To: <200603101039.30417.openembedded@hrw.one.pl> References: <20060310061028.GF24032@ucc.gu.uwa.edu.au> <200603101039.30417.openembedded@hrw.one.pl> Message-ID: <20060312050559.GC24032@ucc.gu.uwa.edu.au> On Fri, Mar 10, 2006 at 10:39:29AM +0100, Marcin Juszkiewicz wrote: > scp fails on compile phase without adding -D_GNU_SOURCE to CFLAGS. > > scp.o(.text+0x660): In function `bwlimit': > scp.c: undefined reference to `TIMEVAL_TO_TIMESPEC' > collect2: ld returned 1 exit status > make: *** [multibinary] Error 1 Sorry about that - forgot that the Debian package doesn't build scp when I was testing Linux. I've packaged up 0.48.1 which is identical except for the scp compile fix attached. Cheers, Matt --- CHANGES 4de896d8eb9ec752aaad4706a128f98fe199c869 +++ CHANGES 52d8155b7e65c65b47d646fa5f842a13ef25cada @@ -1,3 +1,7 @@ +0.48.1 - Sat 11 March 2006 + +- Compile fix for scp + 0.48 - Thurs 9 March 2006 - Check that the circular buffer is properly empty before --- scpmisc.h 14f223b0890febf280796d9cc48b37dbb212d311 +++ scpmisc.h 162472df78978824d5fc0838470aa9bc16f2b7d9 @@ -46,3 +46,24 @@ char *ssh_get_progname(char *); void fatal(char* fmt,...); void sanitise_stdfd(void); + +/* Required for non-BSD platforms, from OpenSSH's defines.h */ +#ifndef timersub +#define timersub(a, b, result) \ + do { \ + (result)->tv_sec = (a)->tv_sec - (b)->tv_sec; \ + (result)->tv_usec = (a)->tv_usec - (b)->tv_usec; \ + if ((result)->tv_usec < 0) { \ + --(result)->tv_sec; \ + (result)->tv_usec += 1000000; \ + } \ + } while (0) +#endif + +#ifndef TIMEVAL_TO_TIMESPEC +#define TIMEVAL_TO_TIMESPEC(tv, ts) { \ + (ts)->tv_sec = (tv)->tv_sec; \ + (ts)->tv_nsec = (tv)->tv_usec * 1000; \ +} +#endif + From openembedded at hrw.one.pl Mon Mar 13 05:57:14 2006 From: openembedded at hrw.one.pl (Marcin Juszkiewicz) Date: Sun, 12 Mar 2006 22:57:14 +0100 Subject: Dropbear 0.48.1 - same as 0.48, but scp compiles In-Reply-To: <20060312050559.GC24032@ucc.gu.uwa.edu.au> References: <20060310061028.GF24032@ucc.gu.uwa.edu.au> <200603101039.30417.openembedded@hrw.one.pl> <20060312050559.GC24032@ucc.gu.uwa.edu.au> Message-ID: <200603122257.14410.openembedded@hrw.one.pl> Dnia niedziela, 12 marca 2006 06:05, Matt Johnston napisa?: > > scp.o(.text+0x660): In function `bwlimit': > > scp.c: undefined reference to `TIMEVAL_TO_TIMESPEC' > > collect2: ld returned 1 exit status > > make: *** [multibinary] Error 1 > > Sorry about that - forgot that the Debian package doesn't > build scp when I was testing Linux. > > I've packaged up 0.48.1 which is identical except for the > scp compile fix attached. Thx - updated to 0.48.1 in OpenEmbedded. During next weekend I plan to release OpenZaurus 3.5.4 (distribution for Sharp Zaurus palmtops) and it will contain dropbear 0.48.1 in default rootfs. -- JID: hrw-jabber.org Palmtop: Sharp Zaurus C760 OpenEmbedded/OpenZaurus developer Think for yourselves and let others enjoy the privilege to do so, too. -- Voltaire From smitty_decoy at mac.com Wed Mar 15 13:23:33 2006 From: smitty_decoy at mac.com (Smith Kennedy) Date: Tue, 14 Mar 2006 22:23:33 -0700 Subject: question regarding port forwarding with dropbear Message-ID: <9FC43D52-61AA-4CA3-AD2C-41B7E351C1D1@mac.com> Hello, I have a router that is running dropbear for an ssh server. I am trying to use dropbear for "listener port forwarding" , but so far I am not able to do so. I am using the following arguments to the "ssh" command: ssh -g -N -R 9777:localhost:9778 foo at null.bitbucket.org If the "-g" argument is provided to ssh, and the sshd at the other end is the OpenSSH sshd, and its sshd_config file contains the "GatewayPorts yes" directive, then sshd on the remote host will begin listening on port 9777, forwarding any connections over the tunnel to port 9778 on the machine at the other end of the tunnel, and it all works. If this directive is missing then sshd will only listen on port 9777 for the loopback address (localhost:9777) instead of on all interfaces (*:9777), which defeats the purpose of the exercise. The corresponding argument for dropbear seems to be omitting the "-k" argument when starting dropbear. However, dropbear isn't being started with that argument. Is there something additional I need to do, or is this just a deficiency with dropbear? Thanks for any info, Smith From matt at ucc.asn.au Wed Mar 15 13:30:24 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 15 Mar 2006 13:30:24 +0800 Subject: question regarding port forwarding with dropbear In-Reply-To: <9FC43D52-61AA-4CA3-AD2C-41B7E351C1D1@mac.com> References: <9FC43D52-61AA-4CA3-AD2C-41B7E351C1D1@mac.com> Message-ID: <20060315053024.GE32089@ucc.gu.uwa.edu.au> On Tue, Mar 14, 2006 at 10:23:33PM -0700, Smith Kennedy wrote: > Hello, > > I have a router that is running dropbear for an ssh server. I am > trying to use dropbear for "listener port forwarding" , but so far I > am not able to do so. I am using the following arguments to the > "ssh" command: > > ssh -g -N -R 9777:localhost:9778 foo at null.bitbucket.org > > If the "-g" argument is provided to ssh, and the sshd at the other > end is the OpenSSH sshd, and its sshd_config file contains the > "GatewayPorts yes" directive, then sshd on the remote host will begin > listening on port 9777, forwarding any connections over the tunnel to > port 9778 on the machine at the other end of the tunnel, and it all > works. If this directive is missing then sshd will only listen on > port 9777 for the loopback address (localhost:9777) instead of on all > interfaces (*:9777), which defeats the purpose of the exercise. > > The corresponding argument for dropbear seems to be omitting the "-k" > argument when starting dropbear. However, dropbear isn't being > started with that argument. > > Is there something additional I need to do, or is this just a > deficiency with dropbear? You'll have to start the Dropbear server with the -a argument (equivalent to the "gatewayports yes" directive). Dropbear's -k option disables "ssh -R" style forwarding entirely. Note that "-a" was only introduced in Dropbear 0.47. Let me know if that doesn't work. Cheers, Matt From simone.marzona at jet-research.it Fri Mar 17 19:12:32 2006 From: simone.marzona at jet-research.it (Marzona Simone) Date: Fri, 17 Mar 2006 12:12:32 +0100 Subject: Aiee, segfault! You should probably report this as a bug to the developer Message-ID: <441A99A0.6010709@jet-research.it> Hi all I run into this problem when I try to connecto to my pc104 (x86) system running xlinux (http://www.dmp.com.tw/tech/os-xlinux/) with 2.6.16.6 kernel (from kernel.org). I compiled dropbear 0.48.1 with these options on my desktop (debian testing): configure -disable-zlib make PROGRAMS="dropbear dbclient scp dropbearkey" STATIC=1 MULTI=1 After this, I transferred dropbearmulti and dropbearkeys on the pc104 system, I made the symlinks and I generated the rsa keys with : ./dropbearkey -t rsa -f dropbear_rsa_host_key then I run the dropbear server side program for testing with: ./dropbear -E -F -r /etc/dropbear/dropbear_rsa_host_key and when I try to connect to it from my desktop (debian testing) the server spits out: Aiee, segfault! You should probably report this as a bug to the developer many many times immediately after sending to the client the key information. Obviously I could not log in. This happens I use either /dev/random either /dev/urandom as random source. What I'm missing? Here is my options.h file: /* Dropbear SSH * Copyright (c) 2002,2003 Matt Johnston * All rights reserved. See LICENSE for the license. */ #ifndef _OPTIONS_H_ #define _OPTIONS_H_ /****************************************************************** * Define compile-time options below - the "#ifndef DROPBEAR_XXX .... #endif" * parts are to allow for commandline -DDROPBEAR_XXX options etc. ******************************************************************/ #ifndef DROPBEAR_DEFPORT #define DROPBEAR_DEFPORT "22" #endif /* Default hostkey paths - these can be specified on the command line */ #ifndef DSS_PRIV_FILENAME #define DSS_PRIV_FILENAME "/etc/dropbear/dropbear_dss_host_key" #endif #ifndef RSA_PRIV_FILENAME #define RSA_PRIV_FILENAME "/etc/dropbear/dropbear_rsa_host_key" #endif /* Set NON_INETD_MODE if you require daemon functionality (ie Dropbear listens * on chosen ports and keeps accepting connections. This is the default. * * Set INETD_MODE if you want to be able to run Dropbear with inetd (or * similar), where it will use stdin/stdout for connections, and each process * lasts for a single connection. Dropbear should be invoked with the -i flag * for inetd, and can only accept IPv4 connections. * * Both of these flags can be defined at once, don't compile without at least * one of them. */ #define NON_INETD_MODE #define INETD_MODE /* Setting this disables the fast exptmod bignum code. It saves ~5kB, but is * perhaps 20% slower for pubkey operations (it is probably worth experimenting * if you want to use this) */ /*#define NO_FAST_EXPTMOD*/ /* Set this if you want to use the DROPBEAR_SMALL_CODE option. This can save several kB in binary size, however will make the symmetrical ciphers (AES, DES etc) slower (perhaps by 50%). Recommended for most small systems. */ #define DROPBEAR_SMALL_CODE /* Enable X11 Forwarding - server only */ #define ENABLE_X11FWD /* Enable TCP Fowarding */ /* 'Local' is "-L" style (client listening port forwarded via server) * 'Remote' is "-R" style (server listening port forwarded via client) */ #define ENABLE_CLI_LOCALTCPFWD #define ENABLE_CLI_REMOTETCPFWD #define ENABLE_SVR_LOCALTCPFWD #define ENABLE_SVR_REMOTETCPFWD /* Enable Authentication Agent Forwarding - server only for now */ #define ENABLE_AGENTFWD /* Encryption - at least one required. * RFC Draft requires 3DES and recommends AES128 for interoperability. * Including multiple keysize variants the same cipher * (eg AES256 as well as AES128) will result in a minimal size increase.*/ #define DROPBEAR_AES128_CBC #define DROPBEAR_3DES_CBC #define DROPBEAR_AES256_CBC //#define DROPBEAR_BLOWFISH_CBC //#define DROPBEAR_TWOFISH256_CBC //#define DROPBEAR_TWOFISH128_CBC /* Message Integrity - at least one required. * RFC Draft requires sha1 and recommends sha1-96. * sha1-96 may be of use for slow links, as it has a smaller overhead. * * Note: there's no point disabling sha1 to save space, since it's used * for the random number generator and public-key cryptography anyway. * Disabling it here will just stop it from being used as the integrity portion * of the ssh protocol. * * These hashes are also used for public key fingerprints in logs. * If you disable MD5, Dropbear will fall back to SHA1 fingerprints, * which are not the standard form. */ #define DROPBEAR_SHA1_HMAC #define DROPBEAR_SHA1_96_HMAC #define DROPBEAR_MD5_HMAC /* Hostkey/public key algorithms - at least one required, these are used * for hostkey as well as for verifying signatures with pubkey auth. * Removing either of these won't save very much space. * SSH2 RFC Draft requires dss, recommends rsa */ #define DROPBEAR_RSA #define DROPBEAR_DSS /* RSA can be vulnerable to timing attacks which use the time required for * signing to guess the private key. Blinding avoids this attack, though makes * signing operations slightly slower. */ #define RSA_BLINDING /* Define DSS_PROTOK to use PuTTY's method of generating the value k for dss, * rather than just from the random byte source. Undefining this will save you * ~4k in binary size with static uclibc, but your DSS hostkey could be exposed * if the random number source isn't good. In general this isn't required */ /* #define DSS_PROTOK */ /* Whether to do reverse DNS lookups. */ //#define DO_HOST_LOOKUP /* Whether to print the message of the day (MOTD). This doesn't add much code * size */ //#define DO_MOTD /* The MOTD file path */ #ifndef MOTD_FILENAME #define MOTD_FILENAME "/etc/motd" #endif /* Authentication Types - at least one required. RFC Draft requires pubkey auth, and recommends password */ /* Note: PAM auth is quite simple, and only works for PAM modules which just do * a simple "Login: " "Password: " (you can edit the strings in svr-authpam.c). * It's useful for systems like OS X where standard password crypts don't work, * but there's an interface via a PAM module - don't bother using it otherwise. * You can't enable both PASSWORD and PAM. */ #define ENABLE_SVR_PASSWORD_AUTH /* #define ENABLE_SVR_PAM_AUTH */ /* requires ./configure --enable-pam */ #define ENABLE_SVR_PUBKEY_AUTH #define ENABLE_CLI_PASSWORD_AUTH #define ENABLE_CLI_PUBKEY_AUTH #define ENABLE_CLI_INTERACT_AUTH /* Define this (as well as ENABLE_CLI_PASSWORD_AUTH) to allow the use of * a helper program for the ssh client. The helper program should be * specified in the SSH_ASKPASS environment variable, and dbclient * should be run with DISPLAY set and no tty. The program should * return the password on standard output */ /*#define ENABLE_CLI_ASKPASS_HELPER*/ /* Random device to use - define either DROPBEAR_RANDOM_DEV or * DROPBEAR_PRNGD_SOCKET. * DROPBEAR_RANDOM_DEV is recommended on hosts with a good /dev/(u)random, * otherwise use run prngd (or egd if you want), specifying the socket. * The device will be queried for a few dozen bytes of seed a couple of times * per session (or more for very long-lived sessions). */ /* If you are lacking entropy on the system then using /dev/urandom * will prevent Dropbear from blocking on the device. This could * however significantly reduce the security of your ssh connections * if the PRNG state becomes guessable - make sure you know what you are * doing if you change this. */ #define DROPBEAR_RANDOM_DEV "/dev/random" /* prngd must be manually set up to produce output */ //#define DROPBEAR_PRNGD_SOCKET "/var/run/dropbear-rng" /* Specify the number of clients we will allow to be connected but * not yet authenticated. After this limit, connections are rejected */ /* The first setting is per-IP, to avoid denial of service */ #ifndef MAX_UNAUTH_PER_IP #define MAX_UNAUTH_PER_IP 5 #endif /* And then a global limit to avoid chewing memory if connections * come from many IPs */ #ifndef MAX_UNAUTH_CLIENTS #define MAX_UNAUTH_CLIENTS 30 #endif /* Maximum number of failed authentication tries (server option) */ #ifndef MAX_AUTH_TRIES #define MAX_AUTH_TRIES 10 #endif /* The file to store the daemon's process ID, for shutdown scripts etc */ #ifndef DROPBEAR_PIDFILE #define DROPBEAR_PIDFILE "/var/run/dropbear.pid" #endif /* The command to invoke for xauth when using X11 forwarding. * "-q" for quiet */ #ifndef XAUTH_COMMAND #define XAUTH_COMMAND "/usr/X11R6/bin/xauth -q" #endif /* if you want to enable running an sftp server (such as the one included with * OpenSSH), set the path below. If the path isn't defined, sftp will not * be enabled */ #ifndef SFTPSERVER_PATH #define SFTPSERVER_PATH "/usr/libexec/sftp-server" #endif /* This is used by the scp binary when used as a client binary. If you're * not using the Dropbear client, you'll need to change it */ #define _PATH_SSH_PROGRAM "/usr/bin/dbclient" /* Multi-purpose binary configuration has now moved. Look at the top * of the Makefile for instructions, or INSTALL */ /******************************************************************* * You shouldn't edit below here unless you know you need to. *******************************************************************/ #ifndef DROPBEAR_VERSION #define DROPBEAR_VERSION "0.48" #endif #define LOCAL_IDENT "SSH-2.0-dropbear_" DROPBEAR_VERSION #define PROGNAME "dropbear" /* Spec recommends after one hour or 1 gigabyte of data. One hour * is a bit too verbose, so we try 8 hours */ #ifndef KEX_REKEY_TIMEOUT #define KEX_REKEY_TIMEOUT (3600 * 8) #endif #ifndef KEX_REKEY_DATA #define KEX_REKEY_DATA (1<<30) /* 2^30 == 1GB, this value must be < INT_MAX */ #endif /* Close connections to clients which haven't authorised after AUTH_TIMEOUT */ #ifndef AUTH_TIMEOUT #define AUTH_TIMEOUT 300 /* we choose 5 minutes */ #endif /* Minimum key sizes for DSS and RSA */ #ifndef MIN_DSS_KEYLEN #define MIN_DSS_KEYLEN 512 #endif #ifndef MIN_RSA_KEYLEN #define MIN_RSA_KEYLEN 512 #endif #define MAX_BANNER_SIZE 2000 /* this is 25*80 chars, any more is foolish */ #define MAX_BANNER_LINES 20 /* How many lines the client will display */ /* the number of NAME=VALUE pairs to malloc for environ, if we don't have * the clearenv() function */ #define ENV_SIZE 100 #define MAX_CMD_LEN 1024 /* max length of a command */ #define MAX_TERM_LEN 200 /* max length of TERM name */ #define MAX_HOST_LEN 254 /* max hostname len for tcp fwding */ #define MAX_IP_LEN 15 /* strlen("255.255.255.255") == 15 */ #define DROPBEAR_MAX_PORTS 10 /* max number of ports which can be specified, ipv4 and ipv6 don't count twice */ #define _PATH_TTY "/dev/tty" #define _PATH_CP "/bin/cp" /* Timeouts in seconds */ #define SELECT_TIMEOUT 20 /* success/failure defines */ #define DROPBEAR_SUCCESS 0 #define DROPBEAR_FAILURE -1 /* various algorithm identifiers */ #define DROPBEAR_KEX_DH_GROUP1 0 #define DROPBEAR_SIGNKEY_ANY 0 #define DROPBEAR_SIGNKEY_RSA 1 #define DROPBEAR_SIGNKEY_DSS 2 #define DROPBEAR_SIGNKEY_NONE 3 #define DROPBEAR_COMP_NONE 0 #define DROPBEAR_COMP_ZLIB 1 /* Required for pubkey auth */ #if defined(ENABLE_SVR_PUBKEY_AUTH) || defined(DROPBEAR_CLIENT) #define DROPBEAR_SIGNKEY_VERIFY #endif /* SHA1 is 20 bytes == 160 bits */ #define SHA1_HASH_SIZE 20 /* SHA512 is 64 bytes == 512 bits */ #define SHA512_HASH_SIZE 64 /* MD5 is 16 bytes = 128 bits */ #define MD5_HASH_SIZE 16 /* largest of MD5 and SHA1 */ #define MAX_MAC_LEN SHA1_HASH_SIZE #define MAX_KEY_LEN 32 /* 256 bits for aes256 etc */ #define MAX_IV_LEN 20 /* must be same as max blocksize, and >= SHA1_HASH_SIZE */ #define MAX_MAC_KEY 20 #define MAX_NAME_LEN 64 /* maximum length of a protocol name, isn't explicitly specified for all protocols (just for algos) but seems valid */ #define MAX_PROPOSED_ALGO 20 /* size/count limits */ #define MAX_LISTEN_ADDR 10 #define MAX_PACKET_LEN 35000 #define MIN_PACKET_LEN 16 #define MAX_PAYLOAD_LEN 32768 #define MAX_TRANS_PAYLOAD_LEN 32768 #define MAX_TRANS_PACKET_LEN (MAX_TRANS_PAYLOAD_LEN+50) #define MAX_TRANS_WINDOW 500000000 /* 500MB is sufficient, stopping overflow */ #define MAX_TRANS_WIN_INCR 500000000 /* overflow prevention */ #define MAX_STRING_LEN 1400 /* ~= MAX_PROPOSED_ALGO * MAX_NAME_LEN, also is the max length for a password etc */ /* For a 4096 bit DSS key, empirically determined */ #define MAX_PUBKEY_SIZE 1700 /* For a 4096 bit DSS key, empirically determined */ #define MAX_PRIVKEY_SIZE 1700 /* The maximum size of the bignum portion of the kexhash buffer */ /* Sect. 8 of the transport draft, K_S + e + f + K */ #define KEXHASHBUF_MAX_INTS (1700 + 130 + 130 + 130) #define DROPBEAR_MAX_SOCKS 2 /* IPv4, IPv6 are all we'll get for now. Revisit in a few years time.... */ #define DROPBEAR_MAX_CLI_PASS 1024 #define DROPBEAR_MAX_CLI_INTERACT_PROMPTS 80 /* The number of prompts we'll accept for keyb-interactive auth */ #if defined(DROPBEAR_AES256_CBC) || defined(DROPBEAR_AES128_CBC) #define DROPBEAR_AES_CBC #endif #if defined(DROPBEAR_TWOFISH256_CBC) || defined(DROPBEAR_TWOFISH128_CBC) #define DROPBEAR_TWOFISH_CBC #endif #ifndef ENABLE_X11FWD #define DISABLE_X11FWD #endif #ifndef ENABLE_AGENTFWD #define DISABLE_AGENTFWD Many thanks in advance -- Dott Simone Marzona -------------------------------------------------------------------------------------------- Il contenuto e gli allegati di questo messaggio sono strettamente confidenziali, e ne sono vietati la diffusione e l'uso non autorizzato. Il presente messaggio di posta elettronica e gli eventuali relativi allegati non costituiscono impegno contrattuale o precontrattuale tra l'Azienda ed il destinatario, salva la conferma di essi con altro mezzo legalmente idoneo. L'azienda non assume inoltre alcuna responsabilit? per eventuali intercettazioni, modifiche o danneggiamenti. Qualora il presente messaggio Le fosse pervenuto per errore, Le saremmo grati se lo distruggesse e ce ne comunicasse, via e-mail, l'errata ricezione all'indirizzo mailerror at jet-research.it. Grazie. From matt at ucc.asn.au Sun Mar 19 20:50:08 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sun, 19 Mar 2006 20:50:08 +0800 Subject: Aiee, segfault! You should probably report this as a bug to the developer In-Reply-To: <441A99A0.6010709@jet-research.it> References: <441A99A0.6010709@jet-research.it> Message-ID: <20060319125008.GS32089@ucc.gu.uwa.edu.au> On Fri, Mar 17, 2006 at 12:12:32PM +0100, Marzona Simone wrote: > Hi all > > I run into this problem when I try to connecto to my pc104 (x86) system > running xlinux (http://www.dmp.com.tw/tech/os-xlinux/) with 2.6.16.6 > kernel (from kernel.org). > ./dropbear -E -F -r /etc/dropbear/dropbear_rsa_host_key > > and when I try to connect to it from my desktop (debian testing) the > server spits out: > > Aiee, segfault! You should probably report this as a bug to the developer > > many many times immediately after sending to the client the key > information. Obviously I could not log in. I can't think of anything obviously wrong with that setup. Is it possible to run gdb on the pc104 system to find out where the segfault is occurring (let me know if you need a hand)? If not, you could try compiling Dropbear with DEBUG_TRACE enabled in debug.h and running dropbear with -v, that should spit out some extra output about which function it's crashing in. It might be worth trying with DSS keys instead of RSA keys to help narrow it down. Cheers, Matt From simone.marzona at jet-research.it Thu Mar 23 23:25:42 2006 From: simone.marzona at jet-research.it (Marzona Simone) Date: Thu, 23 Mar 2006 16:25:42 +0100 Subject: Aiee, segfault! You should probably report this as a bug to the developer Message-ID: <4422BDF6.9000705@jet-research.it> Hi all I found where was the problem. In my kernel setup I was missing some features like SYSVIPC and SYSCTL. Corrected this it seems ok. thank you all. -- Dott Simone Marzona -------------------------------------------------------------------------------------------- Il contenuto e gli allegati di questo messaggio sono strettamente confidenziali, e ne sono vietati la diffusione e l'uso non autorizzato. Il presente messaggio di posta elettronica e gli eventuali relativi allegati non costituiscono impegno contrattuale o precontrattuale tra l'Azienda ed il destinatario, salva la conferma di essi con altro mezzo legalmente idoneo. L'azienda non assume inoltre alcuna responsabilit? per eventuali intercettazioni, modifiche o danneggiamenti. Qualora il presente messaggio Le fosse pervenuto per errore, Le saremmo grati se lo distruggesse e ce ne comunicasse, via e-mail, l'errata ricezione all'indirizzo mailerror at jet-research.it. Grazie. From ndprasad at gmail.com Fri Mar 24 06:06:20 2006 From: ndprasad at gmail.com (DeviPrasad Natesan) Date: Thu, 23 Mar 2006 14:06:20 -0800 Subject: Read-only root-filesystem Message-ID: <3351bfbe0603231406g20fc0626j8e190c77a8f29119@mail.gmail.com> Hi all, Does the dropbear-ssh needs writable root-filesystem to run correctly. I set my file-system as read-only (which i ultimately wants to) and it fails giving the following error. ==================== TRACE: continue recv_msg_channel_request: session request TRACE: enter chansessionrequest TRACE: type is shell TRACE: enter sessioncommand TRACE: enter ptycommand [147] Mar 23 04:51:57 no pty was allocated, couldn't execute ======================== It works ok when i change the root-filesystem as the read-write. Apparently due to the /dev/pty* ?. I am running the default dropbear found in the uClinux-dist distribution with my microblaze as the processor. Please let me know how i can run the dropbear with the read-only root file system. Appreciate your reply. Thnx - Prasad From ndprasad at gmail.com Fri Mar 24 08:14:19 2006 From: ndprasad at gmail.com (DeviPrasad Natesan) Date: Thu, 23 Mar 2006 16:14:19 -0800 Subject: Read-only root-filesystem In-Reply-To: <3351bfbe0603231406g20fc0626j8e190c77a8f29119@mail.gmail.com> References: <3351bfbe0603231406g20fc0626j8e190c77a8f29119@mail.gmail.com> Message-ID: <3351bfbe0603231614r2ba1d199jb68a286b4f653af1@mail.gmail.com> Hi, This was solved when i added "--disable-openpty" in the configuration. Thanx - Prasad On 3/23/06, DeviPrasad Natesan wrote: > Hi all, > Does the dropbear-ssh needs writable root-filesystem to run correctly. > I set my file-system as read-only (which i ultimately wants to) and it > fails giving the following error. > > ==================== > TRACE: continue recv_msg_channel_request: session request > TRACE: enter chansessionrequest > TRACE: type is shell > TRACE: enter sessioncommand > TRACE: enter ptycommand > [147] Mar 23 04:51:57 no pty was allocated, couldn't execute > ======================== > > It works ok when i change the root-filesystem as the read-write. > Apparently due to the /dev/pty* ?. > > I am running the default dropbear found in the uClinux-dist > distribution with my microblaze as the processor. Please let me know > how i can run the dropbear with the read-only root file system. > > Appreciate your reply. > > Thnx > - Prasad > From yan at seiner.com Fri Mar 24 21:15:12 2006 From: yan at seiner.com (Yan Seiner) Date: Fri, 24 Mar 2006 05:15:12 -0800 Subject: Read-only root-filesystem Message-ID: <4423F0E0.3000200@seiner.com> Message: 3 Date: Thu, 23 Mar 2006 16:14:19 -0800 From: "DeviPrasad Natesan" Subject: Re: Read-only root-filesystem To: dropbear at ucc.asn.au Message-ID: <3351bfbe0603231614r2ba1d199jb68a286b4f653af1 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi, This was solved when i added "--disable-openpty" in the configuration. ---------------------------------- You can also use devfs (if you have kernel 2.4) or tmpfs to create /dev. Create the necessary devices in your init scripts. --Yan From rob at landley.net Sat Mar 25 11:09:30 2006 From: rob at landley.net (Rob Landley) Date: Fri, 24 Mar 2006 22:09:30 -0500 Subject: Is this a bug? Message-ID: <200603242209.30305.rob@landley.net> 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? Rob -- Never bet against the cheap plastic solution. From matt at ucc.asn.au Sun Mar 26 23:16:10 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sun, 26 Mar 2006 23:16:10 +0800 Subject: Is this a bug? In-Reply-To: <200603242209.30305.rob@landley.net> References: <200603242209.30305.rob@landley.net> Message-ID: <20060326151609.GI8047@ucc.gu.uwa.edu.au> 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 From stepan at coresystems.de Mon Mar 27 13:01:24 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 27 Mar 2006 07:01:24 +0200 Subject: no shell after login Message-ID: <20060327050124.GA9191@openbios.org> Hi, I've recently found a precompiled version of dropbear on the net (0.43) which worked fine on my mips32 based netgear wgt634u. To make sure I am up to date with security and features, I downloaded the 0.48.1 source and compiled it using the linksys cross gcc for mipsel-uclibc. When I ssh to the system now, I don't get a shell anymore (default was ash) but when I press return the connection drops again. ssh root at a.b.c.d /bin/some-command works fine though. This sounds similar to the following issue I found in the list archive: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2005q4/000309.html Which I think remained unresolved. Any ideas? Anything I can do to debug this further? An ssh -v reveils the following: OpenSSH_4.1p1, OpenSSL 0.9.7g 11 Apr 2005 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to wgt634u [192.168.0.253] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/identity type -1 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version dropbear_0.48.1 debug1: no match: dropbear_0.48.1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug1: Host 'wgt634u' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:4 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/identity debug1: Trying private key: /root/.ssh/id_rsa debug1: Trying private key: /root/.ssh/id_dsa debug1: Next authentication method: password root at wgt634u's password: debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = debug1: channel 0: free: client-session, nchannels 1 debug1: fd 1 clearing O_NONBLOCK Connection to wgt634u closed by remote host. Connection to wgt634u closed. debug1: Transferred: stdin 0, stdout 0, stderr 77 bytes in 4.0 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 19.4 debug1: Exit status -1 Thanks in advance, Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Mon Mar 27 13:13:23 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 27 Mar 2006 07:13:23 +0200 Subject: no shell after login In-Reply-To: <20060327050124.GA9191@openbios.org> References: <20060327050124.GA9191@openbios.org> Message-ID: <20060327051323.GA10153@openbios.org> * Stefan Reinauer [060327 07:01]: > An ssh -v reveils the following: The last few lines with -vvv: debug2: channel 0: request shell confirm 0 debug2: fd 4 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 8000 rmax 8000 debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 5/6 cfd -1) debug3: channel 0: close_fds r 5 w 6 e 7 c -1 Connection to 192.168.0.253 closed by remote host. Connection to 192.168.0.253 closed. debug1: Transferred: stdin 0, stdout 0, stderr 89 bytes in 1.0 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 89.3 debug1: Exit status -1 > OpenSSH_4.1p1, OpenSSL 0.9.7g 11 Apr 2005 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug1: Connecting to wgt634u [192.168.0.253] port 22. > debug1: Connection established. > debug1: permanently_set_uid: 0/0 > debug1: identity file /root/.ssh/identity type -1 > debug1: identity file /root/.ssh/id_rsa type -1 > debug1: identity file /root/.ssh/id_dsa type -1 > debug1: Remote protocol version 2.0, remote software version dropbear_0.48.1 > debug1: no match: dropbear_0.48.1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_4.1 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: server->client aes128-cbc hmac-md5 none > debug1: kex: client->server aes128-cbc hmac-md5 none > debug1: sending SSH2_MSG_KEXDH_INIT > debug1: expecting SSH2_MSG_KEXDH_REPLY > debug1: Host 'wgt634u' is known and matches the RSA host key. > debug1: Found key in /root/.ssh/known_hosts:4 > debug1: ssh_rsa_verify: signature correct > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug1: SSH2_MSG_NEWKEYS received > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug1: Authentications that can continue: publickey,password > debug1: Next authentication method: publickey > debug1: Trying private key: /root/.ssh/identity > debug1: Trying private key: /root/.ssh/id_rsa > debug1: Trying private key: /root/.ssh/id_dsa > debug1: Next authentication method: password > root at wgt634u's password: > debug1: Authentication succeeded (password). > debug1: channel 0: new [client-session] > debug1: Entering interactive session. > debug1: Sending environment. > debug1: Sending env LANG = > > debug1: channel 0: free: client-session, nchannels 1 > debug1: fd 1 clearing O_NONBLOCK > Connection to wgt634u closed by remote host. > Connection to wgt634u closed. > debug1: Transferred: stdin 0, stdout 0, stderr 77 bytes in 4.0 seconds > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 19.4 > debug1: Exit status -1 > > Thanks in advance, > Stefan > -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Mon Mar 27 23:38:05 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 27 Mar 2006 17:38:05 +0200 Subject: no shell after login In-Reply-To: <20060327051323.GA10153@openbios.org> References: <20060327050124.GA9191@openbios.org> <20060327051323.GA10153@openbios.org> Message-ID: <20060327153805.GA5088@openbios.org> Hi, d'uh. couldn't find any errors in the logs, but running it with error reporting to stderr unveiled the problem: [26079] Mar 27 23:32:05 pty_allocate: openpty: No such file or directory [26079] Mar 27 23:32:05 no pty was allocated, couldn't execute so.. configure with --disable-openpty helped and it works perfectly now. Just in case someone else runs into this again. Best regards, Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From srowe at cambridgebroadband.com Thu Mar 30 21:59:14 2006 From: srowe at cambridgebroadband.com (Simon Rowe) Date: Thu, 30 Mar 2006 14:59:14 +0100 Subject: Patch to fix compilation of 0.48.1 Message-ID: <200603301459.15269.srowe@cambridgebroadband.com> dropbear 0.48.1 will not compile with gcc 2.96, there are a number of places where variables as declared after function code. The attached patch fixes those we've encountered. --- third-party/dropbear/cli-auth.c 29 Mar 2006 12:57:19 -0000 1.1.1.3 +++ third-party/dropbear/cli-auth.c 30 Mar 2006 13:44:16 -0000 1.1.1.3.2.2 @@ -236,9 +236,9 @@ void cli_auth_try() { - TRACE(("enter cli_auth_try")) int finished = 0; + TRACE(("enter cli_auth_try")) CHECKCLEARTOWRITE(); --- third-party/dropbear/cli-chansession.c 29 Mar 2006 12:57:19 -0000 1.1.1.3 +++ third-party/dropbear/cli-chansession.c 30 Mar 2006 13:45:30 -0000 1.1.1.3.2.2 @@ -162,7 +162,6 @@ static void put_termcodes() { - TRACE(("enter put_termcodes")) struct termios tio; unsigned int sshcode; @@ -171,7 +170,8 @@ unsigned int mapcode; unsigned int bufpos1, bufpos2; + TRACE(("enter put_termcodes")) if (tcgetattr(STDIN_FILENO, &tio) == -1) { dropbear_log(LOG_WARNING, "Failed reading termmodes"); --- third-party/dropbear/random.c 29 Mar 2006 12:57:19 -0000 1.1.1.4 +++ third-party/dropbear/random.c 29 Mar 2006 14:03:31 -0000 1.1.1.1.24.2 @@ -158,6 +158,8 @@ pid_t pid; struct timeval tv; + hash_state hs; + unsigned char hash[SHA1_HASH_SIZE]; if (!donerandinit) { dropbear_exit("seedrandom not done"); @@ -166,8 +168,6 @@ pid = getpid(); gettimeofday(&tv, NULL); - hash_state hs; - unsigned char hash[SHA1_HASH_SIZE]; sha1_init(&hs); sha1_process(&hs, (void*)hashpool, sizeof(hashpool)); sha1_process(&hs, (void*)&pid, sizeof(pid)); From matt at ucc.asn.au Thu Mar 30 23:12:12 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 30 Mar 2006 23:12:12 +0800 Subject: Patch to fix compilation of 0.48.1 In-Reply-To: <200603301459.15269.srowe@cambridgebroadband.com> References: <200603301459.15269.srowe@cambridgebroadband.com> Message-ID: <20060330151211.GR8088@ucc.gu.uwa.edu.au> On Thu, Mar 30, 2006 at 02:59:14PM +0100, Simon Rowe wrote: > dropbear 0.48.1 will not compile with gcc 2.96, there are a number of places > where variables as declared after function code. The attached patch fixes > those we've encountered. Yeah, I came across these myself in the past week, I'll make sure they're fixed for the next release (and I'll be sure to test that it compiles with DEBUG_TRACE on). Thanks, Matt