From idl0r at qasl.de Thu Jul 1 23:52:14 2010 From: idl0r at qasl.de (Christian Ruppert) Date: Thu, 01 Jul 2010 17:52:14 +0200 Subject: exit after auth In-Reply-To: <4C268D2A.4050402@qasl.de> References: <4C26196A.3030503@qasl.de> <201006261649.23455.rob@landley.net> <4C268D2A.4050402@qasl.de> Message-ID: <4C2CB9AE.5010106@qasl.de> Or can somebody show me a working example with an initramfs? Just a minimal initramfs with busybox and dropbear.. nothing more. I can't figure out why it doesn't work :( -- Regards, Christian Ruppert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20100701/b042b602/attachment.pgp From rob at landley.net Fri Jul 2 06:54:04 2010 From: rob at landley.net (Rob Landley) Date: Thu, 1 Jul 2010 17:54:04 -0500 Subject: exit after auth In-Reply-To: <4C2CB9AE.5010106@qasl.de> References: <4C26196A.3030503@qasl.de> <4C268D2A.4050402@qasl.de> <4C2CB9AE.5010106@qasl.de> Message-ID: <201007011754.05108.rob@landley.net> On Thursday 01 July 2010 10:52:14 Christian Ruppert wrote: > Or can somebody show me a working example with an initramfs? > Just a minimal initramfs with busybox and dropbear.. nothing more. > > I can't figure out why it doesn't work :( I can whip one up, sure. Which target would you like? (x86? x86-64? arm? mips? powerpc? sparc?) Rob -- GPLv3: as worthy a successor as The Phantom Meanace, as timely as Duke Nukem Forever, and as welcome as New Coke. From idl0r at qasl.de Fri Jul 2 12:52:43 2010 From: idl0r at qasl.de (Christian Ruppert) Date: Fri, 02 Jul 2010 06:52:43 +0200 Subject: exit after auth In-Reply-To: <201007011754.05108.rob@landley.net> References: <4C26196A.3030503@qasl.de> <4C268D2A.4050402@qasl.de> <4C2CB9AE.5010106@qasl.de> <201007011754.05108.rob@landley.net> Message-ID: <4C2D709B.3050607@qasl.de> On 07/02/2010 12:54 AM, Rob Landley wrote: > On Thursday 01 July 2010 10:52:14 Christian Ruppert wrote: >> Or can somebody show me a working example with an initramfs? >> Just a minimal initramfs with busybox and dropbear.. nothing more. >> >> I can't figure out why it doesn't work :( > > I can whip one up, sure. Which target would you like? (x86? x86-64? arm? > mips? powerpc? sparc?) > > Rob x86-64 would be good :) -- Regards, Christian Ruppert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20100702/7a91237b/attachment.pgp From johan at dicam.org.uk Tue Jul 6 21:30:02 2010 From: johan at dicam.org.uk (Johan Ribenfors) Date: Tue, 06 Jul 2010 14:30:02 +0100 Subject: Detect dropped connections Message-ID: Hi, We have upwards of 70 embedded pcs running linux, and are trying to use dropbear to set up ssh tunnels to our server. This is so we don't have to worry about dynamic ips, router configuration, mesh networks or any other of the strange setups we've encountered. The command we are using is: dbclient -R :localhost: -I 60 -K 30 -g -T -N -f -i @ If I've got the arguments correct, the -I should cause dbclient to exit if it doesn't recieve any keep alive packets from the server within 60 seconds. The -K should cause dbclient to send a packet every 30 seconds to prevent routers etc from closing the connection. Generally, this seems to work. However, we occasionally get a situation where the server has stopped listening on the relevant port, and dbclient hasn't detected this and exited. Have I missunderstood the arguments, or missed a setting? This is Dropbear client v0.52 Thanks in advance. - Johan From dan at emutex.com Wed Jul 7 17:42:11 2010 From: dan at emutex.com (Dan O'Donovan) Date: Wed, 7 Jul 2010 10:42:11 +0100 Subject: Detect dropped connections In-Reply-To: References: Message-ID: <002101cb1db8$b1a8d190$14fa74b0$@emutex.com> Hi Johan We are using dropbear in a similar way to yourself. You're correct that the -K option should prevent the server and the routers in between from closing the connection. I tried using the -I option in the same way that you did but it didn't work for me. I suspect that the keep-alives sent with the -K actually prevent the link from ever appearing as "idle", although I'm not entirely sure. We decided to use 'autossh' to launch 'dbclient' and monitor the connection by sending its own link test messages. See: http://www.harding.motd.ca/autossh/ That works well for us. However, we still had one issue. If dbclient failed to set up the reverse tcp forward, it wouldn't exit with an error so autossh would never know. So I made the following minor code change (perhaps this could be considered for a future release of dropbear?): --- dropbear-0.52_orig/cli-tcpfwd.c 2008-11-11 14:09:02.000000000 +0000 +++ dropbear-0.52_new/cli-tcpfwd.c 2010-06-30 16:05:17.000000000 +0000 @@ -172,8 +172,16 @@ if (!iter->have_reply) { iter->have_reply = 1; - dropbear_log(LOG_WARNING, "Remote TCP forward request failed (port %d -> %s:%d)", iter->listenport, iter->connectaddr, iter->connectport); - return; + + if (cli_opts.no_cmd) + { + dropbear_exit("Remote TCP forward request failed (port %d -> %s:%d)", iter->listenport, iter->connectaddr, iter->connectport); + } + else + { + dropbear_log(LOG_WARNING, "Remote TCP forward request failed (port %d -> %s:%d)", iter->listenport, iter->connectaddr, iter->connectport); + return; + } } iter = iter->next; } We run dbclient with the -N option, so I tied the above behaviour to that. dbclient will exit if the -N option is set and a remote tcp forward request fails. Subsequently, autossh will restart dbclient again. This does the trick for us. Hope this helps. Best regards, -Dan -----Original Message----- From: dropbear-bounces at ucc.asn.au [mailto:dropbear-bounces at ucc.asn.au] On Behalf Of Johan Ribenfors Sent: 06 July 2010 14:30 To: dropbear at ucc.asn.au Subject: Detect dropped connections Hi, We have upwards of 70 embedded pcs running linux, and are trying to use dropbear to set up ssh tunnels to our server. This is so we don't have to worry about dynamic ips, router configuration, mesh networks or any other of the strange setups we've encountered. The command we are using is: dbclient -R :localhost: -I 60 -K 30 -g -T -N -f -i @ If I've got the arguments correct, the -I should cause dbclient to exit if it doesn't recieve any keep alive packets from the server within 60 seconds. The -K should cause dbclient to send a packet every 30 seconds to prevent routers etc from closing the connection. Generally, this seems to work. However, we occasionally get a situation where the server has stopped listening on the relevant port, and dbclient hasn't detected this and exited. Have I missunderstood the arguments, or missed a setting? This is Dropbear client v0.52 Thanks in advance. - Johan From rob at landley.net Mon Jul 12 14:00:58 2010 From: rob at landley.net (Rob Landley) Date: Mon, 12 Jul 2010 01:00:58 -0500 Subject: exit after auth In-Reply-To: <4C2D709B.3050607@qasl.de> References: <4C26196A.3030503@qasl.de> <201007011754.05108.rob@landley.net> <4C2D709B.3050607@qasl.de> Message-ID: <201007120101.00581.rob@landley.net> On Thursday 01 July 2010 23:52:43 Christian Ruppert wrote: > On 07/02/2010 12:54 AM, Rob Landley wrote: > > On Thursday 01 July 2010 10:52:14 Christian Ruppert wrote: > >> Or can somebody show me a working example with an initramfs? > >> Just a minimal initramfs with busybox and dropbear.. nothing more. > >> > >> I can't figure out why it doesn't work :( > > > > I can whip one up, sure. Which target would you like? (x86? x86-64? > > arm? mips? powerpc? sparc?) > > > > Rob > > x86-64 would be good :) Sorry, got distracted. :) Grab http://landley.net/system-image-x86_64.tar.bz2 and give that a try. It should boot under qemu with the included run-emulator.sh. Rob -- GPLv3: as worthy a successor as The Phantom Meanace, as timely as Duke Nukem Forever, and as welcome as New Coke. From johan at dicam.org.uk Wed Jul 21 21:47:10 2010 From: johan at dicam.org.uk (Johan Ribenfors) Date: Wed, 21 Jul 2010 13:47:10 +0000 (UTC) Subject: Detect dropped connections References: Message-ID: Johan Ribenfors dicam.org.uk> writes: > > Hi, > > We have upwards of 70 embedded pcs running linux, and are trying to use > dropbear to set up ssh tunnels to our server. > > This is so we don't have to worry about dynamic ips, router configuration, > mesh networks or any other of the strange setups we've encountered. > > The command we are using is: > > dbclient -R :localhost: -I 60 -K 30 -g -T -N -f -i > @ > > If I've got the arguments correct, the -I should cause dbclient to exit if > it doesn't recieve any keep alive packets from the server within 60 > seconds. > > The -K should cause dbclient to send a packet every 30 seconds to prevent > routers etc from closing the connection. > > Generally, this seems to work. However, we occasionally get a situation > where the server has stopped listening on the relevant port, and dbclient > hasn't detected this and exited. > > Have I missunderstood the arguments, or missed a setting? > > This is Dropbear client v0.52 > > Thanks in advance. > > - Johan > > Hi, I thought it was time I posted our solution. Farrell Aultman suggested a patch by Ahilan (http://comments.gmane.org/ gmane.network.ssh.dropbear/936) This compiled and ran fine - but didn't solve the problem. The server (OpenSSH) would still drop the occasional connection and dropbear wouldn't notice. I might be using it incorrectly, (I hope I am) but don't think so. Just to make it difficult, when testing dropping the connection on the server - with -A or -I - dropbear _always_ notices. We ended up with a workaround, rather than a proper solution. The server knows what connections should be open, and maintains a list of the ones that aren't. Each site (embeded pc) has a cronjob that runs every minute and queries the server for the currently _inactive_ connections. It then restarts those connections locally. Worst case, a tunnel is down for a minute. I have a feeling someone else has posted this approach in the mailing lists already. It felt clunky when I read it then, and feels clunky now. But much as I'd like a proper solution, this one works. - Johan From matt at ucc.asn.au Wed Jul 21 22:52:12 2010 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 21 Jul 2010 22:52:12 +0800 Subject: Detect dropped connections In-Reply-To: <002101cb1db8$b1a8d190$14fa74b0$@emutex.com> References: <002101cb1db8$b1a8d190$14fa74b0$@emutex.com> Message-ID: <20100721145212.GL6819@ucc.gu.uwa.edu.au> Hi, Apologies to everyone for the long delay in replying. On Wed, Jul 07, 2010 at 10:42:11AM +0100, Dan O'Donovan wrote: > You're correct that the -K option should prevent the server and the routers > in between from closing the connection. > I tried using the -I option in the same way that you did but it didn't work > for me. I suspect that the keep-alives sent with the -K actually prevent > the link from ever appearing as "idle", although I'm not entirely sure. This does seem to be the case - I'll look at fixing it. > > We decided to use 'autossh' to launch 'dbclient' and monitor the connection > by sending its own link test messages. See: > http://www.harding.motd.ca/autossh/ > That works well for us. However, we still had one issue. If dbclient > failed to set up the reverse tcp forward, it wouldn't exit with an error so > autossh would never know. > So I made the following minor code change (perhaps this could be considered > for a future release of dropbear?): This looks sensible (exiting if a -R forward fails when -N is specified). I wonder if anyone would have problems if they're using -N and multiple -L/-R options and don't mind of only some of them fail - maybe it should be a separate commandline flag. Cheers, Matt From matt at ucc.asn.au Wed Jul 21 22:55:23 2010 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 21 Jul 2010 22:55:23 +0800 Subject: Detect dropped connections In-Reply-To: References: Message-ID: <20100721145523.GM6819@ucc.gu.uwa.edu.au> On Wed, Jul 21, 2010 at 01:47:10PM +0000, Johan Ribenfors wrote: > This compiled and ran fine - but didn't solve the problem. The server > (OpenSSH) would still drop the occasional connection and dropbear wouldn't > notice. I might be using it incorrectly, (I hope I am) but don't think so. > Just to make it difficult, when testing dropping the connection on the server - > with -A or -I - dropbear _always_ notices. Have you set any ClientAliveInterval or TCPKeepAlive options on the server? I wonder if the server sometimes might not have noticed that the client connection has gone away so will keep the listening port in use, so even reconnecting won't help as it won't be able to bind to that port. I may be misunderstanding some of the problem though. Cheers, Matt From johan at dicam.org.uk Wed Jul 21 23:33:31 2010 From: johan at dicam.org.uk (Johan Ribenfors) Date: Wed, 21 Jul 2010 15:33:31 +0000 (UTC) Subject: Detect dropped connections References: <20100721145523.GM6819@ucc.gu.uwa.edu.au> Message-ID: Matt Johnston ucc.asn.au> writes: > > On Wed, Jul 21, 2010 at 01:47:10PM +0000, Johan Ribenfors wrote: > > This compiled and ran fine - but didn't solve the problem. The server > > (OpenSSH) would still drop the occasional connection and dropbear wouldn't > > notice. I might be using it incorrectly, (I hope I am) but don't think so. > > Just to make it difficult, when testing dropping the connection on the server - > > with -A or -I - dropbear _always_ notices. > > Have you set any ClientAliveInterval or TCPKeepAlive options > on the server? I wonder if the server sometimes might not > have noticed that the client connection has gone away so > will keep the listening port in use, so even reconnecting > won't help as it won't be able to bind to that port. I may > be misunderstanding some of the problem though. > > Cheers, > Matt > > Matt, They are both set: KeepAlive yes ClientAliveInterval 60 You have the problem backwards though - the server connection has gone away, and the client hasn't noticed. - Johan From johan at dicam.org.uk Thu Jul 22 22:46:38 2010 From: johan at dicam.org.uk (Johan Ribenfors) Date: Thu, 22 Jul 2010 14:46:38 +0000 (UTC) Subject: Detect dropped connections References: <002101cb1db8$b1a8d190$14fa74b0$@emutex.com> <20100721145212.GL6819@ucc.gu.uwa.edu.au> Message-ID: Matt Johnston ucc.asn.au> writes: > > This looks sensible (exiting if a -R forward fails when -N > is specified). I wonder if anyone would have problems if > they're using -N and multiple -L/-R options and don't mind > of only some of them fail - maybe it should be a separate > commandline flag. > > Cheers, > Matt > > In the interests of learning more, under what circumstances would you _not_ want dropbear to exit when it couldn't make the connection? - Johan From matt at ucc.asn.au Thu Jul 22 22:56:42 2010 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 22 Jul 2010 22:56:42 +0800 Subject: Detect dropped connections In-Reply-To: References: <002101cb1db8$b1a8d190$14fa74b0$@emutex.com> <20100721145212.GL6819@ucc.gu.uwa.edu.au> Message-ID: <20100722145642.GT6819@ucc.gu.uwa.edu.au> On Thu, Jul 22, 2010 at 02:46:38PM +0000, Johan Ribenfors wrote: > Matt Johnston ucc.asn.au> writes: > > > This looks sensible (exiting if a -R forward fails when -N > > is specified). I wonder if anyone would have problems if > > they're using -N and multiple -L/-R options and don't mind > > of only some of them fail - maybe it should be a separate > > commandline flag. > > In the interests of learning more, under what circumstances would you _not_ want > dropbear to exit when it couldn't make the connection? The kind of situation I had in mind is where you have a set of say 5 ports you want forwarded but one of the ports is already bound on the server (perhaps you've forwarded that separately?). I guess in automated circumstances with -N that isn't very common. It's more of an issue if you have some standard "LocalForward" per-host entries in a ~/.ssh/config for OpenSSH client, but don't care much if they don't always work. Cheers, Matt From mbus25 at hotmail.com Sat Jul 24 06:53:49 2010 From: mbus25 at hotmail.com (mbus25 .) Date: Fri, 23 Jul 2010 22:53:49 +0000 Subject: How to redirect the output of an command executed with dbclient on a remote server? Message-ID: Hello, im fighting with dbclient to redirect the ouput of an remotely executed command, but it seems not possible i can redirect the stderr before the connection to the server ( for example connection refused error ), but after it doesn't work. Im running dbclient from an script that is executed by cron, when i run the script by hand it works perfectly, but running it from cron the output inst redirected :( anyone have some idea ??? thanks in advance.. Nuno _________________________________________________________________ Correio Electr?nico e Muito Mais Enquanto Viaja. Obtenha o Windows Live Hotmail Gratuito. https://signup.live.com/signup.aspx?id=60969 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20100723/b98cb731/attachment.htm From matt at ucc.asn.au Sat Jul 24 13:16:49 2010 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 24 Jul 2010 13:16:49 +0800 Subject: How to redirect the output of an command executed with dbclient on a remote server? In-Reply-To: References: Message-ID: <20100724051649.GX6819@ucc.gu.uwa.edu.au> What commandline are you running? If it works by hand but not from a script then that suggests that it might be that the program needs a TTY to run properly - you could try running "dbclient -t" in the cronjob? Testing here redirecting output seems to work as below (the shell is zsh). I've added -T to be similar to how a cronjob would run. Matt evil:~/src/dropbear ./dbclient -T localhost find /etc/lvm > /dev/null matt at localhost's password: find: `/etc/lvm/cache': Permission denied find: `/etc/lvm/backup': Permission denied find: `/etc/lvm/archive': Permission denied [1] 22210 exit 1 ./dbclient -T localhost find /etc/lvm > /dev/null evil:~/src/dropbear ./dbclient -T localhost find /etc/lvm 2> /dev/null matt at localhost's password: /etc/lvm /etc/lvm/cache /etc/lvm/backup /etc/lvm/lvm.conf /etc/lvm/archive [1] 22216 exit 1 ./dbclient -T localhost find /etc/lvm 2> /dev/null On Fri, Jul 23, 2010 at 10:53:49PM +0000, mbus25 . wrote: > > Hello, im fighting with dbclient to redirect the ouput of an remotely executed command, but it seems not possible > > i can redirect the stderr before the connection to the server ( for example connection refused error ), but after it doesn't work. > > > Im running dbclient from an script that is executed by cron, when i run the script by hand it works perfectly, but running it from cron the output inst redirected :( > > anyone have some idea ??? > thanks in advance.. > > Nuno > _________________________________________________________________ > Correio Electr?nico e Muito Mais Enquanto Viaja. Obtenha o Windows Live Hotmail Gratuito. > https://signup.live.com/signup.aspx?id=60969 From sleeper0110 at gmail.com Thu Jul 29 00:36:02 2010 From: sleeper0110 at gmail.com (Mike J) Date: Wed, 28 Jul 2010 10:36:02 -0600 Subject: Compiling PAM support Message-ID: Hi, I've compiled in PAM support with "./configure --enable-pam". I can verify that PAM has been compiled in using "ldd dropbear". However when I try to use dropbear, it doesn't look like it is using PAM. It's still using the system password file (without going through PAM). So my question is, now that I have dropbear compiled with PAM support, how do I get dropbear to use PAM? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20100728/f06368f6/attachment.htm From matt at ucc.asn.au Thu Jul 29 19:55:36 2010 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 29 Jul 2010 19:55:36 +0800 Subject: Compiling PAM support In-Reply-To: References: Message-ID: <20100729115536.GB6819@ucc.gu.uwa.edu.au> Hi, You need to enable "ENABLE_SVR_PAM_AUTH" and disable "ENABLE_SVR_PASSWORD_AUTH" in options.h. Note that Dropbear only supports simple PAM auth (asking for a username/password), nothing more complicated since the API isn't well suited to network apps. Cheers, Matt On Wed, Jul 28, 2010 at 10:36:02AM -0600, Mike J wrote: > Hi, > > I've compiled in PAM support with "./configure --enable-pam". > I can verify that PAM has been compiled in using "ldd dropbear". > However when I try to use dropbear, it doesn't look like it is using PAM. > It's still using the system password file (without going through PAM). > > So my question is, now that I have dropbear compiled with PAM support, how > do I get dropbear to use PAM? > > Thanks. From sleeper0110 at gmail.com Fri Jul 30 06:50:48 2010 From: sleeper0110 at gmail.com (Mike J) Date: Thu, 29 Jul 2010 16:50:48 -0600 Subject: Compiling PAM support In-Reply-To: <20100729115536.GB6819@ucc.gu.uwa.edu.au> References: <20100729115536.GB6819@ucc.gu.uwa.edu.au> Message-ID: That seems to work. Thanks! Mike On Thu, Jul 29, 2010 at 5:55 AM, Matt Johnston wrote: > Hi, > > You need to enable "ENABLE_SVR_PAM_AUTH" and disable > "ENABLE_SVR_PASSWORD_AUTH" in options.h. Note that Dropbear > only supports simple PAM auth (asking for a > username/password), nothing more complicated since the API > isn't well suited to network apps. > > Cheers, > Matt > > On Wed, Jul 28, 2010 at 10:36:02AM -0600, Mike J wrote: > > Hi, > > > > I've compiled in PAM support with "./configure --enable-pam". > > I can verify that PAM has been compiled in using "ldd dropbear". > > However when I try to use dropbear, it doesn't look like it is using PAM. > > It's still using the system password file (without going through PAM). > > > > So my question is, now that I have dropbear compiled with PAM support, > how > > do I get dropbear to use PAM? > > > > Thanks. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20100729/26306550/attachment.htm From ssh at sgi.com Sat Jul 31 03:10:31 2010 From: ssh at sgi.com (Steven Hein) Date: Fri, 30 Jul 2010 14:10:31 -0500 Subject: Capturing backgrounded dbclient command output Message-ID: <4C5323A7.2080304@sgi.com> I've been using dropbear-0.52 happily for a long time now, but today I tried to write a shell script to execute multiple dbclient commands in parallel (backgrounded), capture their output, and then display it when all dbclient commands have finished. But I can't seem to capture any output from the dbclient command. The target platform for this is an embedded platform running busybox....but I boiled it down to a simple failing case on my Fedora 12 box (I built a brand new dbclient from the 0.52 tarball). Here's the simple failing case: #! /bin/sh (/tmp/dropbear-0.52/dbclient -y -i /tmp/id_rsa_db localhost pwd) > /tmp/tout & wait When this script completes, there is nothing in /tmp/tout When I run this script (same case, just using the openssh client instead): #! /bin/sh (ssh localhost pwd) > /tmp/tout & wait Then I have data in /tmp/out (the output from the 'pwd' command). This problem only appears to happen when the dbclient command is run in the background from within a script. If I run this command directly from the shell command prompt: (/tmp/dropbear-0.52/dbclient -y -i /tmp/id_rsa_db localhost pwd) > /tmp/tout &; wait Then /tmp/tout contains the output of the 'pwd' command. Has anyone else wrestled with this problem? Any solutions or pointers? Thanks! Steve From ssh at sgi.com Sat Jul 31 22:01:47 2010 From: ssh at sgi.com (Steve Hein) Date: Sat, 31 Jul 2010 09:01:47 -0500 Subject: Capturing backgrounded dbclient command output In-Reply-To: <4C5323A7.2080304@sgi.com> References: <4C5323A7.2080304@sgi.com> Message-ID: <4C542CCB.7050701@sgi.com> I've continued to investigate this issue, and the problem is specific to not having stdin available. I found that I don't see my output when I run this: /tmp/dropbear-0.52/dbclient -y -i /tmp/id_rsa_db localhost pwd I've been using dropbear-0.52 happily for a long time now, but > today I tried to write a shell script to execute multiple > dbclient commands in parallel (backgrounded), capture > their output, and then display it when all dbclient > commands have finished. But I can't seem to capture > any output from the dbclient command. > > The target platform for this is an embedded platform > running busybox....but I boiled it down to a simple > failing case on my Fedora 12 box (I built a brand > new dbclient from the 0.52 tarball). > > > Here's the simple failing case: > > > #! /bin/sh > > (/tmp/dropbear-0.52/dbclient -y -i /tmp/id_rsa_db localhost pwd) > > /tmp/tout & > wait > > > When this script completes, there is nothing in /tmp/tout > > > > When I run this script (same case, just using the openssh client > instead): > > #! /bin/sh > > (ssh localhost pwd) > /tmp/tout & > wait > > > Then I have data in /tmp/out (the output from the 'pwd' command). > > > > > This problem only appears to happen when the dbclient command is run > in the background from within a script. If I run this command > directly from the shell command prompt: > > (/tmp/dropbear-0.52/dbclient -y -i /tmp/id_rsa_db localhost pwd) > > /tmp/tout &; wait > > Then /tmp/tout contains the output of the 'pwd' command. > > > > Has anyone else wrestled with this problem? Any solutions or pointers? > > > Thanks! > Steve > > From ssh at sgi.com Sun Aug 1 04:25:24 2010 From: ssh at sgi.com (Steve Hein) Date: Sat, 31 Jul 2010 15:25:24 -0500 Subject: Capturing backgrounded dbclient command output In-Reply-To: <4C542CCB.7050701@sgi.com> References: <4C5323A7.2080304@sgi.com> <4C542CCB.7050701@sgi.com> Message-ID: <4C5486B4.5020108@sgi.com> I can confirm now that I am seeing the issue described in this thread: http://www.mail-archive.com/dropbear at ucc.asn.au/msg00325.html and that it was a change in v0.49 that caused this behavior change. I tried to pour through the diffs from 0.48.1 to 0.49, but it's big....... Is there anything relatively easy that I can do to get back to the 0.48.1 behavior related to operating without stdin? I really don't want to fall back that far, but I really have a need for the parallel ssh functionality I described originally, which needs the ability to execute dbclient in the background (and get the command output!). Any help/hints would really be appreciated! Steve On 07/31/2010 09:01 AM, Steve Hein wrote: > I've continued to investigate this issue, and the problem > is specific to not having stdin available. I found that > I don't see my output when I run this: > > /tmp/dropbear-0.52/dbclient -y -i /tmp/id_rsa_db localhost pwd > or when I do this: > > /tmp/dropbear-0.52/dbclient -f -y -i /tmp/id_rsa_db localhost pwd > > > But openssh handles lack of stdin just fine, i.e.: > > ssh localhost pwd < /dev/null > > will still return the command output. > > > > Is this dropbear behavior intentional? If so, does anyone know > what I would need to change to fix it? > > Thanks! > Steve > > > > > > > On 07/30/2010 02:10 PM, Steven Hein wrote: > >> I've been using dropbear-0.52 happily for a long time now, but >> today I tried to write a shell script to execute multiple >> dbclient commands in parallel (backgrounded), capture >> their output, and then display it when all dbclient >> commands have finished. But I can't seem to capture >> any output from the dbclient command. >> >> The target platform for this is an embedded platform >> running busybox....but I boiled it down to a simple >> failing case on my Fedora 12 box (I built a brand >> new dbclient from the 0.52 tarball). >> >> >> Here's the simple failing case: >> >> >> #! /bin/sh >> >> (/tmp/dropbear-0.52/dbclient -y -i /tmp/id_rsa_db localhost pwd) > >> /tmp/tout & >> wait >> >> >> When this script completes, there is nothing in /tmp/tout >> >> >> >> When I run this script (same case, just using the openssh client >> instead): >> >> #! /bin/sh >> >> (ssh localhost pwd) > /tmp/tout & >> wait >> >> >> Then I have data in /tmp/out (the output from the 'pwd' command). >> >> >> >> >> This problem only appears to happen when the dbclient command is run >> in the background from within a script. If I run this command >> directly from the shell command prompt: >> >> (/tmp/dropbear-0.52/dbclient -y -i /tmp/id_rsa_db localhost pwd) > >> /tmp/tout &; wait >> >> Then /tmp/tout contains the output of the 'pwd' command. >> >> >> >> Has anyone else wrestled with this problem? Any solutions or pointers? >> >> >> Thanks! >> Steve >> >> >> > From generatorglukoff at gmail.com Mon Aug 9 10:39:16 2010 From: generatorglukoff at gmail.com (Andrey Batyiev) Date: Mon, 9 Aug 2010 05:39:16 +0300 Subject: dropbear and external libtommath and libtomcrypt Message-ID: <201008090539.17102.generatorglukoff@gmail.com> Hello Is it possible to compile dropbear against external libtommath and libtomcrypt? I'm building system for my router box and these libraries are needed for hostapd, so it would be nice not to embed them into dropbear. Thanks, Andrey From rob at landley.net Thu Aug 12 03:46:38 2010 From: rob at landley.net (Rob Landley) Date: Wed, 11 Aug 2010 14:46:38 -0500 Subject: dropbear and external libtommath and libtomcrypt In-Reply-To: <201008090539.17102.generatorglukoff@gmail.com> References: <201008090539.17102.generatorglukoff@gmail.com> Message-ID: <201008111446.40439.rob@landley.net> On Sunday 08 August 2010 21:39:16 Andrey Batyiev wrote: > Hello > > Is it possible to compile dropbear against external libtommath and > libtomcrypt? I'm building system for my router box and these libraries are > needed for hostapd, so it would be nice not to embed them into dropbear. > > Thanks, > Andrey Are those libraries still maintained outside dropbear? Last time I tried to look them up (because the embedded world desperately needs an stunnel implementation that doesn't depend on openssl, that's why) the website had gone away. Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. From fja0568 at gmail.com Thu Aug 12 04:54:46 2010 From: fja0568 at gmail.com (Farrell Aultman) Date: Wed, 11 Aug 2010 16:54:46 -0400 Subject: dropbear and external libtommath and libtomcrypt In-Reply-To: <201008111446.40439.rob@landley.net> References: <201008090539.17102.generatorglukoff@gmail.com> <201008111446.40439.rob@landley.net> Message-ID: The web site is still up, but the project doesn't appear to be actively maintained. Last log entry was in 2007. I read a while back that Tom got a job. http://libtom.org/?page=features&whatfile=crypt Only what's actually used is compiled into the dropbear executable, so it the tom libs don't add much to the file size. If you still want to do this, the Tom libs have their own Makefiles. One could start there and build the shared libraries. Then one would need to link to them from the dropbear Makefile. Farrell On Wed, Aug 11, 2010 at 3:46 PM, Rob Landley wrote: > On Sunday 08 August 2010 21:39:16 Andrey Batyiev wrote: >> Hello >> >> Is it possible to compile dropbear against external libtommath and >> libtomcrypt? I'm building system for my router box and these libraries are >> needed for hostapd, so it would be nice not to embed them into dropbear. >> >> Thanks, >> ? ?Andrey > > Are those libraries still maintained outside dropbear? ?Last time I tried to > look them up (because the embedded world desperately needs an stunnel > implementation that doesn't depend on openssl, that's why) the website had > gone away. > > Rob > -- > GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem > Forever, and as welcome as New Coke. > From fabriziobertocci at gmail.com Mon Aug 16 18:54:30 2010 From: fabriziobertocci at gmail.com (Fabrizio Bertocci) Date: Mon, 16 Aug 2010 12:54:30 +0200 Subject: keepalive message not sent? Message-ID: Hi All, Here is an interesting (but inconvenient) problem I've found with dbclient when connected to an OpenSSH server that uses the keepalive (ClientAliveInterval & ClientAliveCountMax). I have a OpenSSH server that sends keepalive messages to the client every 10 seconds and consider the client disconnected after 2 failed attempts. On my client I use dbclient (latest version 0.52) to start a connection (using a private key with no password) to setup some tunnels (local & remote). So far so good. When I launch the dbclient from a shell everything is fine, this is what I see on the server log every 10 seconds: debug2: channel 1: request keepalive at openssh.com confirm 1 debug1: Got 100/10 for keepalive debug2: channel 1: request keepalive at openssh.com confirm 1 debug1: Got 100/11 for keepalive ... and the server keep maintaining the connection with the client. Unfortunately, when I invoke my bourne shell script (that I use as wrapper for launching dbclient) from the init script (/etc/init.d/myWrapper.sh), everything SEEMS to work fine, but when the server sends keep alive messages, the dbclient doesn't seem to respond correctly. This is what I see from the server's log: debug2: channel 1: request keepalive at openssh.com confirm 1 debug2: channel 1: almost dead debug2: channel 1: gc: notify user debug1: session_by_channel: session 0 channel 1 debug1: session_close_by_channel: channel 1 child 18881 debug1: session_close_by_channel: channel 1: has child ... Disconnecting: Timeout, your session not responding. debug1: do_cleanup debug1: do_cleanup Does anybody have an idea why ? It has something to do with I/O probably or some settings that are available when I launch my script (or the dbclient) from an interactive session but is missing when is invoked from the init script... Regards, fabrizio -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20100816/411c4076/attachment.htm From matt at ucc.asn.au Tue Aug 17 21:44:21 2010 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 17 Aug 2010 21:44:21 +0800 Subject: keepalive message not sent? In-Reply-To: References: Message-ID: <20100817134421.GS4478@ucc.gu.uwa.edu.au> Hi, Could you try running "strace -p " on the dbclient process when it's running under the wrapper, soon after it starts? That might give a clue as to how it differs. Cheers, Matt On Mon, Aug 16, 2010 at 12:54:30PM +0200, Fabrizio Bertocci wrote: > Hi All, > Here is an interesting (but inconvenient) problem I've found with dbclient > when connected to an OpenSSH server that uses the keepalive > (ClientAliveInterval & ClientAliveCountMax). > > I have a OpenSSH server that sends keepalive messages to the client every 10 > seconds and consider the client disconnected after 2 failed attempts. > > On my client I use dbclient (latest version 0.52) to start a connection > (using a private key with no password) to setup some tunnels (local & > remote). > So far so good. When I launch the dbclient from a shell everything is fine, > this is what I see on the server log every 10 seconds: > > debug2: channel 1: request keepalive at openssh.com confirm 1 > debug1: Got 100/10 for keepalive > debug2: channel 1: request keepalive at openssh.com confirm 1 > debug1: Got 100/11 for keepalive > ... > and the server keep maintaining the connection with the client. > > Unfortunately, when I invoke my bourne shell script (that I use as wrapper > for launching dbclient) from the init script (/etc/init.d/myWrapper.sh), > everything SEEMS to work fine, but when the server sends keep alive > messages, the dbclient doesn't seem to respond correctly. > This is what I see from the server's log: > > debug2: channel 1: request keepalive at openssh.com confirm 1 > debug2: channel 1: almost dead > debug2: channel 1: gc: notify user > debug1: session_by_channel: session 0 channel 1 > debug1: session_close_by_channel: channel 1 child 18881 > debug1: session_close_by_channel: channel 1: has child > ... > Disconnecting: Timeout, your session not responding. > debug1: do_cleanup > debug1: do_cleanup > > Does anybody have an idea why ? > It has something to do with I/O probably or some settings that are available > when I launch my script (or the dbclient) from an interactive session but is > missing when is invoked from the init script... > > Regards, > fabrizio From scott at binrock.net Tue Aug 24 04:06:46 2010 From: scott at binrock.net (Scott Sturdivant) Date: Mon, 23 Aug 2010 16:06:46 -0400 (EDT) Subject: dbclient - banner too long? Message-ID: Using dropbear 0.50 (I know there's a more recent, but didn't see any changelog notes about this issue), if I try to use dbclient to connect to a host that has a long banner (1553 chars), I get the following error: dbclient: connection to user at host:22 exited: string too long On this particular host, I do not have access to change the banner. However on a different machine that I do have access to, I did change its banner and confirmed that indeed when using the longer one, dbclient gives the 'string too long' error and aborts. Are there any workarounds for this? Thanks, Scott From matt at ucc.asn.au Tue Aug 24 19:11:47 2010 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 24 Aug 2010 19:11:47 +0800 Subject: dbclient - banner too long? In-Reply-To: References: Message-ID: <20100824111147.GA4478@ucc.gu.uwa.edu.au> On Mon, Aug 23, 2010 at 04:06:46PM -0400, Scott Sturdivant wrote: > Using dropbear 0.50 (I know there's a more recent, but didn't see any > changelog notes about this issue), if I try to use dbclient to connect to > a host that has a long banner (1553 chars), I get the following error: > > dbclient: connection to user at host:22 exited: string too long > > On this particular host, I do not have access to change the banner. > However on a different machine that I do have access to, I did change its > banner and confirmed that indeed when using the longer one, dbclient > gives the 'string too long' error and aborts. > > Are there any workarounds for this? A banner that size should work, there's a limit of 2000 characters but over that it just doesn't display the banner, continuing as normal. It seems like something else is going wrong. What SSH server is being used, and can I connect to it via the internet (prior to authenticating)? "telnet servername 22" will print out the version string. Cheers, Matt From matt at ucc.asn.au Tue Aug 24 19:39:07 2010 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 24 Aug 2010 19:39:07 +0800 Subject: dbclient - banner too long? In-Reply-To: <20100824111147.GA4478@ucc.gu.uwa.edu.au> References: <20100824111147.GA4478@ucc.gu.uwa.edu.au> Message-ID: <20100824113907.GB4478@ucc.gu.uwa.edu.au> On Tue, Aug 24, 2010 at 07:11:47PM +0800, Matt Johnston wrote: > > On this particular host, I do not have access to change the banner. > > However on a different machine that I do have access to, I did change its > > banner and confirmed that indeed when using the longer one, dbclient > > gives the 'string too long' error and aborts. > > > > Are there any workarounds for this? > > A banner that size should work, there's a limit of 2000 > characters but over that it just doesn't display the banner, > continuing as normal. It seems like something else is going > wrong. What SSH server is being used, and can I connect to > it via the internet (prior to authenticating)? > "telnet servername 22" will print out the version string. Having actually tested it here now, you're right, it is broken. A workaround is increasing MAX_STRING_LEN in options.h (or sysoptions.h in more recent versions) from 1400 to something larger - 10000 perhaps? I'll get a better fix in the next release. Cheers, Matt From scott at binrock.net Tue Aug 24 21:28:16 2010 From: scott at binrock.net (Scott Sturdivant) Date: Tue, 24 Aug 2010 09:28:16 -0400 (EDT) Subject: dbclient - banner too long? In-Reply-To: <20100824113907.GB4478@ucc.gu.uwa.edu.au> References: <20100824111147.GA4478@ucc.gu.uwa.edu.au> <20100824113907.GB4478@ucc.gu.uwa.edu.au> Message-ID: On Tue, 24 Aug 2010, Matt Johnston wrote: > On Tue, Aug 24, 2010 at 07:11:47PM +0800, Matt Johnston wrote: >>> On this particular host, I do not have access to change the banner. >>> However on a different machine that I do have access to, I did change its >>> banner and confirmed that indeed when using the longer one, dbclient >>> gives the 'string too long' error and aborts. >>> >>> Are there any workarounds for this? >> >> A banner that size should work, there's a limit of 2000 >> characters but over that it just doesn't display the banner, >> continuing as normal. It seems like something else is going >> wrong. What SSH server is being used, and can I connect to >> it via the internet (prior to authenticating)? >> "telnet servername 22" will print out the version string. > > Having actually tested it here now, you're right, it is > broken. A workaround is increasing MAX_STRING_LEN in > options.h (or sysoptions.h in more recent versions) from > 1400 to something larger - 10000 perhaps? I'll get a better > fix in the next release. > > Cheers, > Matt > Thanks Matt - I have made the change and confirmed that it fixes my issue! Thanks again for your help, Scott From xaos at darksmile.net Wed Aug 25 09:06:36 2010 From: xaos at darksmile.net (xaos) Date: Tue, 24 Aug 2010 21:06:36 -0400 Subject: Dropbear for iPhone Message-ID: <4C746C9C.7090705@darksmile.net> Hello everyone. This is what I'd like to do: In my iPhone app, I'd like to call the Dropbear client code in order to create an SSH tunnel to another machine. I do not want an independent ssh command-line client. I will be running the client code from an iPhone thread. I do not want X11 forwarding or SSH compression. Easier said than done. I guess. Quick info about myself: I am a serious developer who knows a few things about iPhone, Objective-C, C programming and UNIX. Been with UNIX since '84. Yes, I'm, old(er). So, I don't need hand holding here, just a few pointers to get me going. Naturally, I will post my results as I tend to do, see my blog at: http://www.xm5design.com/ Ok. So my initial code inspection turned out the following: in "cli-main.c" there is a way to start the code without a "main()" which would clash with the "main()" in any iPhone app. This is good! However, the defines: "DBMULTI_dbclient" and "DROPBEAR_MULTI" are not exactly clear on their meaning. There is a "cli_dropbear_exit" function that seems to be the central exit gate for the client code. If true, this is fantastic since I don't want to Dropbear code to "exit()". I want a nice "return()" which will shutdown the dropbear thread gracefully (or re-start). Problem: I can't really use the Makefile genned by configure since I will execute the code from Xcode. Any hints? I tried a simple test on my OSX machine like this: ./configure --disable-zlib --disable-syslog --disable-lastlog and then: make PROGRAMS="dbclient" >make.log 2>&1 and I got a working client binary. I was able to ssh to another machine, etc, etc.. However when I do: "otool -L dbclient" (otool is like like ldd) I only see "/usr/lib/libSystem.B.dylib" no other lib. Does that mean I don't need the libraries in "libtomcrypt" and "libtommath" for a simple client code? Please accept my thanks ahead of time for this. Any help is appreciated. -George H. From matt at ucc.asn.au Wed Aug 25 19:40:11 2010 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 25 Aug 2010 19:40:11 +0800 Subject: Dropbear for iPhone In-Reply-To: <4C746C9C.7090705@darksmile.net> References: <4C746C9C.7090705@darksmile.net> Message-ID: <20100825114011.GF4478@ucc.gu.uwa.edu.au> The "multi" stuff is defined in the Makefile - compile with "make MULTI=1" to create the multi-function binary. If you're only using dbclient it might be easier to just rename main() in cli-main.c . libtomcrypt and libtommath are built as static libraries that are linked to Dropbear. I think you should be able to run ./configure once, then add all the files including the "config.h" to your xcode project. I did that one time a few years ago and it worked OK, though I'm not sure how you'd run ./configure with the iphone SDK - perhaps point it at the relevant cross-compiling $CC? Off the top of my head I think most of dbclient should be threadsafe at least if there's only a single instance running, though there are calls to getpwnam() etc that could need attention. I guess you could replace the stdin/stdout file descriptor with a unix pipe to your main program as a way of talking to your UI with minimal changes to the dropbear code. You will also need to change the code in cli-chansession.c that sets up terminal control codes. Cheers, Matt On Tue, Aug 24, 2010 at 09:06:36PM -0400, xaos wrote: > Hello everyone. This is what I'd like to do: > > In my iPhone app, I'd like to call the Dropbear client code in order to create an SSH tunnel > to another machine. I do not want an independent ssh command-line client. > > I will be running the client code from an iPhone thread. > > I do not want X11 forwarding or SSH compression. > > Easier said than done. I guess. > > Quick info about myself: I am a serious developer who knows a few things about iPhone, > Objective-C, C programming and UNIX. Been with UNIX since '84. Yes, I'm, old(er). > > So, I don't need hand holding here, just a few pointers to get me going. Naturally, I will post > my results as I tend to do, see my blog at: http://www.xm5design.com/ > > Ok. So my initial code inspection turned out the following: > > in "cli-main.c" there is a way to start the code without a "main()" which would clash with the > "main()" in any iPhone app. > > This is good! > > However, the defines: "DBMULTI_dbclient" and "DROPBEAR_MULTI" are not > exactly clear on their meaning. > > There is a "cli_dropbear_exit" function that seems to be the central exit gate for the client code. > If true, this is fantastic since I don't want to Dropbear code to "exit()". I want a nice "return()" > which will shutdown the dropbear thread gracefully (or re-start). > > Problem: I can't really use the Makefile genned by configure since I will execute the code > from Xcode. Any hints? > > I tried a simple test on my OSX machine like this: > > ./configure --disable-zlib --disable-syslog --disable-lastlog > > and then: > > make PROGRAMS="dbclient" >make.log 2>&1 > > and I got a working client binary. I was able to ssh to another machine, etc, etc.. > > However when I do: "otool -L dbclient" (otool is like like ldd) > I only see "/usr/lib/libSystem.B.dylib" no other lib. Does that mean > I don't need the libraries in "libtomcrypt" and "libtommath" for a simple client code? > > Please accept my thanks ahead of time for this. Any help is appreciated. > > -George H. From xaos at darksmile.net Fri Aug 27 06:40:29 2010 From: xaos at darksmile.net (xaos) Date: Thu, 26 Aug 2010 18:40:29 -0400 Subject: Dropbear for iPhone In-Reply-To: <20100825114011.GF4478@ucc.gu.uwa.edu.au> References: <4C746C9C.7090705@darksmile.net> <20100825114011.GF4478@ucc.gu.uwa.edu.au> Message-ID: <4C76ED5D.7090803@darksmile.net> Matt, First, after some experimentation, I have the following command line setup: ./configure --disable-zlib --disable-syslog --disable-lastlog --disable-shadow --disable-utmp --disable-utmpx --disable-wtmp --disable-wtmpx --disable-loginfunc --disable-pututline --disable-pututxline Are these options correct for a strictly client only build? make PROGRAMS=dbclient >make.log 2>&1 However, in "config.h" I still have: 337 /* Define to 1 if you have the `utmpxname' function. */ 338 #define HAVE_UTMPXNAME 1 339 340 /* Define to 1 if you have the header file. */ 341 #define HAVE_UTMPX_H 1 342 343 /* Define to 1 if you have the header file. */ 344 #define HAVE_UTMP_H 1 Shouldn't these #defines not be there (based on the "./configure" command)? Actually, this is a problem since Xcode is telling me that these header files do not exist. Since I do not want to change anything in config.h, I make changes in "options.h". It looks like "includes.h" has #include "config.h" #include "options.h" "options.h" is after "config.h" so I should be able to undef what I don't need. Is this the proper procedure? Currently, my "options.h" has: /****************************************************************** * Define compile-time options below - the "#ifndef DROPBEAR_XXX .... #endif" * parts are to allow for commandline -DDROPBEAR_XXX options etc. ******************************************************************/ #define TARGET_IPHONE #if defined(TARGET_IPHONE) /* This should be set as part of the "compiler command line defines" but we just make sure */ #if !defined(DROPBEAR_CLIENT) #define DROPBEAR_CLIENT #endif /* Define to 1 if you have the `utmpname' function. */ #if defined(HAVE_UTMPNAME) #undef HAVE_UTMPNAME #endif /* Define to 1 if you have the `utmpxname' function. */ #if defined(HAVE_UTMPXNAME) #undef HAVE_UTMPXNAME #endif /* Define to 1 if you have the header file. */ #if defined(HAVE_UTMPX_H) #undef HAVE_UTMPX_H #endif /* Define to 1 if you have the header file. */ #if defined(HAVE_UTMP_H) #undef HAVE_UTMP_H #endif #endif ... ... ... One more thing. As I find small issues (as shown above) do I go ahead and post in the list? It could get verbose. -George On 8/25/10 7:40 AM, Matt Johnston wrote: > The "multi" stuff is defined in the Makefile - compile with > "make MULTI=1" to create the multi-function binary. If > you're only using dbclient it might be easier to just rename > main() in cli-main.c . > > libtomcrypt and libtommath are built as static libraries > that are linked to Dropbear. I think you should be able to > run ./configure once, then add all the files including the > "config.h" to your xcode project. I did that one time a few > years ago and it worked OK, though I'm not sure how you'd > run ./configure with the iphone SDK - perhaps point it at > the relevant cross-compiling $CC? > > Off the top of my head I think most of dbclient should be > threadsafe at least if there's only a single instance > running, though there are calls to getpwnam() etc that > could need attention. I guess you could replace the > stdin/stdout file descriptor with a unix pipe to your main > program as a way of talking to your UI with minimal changes > to the dropbear code. You will also need to change the code > in cli-chansession.c that sets up terminal control codes. > > Cheers, > Matt > > On Tue, Aug 24, 2010 at 09:06:36PM -0400, xaos wrote: >> Hello everyone. This is what I'd like to do: >> >> In my iPhone app, I'd like to call the Dropbear client code in order to create an SSH tunnel >> to another machine. I do not want an independent ssh command-line client. >> >> I will be running the client code from an iPhone thread. >> >> I do not want X11 forwarding or SSH compression. >> >> Easier said than done. I guess. >> >> Quick info about myself: I am a serious developer who knows a few things about iPhone, >> Objective-C, C programming and UNIX. Been with UNIX since '84. Yes, I'm, old(er). >> >> So, I don't need hand holding here, just a few pointers to get me going. Naturally, I will post >> my results as I tend to do, see my blog at: http://www.xm5design.com/ >> >> Ok. So my initial code inspection turned out the following: >> >> in "cli-main.c" there is a way to start the code without a "main()" which would clash with the >> "main()" in any iPhone app. >> >> This is good! >> >> However, the defines: "DBMULTI_dbclient" and "DROPBEAR_MULTI" are not >> exactly clear on their meaning. >> >> There is a "cli_dropbear_exit" function that seems to be the central exit gate for the client code. >> If true, this is fantastic since I don't want to Dropbear code to "exit()". I want a nice "return()" >> which will shutdown the dropbear thread gracefully (or re-start). >> >> Problem: I can't really use the Makefile genned by configure since I will execute the code >> from Xcode. Any hints? >> >> I tried a simple test on my OSX machine like this: >> >> ./configure --disable-zlib --disable-syslog --disable-lastlog >> >> and then: >> >> make PROGRAMS="dbclient">make.log 2>&1 >> >> and I got a working client binary. I was able to ssh to another machine, etc, etc.. >> >> However when I do: "otool -L dbclient" (otool is like like ldd) >> I only see "/usr/lib/libSystem.B.dylib" no other lib. Does that mean >> I don't need the libraries in "libtomcrypt" and "libtommath" for a simple client code? >> >> Please accept my thanks ahead of time for this. Any help is appreciated. >> >> -George H. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20100826/f6222e6c/attachment.htm From ahilan.anantha at gmail.com Sat Sep 11 11:01:04 2010 From: ahilan.anantha at gmail.com (Ahilan Anantha) Date: Sat, 11 Sep 2010 03:01:04 +0000 (UTC) Subject: keepalive message not sent? References: Message-ID: Fabrizio Bertocci gmail.com> writes: > > > Hi All, > Here is an interesting (but inconvenient) problem I've found with dbclient when connected to an OpenSSH server that uses the keepalive (ClientAliveInterval & ClientAliveCountMax). > > > I have a OpenSSH server that sends keepalive messages to the client every 10 seconds and consider the client disconnected after 2 failed attempts. > > On my client I use dbclient (latest version 0.52) to start a connection (using a private key with no password) to setup some tunnels (local & remote). > So far so good. When I launch the dbclient from a shell everything is fine, this is what I see on the server log every 10 seconds: > > > debug2: channel 1: request keepalive openssh.com confirm 1 > debug1: Got 100/10 for keepalive > debug2: channel 1: request keepalive openssh.com confirm 1 > debug1: Got 100/11 for keepalive > ... > > > and the server keep maintaining the connection with the client. > > Unfortunately, when I invoke my bourne shell script (that I use as wrapper for launching dbclient) from the init script (/etc/init.d/myWrapper.sh), everything SEEMS to work fine, but when the server sends keep alive messages, the dbclient doesn't seem to respond correctly. > This is what I see from the server's log: > > > debug2: channel 1: request keepalive openssh.com confirm 1 > debug2: channel 1: almost dead > debug2: channel 1: gc: notify user > debug1: session_by_channel: session 0 channel 1 > debug1: session_close_by_channel: channel 1 child 18881 > debug1: session_close_by_channel: channel 1: has child > ... > Disconnecting: Timeout, your session not responding. > debug1: do_cleanup > debug1: do_cleanup > > > Does anybody have an idea why ? > It has something to do with I/O probably or some settings that are available when I launch my script (or the dbclient) from an interactive session but is missing when is invoked from the init script... > > Regards, > fabrizio > > So reading the OpenSSH source code... it implements "client alive" by sending an "SSH_MSG_GLOBAL_REQUEST" (type: 80) message. dbclient doesn't implement that message and so returns an "SSH_MSG_UNIMPLEMENTED" (type: 3) message. But the OpenSSH server expects either an "SSH_MSG_REQUEST_SUCCESS" (type: 81) or "SSH_MSG_REQUEST_FAILURE" (type: 82) response. But I don't know why it works when launching dbclient from the shell. You'd think it would just always kick dbclient. Regards, Ahilan From aanantha at riverbed.com Tue Sep 14 11:16:23 2010 From: aanantha at riverbed.com (Ahilan Anantha) Date: Tue, 14 Sep 2010 03:16:23 +0000 (UTC) Subject: keepalive message not sent? References: Message-ID: Ahilan Anantha gmail.com> writes: [snip] > But I don't know why it works when launching dbclient from the shell. > You'd think it would just always kick dbclient. > I misread the OpenSSH code. I read the "if" but not the "else" block. If OpenSSH finds an "open session suitable for keepaliving" it will send an SSH_MSG_CHANNEL_REQUEST. dbclient does appear to service that. So probably that is what is happening when there's an actual shell session. Only when it can't find such a session, will it send an SSH_MSG_GLOBAL_REQUEST... which dbclient does not implement. I suspect that's what's going on when you ran dbclient in such a way that it only has a tunnel. I think it is fixable by just adding a handler for SSH_MSG_GLOBAL_REQUEST for the dropbear client loop that just sends back SSH_MSG_REQUEST_FAILURE. Ahilan From cheungtifan at gmail.com Wed Sep 15 23:53:06 2010 From: cheungtifan at gmail.com (Alex Zhang) Date: Wed, 15 Sep 2010 23:53:06 +0800 Subject: Compiled Dropbear on Solairs 7 SPARC Message-ID: Hi all, This is a old machine, Sun Enterprise 450. Finally I decided to use ssh instead of telnet, and those small modification should be done in order to get it compile. First, add typedef unsigned char u_int8_t; typedef unsigned int u_int16_t; typedef unsigned short u_int32_t; in fake-rfc2553.h Second, go to libtomcrypt and run: export PATH=$PATH:/usr/ccs/bin (I am using zsh) make So is in libtommath Third, ./configure as you know. Note that Makefile should be modified to the following: LIBS=$(LTC) $(LTM) -lsocket -lnsl -lresolv -lcrypt `-lresolv' should be added in order to get it compiles, or the following error will occur when compiling: gcc -L/usr/local/lib -R/usr/local/lib -o dropbear dbutil.o buffer.o dss.o bignum.o signkey.o rsa.o random.o queue.o atomicio.o compat.o fake-rfc2553.o common-session.o packet.o common-algo.o common-kex.o common-channel.o common-chansession.o termcodes.o loginrec.o tcp-accept.o listener.o process-packet.o common-runopts.o circbuffer.o svr-kex.o svr-algo.o svr-auth.o sshpty.o svr-authpasswd.o svr-authpubkey.o svr-authpubkeyoptions.o svr-session.o svr-service.o svr-chansession.o svr-runopts.o svr-agentfwd.o svr-main.o svr-x11fwd.o svr-tcpfwd.o svr-authpam.o libtomcrypt/libtomcrypt.a libtommath/libtommath.a -lsocket -lnsl -lcrypt Undefined first referenced symbol in file inet_aton fake-rfc2553.o ld: fatal: Symbol referencing errors. No output written to dropbear collect2: ld returned 1 exit status make: *** [dropbear] Error 1 I found that scp won't compile. So, make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert" make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert" install And, at last, enjoy! OSQDU::Alex +------------------------------------ |Alex Zhang(Difan) |eMbedded Linux & Chemistry |College of Chemistry & Environment |Qingdao University +------------------------------------ OpenSource Qingdao University http://qdu.ac.cn/ Blog http://difan.org.cn/