From kevans at android-x86.org Sun Jul 1 09:43:47 2012 From: kevans at android-x86.org (Kyle Evans) Date: Sat, 30 Jun 2012 21:43:47 -0400 Subject: Passphrase keys? Message-ID: <4FEFAB53.7050404@android-x86.org> Hello, I do not see any mention of creating keys with a passphrase. If it is somehow possible, please inform. Otherwise, has there been any thought of adding the support? I do not feel comfortable having a free and clear login key on an android device, which I would like to use to connect to and openSSH server. Thanks, Kyle Evans From matt at ucc.asn.au Sun Jul 1 19:19:36 2012 From: matt at ucc.asn.au (Matt Johnston) Date: Sun, 1 Jul 2012 19:19:36 +0800 Subject: Passphrase keys? In-Reply-To: <4FEFAB53.7050404@android-x86.org> References: <4FEFAB53.7050404@android-x86.org> Message-ID: <20120701111936.GU10395@ucc.gu.uwa.edu.au> Hi, Currently keys can't be encrypted. It would probably be worth adding - I guess just supporting OpenSSH format would be most convenient (and also for non-encrypted keys, though I think they have a different format). You can use OpenSSH's ssh-agent with Dropbear as an alternative to encrypted keys, that's what I do on my own systems. CHeers, Matt On Sat, Jun 30, 2012 at 09:43:47PM -0400, Kyle Evans wrote: > Hello, I do not see any mention of creating keys with a passphrase. > If it is somehow possible, please inform. Otherwise, has there been > any thought of adding the support? I do not feel comfortable having > a free and clear login key on an android device, which I would like > to use to connect to and openSSH server. > > Thanks, > Kyle Evans > From maris.rob at ingenieur.de Mon Jul 23 20:13:05 2012 From: maris.rob at ingenieur.de (Maris, Rob) Date: Mon, 23 Jul 2012 14:13:05 +0200 Subject: forwarding problems Message-ID: Use case: - embedded system running dbclient with server connection that includes a port forwarding. - system is powered off, and powered on again - upon next boot, the following message is given: dbclient: Remote TCP forward request failed (port 10526 -> 127.0.0.1:22) I'd believe that doing a SO_REUSEADDR via setsockopt() would resolve this issue. However, I'm not sure and where to implement this (in cli_tcpfwd.c?) Thanks for any suggestions. Rob From maris.rob at ingenieur.de Mon Jul 23 21:10:12 2012 From: maris.rob at ingenieur.de (Maris, Rob) Date: Mon, 23 Jul 2012 15:10:12 +0200 Subject: forwarding problems In-Reply-To: <20120723123219.GB16933@ucc.gu.uwa.edu.au> References: <20120723123219.GB16933@ucc.gu.uwa.edu.au> Message-ID: Thanks for instant answering, I was still aware of SO_REUSEADDR in dbutil.c, but could not quickly determine whether this also applies to forwarding channels. In any case, reconnect goes OK when the embedded system gets a reboot prior to poweroff (as could be expected). In the problem case, the host netstat shows up tcp 0 0 localhost.localdo:51225 localhost.localdo:10526 CLOSE_WAIT BTW: I'm using 0.52 on a blackfin platform. Regarding strace: Must be prepared. Is not yet built into the root file system. I'll return later to it. Rob Note: I also noticed http://comments.gmane.org/gmane.network.ssh.dropbear/962 before, and the suggestions in that thread will probably be realised after the current problem has been solved. Am 23.07.2012, 14:32 Uhr, schrieb Matt Johnston : > Hi, > > Dropbear already does SO_REUSEADDR for all listening > sockets, see > https://secure.ucc.asn.au/hg/dropbear/file/983a817f8e41/dbutil.c#l254 > > Can you run strace on dbclient to see what's failing? Does > the server log anything? > > Cheers, > Matt > > On Mon, Jul 23, 2012 at 02:13:05PM +0200, Maris, Rob wrote: >> Use case: >> - embedded system running dbclient with server connection that >> includes a port forwarding. >> - system is powered off, and powered on again >> - upon next boot, the following message is given: >> dbclient: Remote TCP forward request failed (port 10526 -> 127.0.0.1:22) >> >> I'd believe that doing a SO_REUSEADDR via setsockopt() would resolve >> this issue. >> However, I'm not sure and where to implement this (in cli_tcpfwd.c?) >> >> Thanks for any suggestions. >> >> Rob From matt at ucc.asn.au Mon Jul 23 23:16:32 2012 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 23 Jul 2012 23:16:32 +0800 Subject: forwarding problems In-Reply-To: References: <20120723123219.GB16933@ucc.gu.uwa.edu.au> Message-ID: <20120723151632.GC16933@ucc.gu.uwa.edu.au> Ah right. Is the server-side sshd/dropbear process still running? I guess something hasn't noticed that the client has gone away, though I'm not really sure what you can do. Is the embedded device sending icmp port unreachable (or similar?) packets out, or does it just silently drop the stale connection's packets? Matt On Mon, Jul 23, 2012 at 03:10:12PM +0200, Maris, Rob wrote: > Thanks for instant answering, > > I was still aware of SO_REUSEADDR in dbutil.c, but could not quickly > determine whether this also applies to forwarding channels. In any > case, reconnect goes OK when the embedded system gets a reboot prior > to poweroff (as could be expected). > > In the problem case, the host netstat shows up > tcp 0 0 localhost.localdo:51225 localhost.localdo:10526 > CLOSE_WAIT > > BTW: I'm using 0.52 on a blackfin platform. > > Regarding strace: Must be prepared. Is not yet built into the root > file system. I'll return later to it. > > Rob > > Note: I also noticed > http://comments.gmane.org/gmane.network.ssh.dropbear/962 > before, and the suggestions in that thread will probably be realised > after the current problem has been solved. > > > > Am 23.07.2012, 14:32 Uhr, schrieb Matt Johnston : > > >Hi, > > > >Dropbear already does SO_REUSEADDR for all listening > >sockets, see > >https://secure.ucc.asn.au/hg/dropbear/file/983a817f8e41/dbutil.c#l254 > > > >Can you run strace on dbclient to see what's failing? Does > >the server log anything? > > > >Cheers, > >Matt > > > >On Mon, Jul 23, 2012 at 02:13:05PM +0200, Maris, Rob wrote: > >>Use case: > >>- embedded system running dbclient with server connection that > >>includes a port forwarding. > >>- system is powered off, and powered on again > >>- upon next boot, the following message is given: > >>dbclient: Remote TCP forward request failed (port 10526 -> 127.0.0.1:22) > >> > >>I'd believe that doing a SO_REUSEADDR via setsockopt() would resolve > >>this issue. > >>However, I'm not sure and where to implement this (in cli_tcpfwd.c?) > >> > >>Thanks for any suggestions. > >> > >>Rob From maris.rob at ingenieur.de Tue Jul 24 07:46:18 2012 From: maris.rob at ingenieur.de (Maris, Rob) Date: Tue, 24 Jul 2012 01:46:18 +0200 Subject: forwarding problems In-Reply-To: <20120723151632.GC16933@ucc.gu.uwa.edu.au> References: <20120723123219.GB16933@ucc.gu.uwa.edu.au> <20120723151632.GC16933@ucc.gu.uwa.edu.au> Message-ID: Am 23.07.2012, 17:16 Uhr, schrieb Matt Johnston : > Ah right. Is the server-side sshd/dropbear process still > running? I guess something hasn't noticed that the client > has gone away, though I'm not really sure what you can do. Hm, are you implicitly suggesting that SO_REUSEADDR woudn't help at all? > Is the embedded device sending icmp port unreachable (or > similar?) packets out, or does it just silently drop the > stale connection's packets? Well, to just address another point of view: I have never had problems in a test phase, where I used two linux desktops or notebooks for experiments with communication via two forwarders to one middleman server. Of course, any kill of running processes yield a proper closing of tcp channels. And I don't brutally switch off my notebook. I didn't try it out (but I will do), what its happening, if I brutally power-off my notebook, and see what happens when I reestablish a connection with the same forwarder. Such power cycling is (of course) the natural thing with embedded systems. When I then connect to another port - no problem. Rob > > Matt > > On Mon, Jul 23, 2012 at 03:10:12PM +0200, Maris, Rob wrote: >> Thanks for instant answering, >> >> I was still aware of SO_REUSEADDR in dbutil.c, but could not quickly >> determine whether this also applies to forwarding channels. In any >> case, reconnect goes OK when the embedded system gets a reboot prior >> to poweroff (as could be expected). >> >> In the problem case, the host netstat shows up >> tcp 0 0 localhost.localdo:51225 localhost.localdo:10526 >> CLOSE_WAIT >> >> BTW: I'm using 0.52 on a blackfin platform. >> >> Regarding strace: Must be prepared. Is not yet built into the root >> file system. I'll return later to it. >> >> Rob >> >> Note: I also noticed >> http://comments.gmane.org/gmane.network.ssh.dropbear/962 >> before, and the suggestions in that thread will probably be realised >> after the current problem has been solved. >> >> >> >> Am 23.07.2012, 14:32 Uhr, schrieb Matt Johnston : >> >> >Hi, >> > >> >Dropbear already does SO_REUSEADDR for all listening >> >sockets, see >> >https://secure.ucc.asn.au/hg/dropbear/file/983a817f8e41/dbutil.c#l254 >> > >> >Can you run strace on dbclient to see what's failing? Does >> >the server log anything? >> > >> >Cheers, >> >Matt >> > >> >On Mon, Jul 23, 2012 at 02:13:05PM +0200, Maris, Rob wrote: >> >>Use case: >> >>- embedded system running dbclient with server connection that >> >>includes a port forwarding. >> >>- system is powered off, and powered on again >> >>- upon next boot, the following message is given: >> >>dbclient: Remote TCP forward request failed (port 10526 -> >> 127.0.0.1:22) >> >> >> >>I'd believe that doing a SO_REUSEADDR via setsockopt() would resolve >> >>this issue. >> >>However, I'm not sure and where to implement this (in cli_tcpfwd.c?) >> >> >> >>Thanks for any suggestions. >> >> >> >>Rob From matt at ucc.asn.au Tue Jul 24 07:55:31 2012 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 24 Jul 2012 07:55:31 +0800 Subject: forwarding problems In-Reply-To: References: <20120723123219.GB16933@ucc.gu.uwa.edu.au> <20120723151632.GC16933@ucc.gu.uwa.edu.au> Message-ID: When you kill a process the OS will close its TCP connections by sending a reset packet to the other side. If the whole machine turns off those packets can't be sent. After it reboots, the OS should reject packets from the stale connections and reset them then. But that'll only happen when data or a TCP keepalive is transferred (I think). Matt "Maris, Rob" wrote: >Am 23.07.2012, 17:16 Uhr, schrieb Matt Johnston : > >> Ah right. Is the server-side sshd/dropbear process still >> running? I guess something hasn't noticed that the client >> has gone away, though I'm not really sure what you can do. > >Hm, are you implicitly suggesting that SO_REUSEADDR woudn't help at >all? > >> Is the embedded device sending icmp port unreachable (or >> similar?) packets out, or does it just silently drop the >> stale connection's packets? > >Well, to just address another point of view: I have never had problems >in >a test phase, where I used two linux desktops or notebooks for >experiments >with communication via two forwarders to one middleman server. Of >course, >any kill of running processes yield a proper closing of tcp channels. >And >I don't brutally switch off my notebook. I didn't try it out (but I >will >do), what its happening, if I brutally power-off my notebook, and see >what >happens when I reestablish a connection with the same forwarder. > >Such power cycling is (of course) the natural thing with embedded >systems. >When I then connect to another port - no problem. > >Rob > >> >> Matt >> >> On Mon, Jul 23, 2012 at 03:10:12PM +0200, Maris, Rob wrote: >>> Thanks for instant answering, >>> >>> I was still aware of SO_REUSEADDR in dbutil.c, but could not quickly >>> determine whether this also applies to forwarding channels. In any >>> case, reconnect goes OK when the embedded system gets a reboot prior >>> to poweroff (as could be expected). >>> >>> In the problem case, the host netstat shows up >>> tcp 0 0 localhost.localdo:51225 localhost.localdo:10526 >>> CLOSE_WAIT >>> >>> BTW: I'm using 0.52 on a blackfin platform. >>> >>> Regarding strace: Must be prepared. Is not yet built into the root >>> file system. I'll return later to it. >>> >>> Rob >>> >>> Note: I also noticed >>> http://comments.gmane.org/gmane.network.ssh.dropbear/962 >>> before, and the suggestions in that thread will probably be realised >>> after the current problem has been solved. >>> >>> >>> >>> Am 23.07.2012, 14:32 Uhr, schrieb Matt Johnston : >>> >>> >Hi, >>> > >>> >Dropbear already does SO_REUSEADDR for all listening >>> >sockets, see >>> >>https://secure.ucc.asn.au/hg/dropbear/file/983a817f8e41/dbutil.c#l254 >>> > >>> >Can you run strace on dbclient to see what's failing? Does >>> >the server log anything? >>> > >>> >Cheers, >>> >Matt >>> > >>> >On Mon, Jul 23, 2012 at 02:13:05PM +0200, Maris, Rob wrote: >>> >>Use case: >>> >>- embedded system running dbclient with server connection that >>> >>includes a port forwarding. >>> >>- system is powered off, and powered on again >>> >>- upon next boot, the following message is given: >>> >>dbclient: Remote TCP forward request failed (port 10526 -> >>> 127.0.0.1:22) >>> >> >>> >>I'd believe that doing a SO_REUSEADDR via setsockopt() would >resolve >>> >>this issue. >>> >>However, I'm not sure and where to implement this (in >cli_tcpfwd.c?) >>> >> >>> >>Thanks for any suggestions. >>> >> >>> >>Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20120724/43b044a4/attachment.htm From maris.rob at ingenieur.de Tue Jul 24 16:16:36 2012 From: maris.rob at ingenieur.de (Maris, Rob) Date: Tue, 24 Jul 2012 10:16:36 +0200 Subject: forwarding problems In-Reply-To: References: <20120723123219.GB16933@ucc.gu.uwa.edu.au> <20120723151632.GC16933@ucc.gu.uwa.edu.au> Message-ID: Am 24.07.2012, 01:55 Uhr, schrieb Matt Johnston : > When you kill a process the OS will close its TCP connections by sending > a reset packet to the other side. If the whole machine turns off those > packets can't be sent. > > After it reboots, the OS should reject packets from the stale > connections and reset them then. But that'll only happen when data or a > TCP keepalive is transferred (I think). Thanks for this hint. Using information from http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html and its next page, I drastically reduced keepalive constants in my vserver, and the problem has been solved. Next step is testing dbclient's -K option and see whether port forwarding is re-connected when the server dies and restarts. I'll let you know if this works (eventually with patch as proposed in http://comments.gmane.org/gmane.network.ssh.dropbear/962 ), prior to using extra resources (autossh). I'll let you know. Rob From freddie_chopin at op.pl Tue Jul 31 19:07:54 2012 From: freddie_chopin at op.pl (Freddie Chopin) Date: Tue, 31 Jul 2012 11:07:54 +0000 (UTC) Subject: Dropbear on bare-metal ARM Cortex-M3? Message-ID: Hi! I was wondering whether it's possible (in a reasonable amount of time) to port Dropbear to bare-metal platform - one without an OS (like Linux), but with RTOS (FreeRTOS) that provides tasks, queues and synchronization (semaphores + mutexes) + LwIP TCP/IP stack? I would require a very minimal implementation of SSH server, without all possible encryption options (the code/RAM footprint has to be low) and without all possible features - ideally only simpliest SSH server that can pass received strings to other parts of code and transfer strings from code via SSH to connected client. Of course I'm talking only about command-line interface. If Dropbear is not a good option for such task, do you have any other recommendations? Thx in advance for your help! 4\/3!! FCh From fja0568 at gmail.com Fri Aug 17 04:37:13 2012 From: fja0568 at gmail.com (Farrell Aultman) Date: Thu, 16 Aug 2012 16:37:13 -0400 Subject: Dropbear on bare-metal ARM Cortex-M3? In-Reply-To: References: Message-ID: Freddie, I wouldn't waste my time with it. You'll have to find or write a POSIX layer. Also, dropbear makes liberal use of dynamic memory and without an MMU you'll run into memory fragmentation. In addition, you'll likely suffer from terrible performance on the M3 if you can even get it small enough to fit into flash and run within the confines of your RAM. In short, I recommend picking a processor with a MMU and run Linux. Another option is to use a COTS like Mocana. But that can be expensive. Farrell On Tue, Jul 31, 2012 at 7:07 AM, Freddie Chopin wrote: > Hi! > > I was wondering whether it's possible (in a reasonable amount of time) to port > Dropbear to bare-metal platform - one without an OS (like Linux), but with RTOS > (FreeRTOS) that provides tasks, queues and synchronization (semaphores + > mutexes) + LwIP TCP/IP stack? > > I would require a very minimal implementation of SSH server, without all > possible encryption options (the code/RAM footprint has to be low) and without > all possible features - ideally only simpliest SSH server that can pass received > strings to other parts of code and transfer strings from code via SSH to > connected client. Of course I'm talking only about command-line interface. > > If Dropbear is not a good option for such task, do you have any other > recommendations? > > Thx in advance for your help! > > 4\/3!! > > FCh > From grant.b.edwards at gmail.com Fri Aug 17 05:33:58 2012 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Thu, 16 Aug 2012 21:33:58 +0000 (UTC) Subject: Dropbear on bare-metal ARM Cortex-M3? References: Message-ID: On 2012-07-31, Freddie Chopin wrote: > I was wondering whether it's possible (in a reasonable amount of time) to port > Dropbear to bare-metal platform - one without an OS (like Linux), but with RTOS > (FreeRTOS) that provides tasks, queues and synchronization (semaphores + > mutexes) + LwIP TCP/IP stack? > > I would require a very minimal implementation of SSH server, without all > possible encryption options (the code/RAM footprint has to be low) and without > all possible features - ideally only simpliest SSH server that can pass received > strings to other parts of code and transfer strings from code via SSH to > connected client. Of course I'm talking only about command-line interface. > > If Dropbear is not a good option for such task, do you have any other > recommendations? I've used (non-free) SSL/SSH libraries from Peersec on a platform similar to what you're describing (using an RTOS different than, but similar to, FreeRTS). I haven't looked at dropbear source code in any detail, but I can tell you that porting network servers written to run on a Unix OS to an RTOS environment can be _very_ difficult. The two main problems are that the servers generally expect to be able to 1) Call fork() to create a server process for each incoming connection. 2) Call exit() after a connection is closed with the assumption that all the resources that were allocated will be auto-magically "freed". Coming up with fixes/work-arounds for those two issues alone can be a huge amount of work. -- Grant Edwards grant.b.edwards Yow! Used staples are good at with SOY SAUCE! gmail.com From lb at tx.technion.ac.il Mon Aug 27 23:05:35 2012 From: lb at tx.technion.ac.il (Leonid Bloch) Date: Mon, 27 Aug 2012 18:05:35 +0300 Subject: DropBear on Android Message-ID: Hello, Has anyone successfully compiled and tested the latest Dropbear on Android? If so, can you please share your modifications? After few changes that seemed reasonable to me, I still get various error messages, and nothing works: I've tried logging in with a random user, as well as the user that belongs to my terminal emulator app, then the error of the server was: "Login attempt for nonexistent user from " When I patched further, in the spirit of what is written here: http://roycormier.net/2010/11/02/cross-compiling-dropbear-sshd-for-android I got something about "shell is missing for the user " When tried to run dbclient, the error was: "dbclient: Exited: Unknown own user" The error in scp was: "unknown user 10118" I'd appreciate any ideas or instructions. Best regards, Leonid. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20120827/d51209ea/attachment.htm From matt at ucc.asn.au Mon Aug 27 23:13:06 2012 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 27 Aug 2012 23:13:06 +0800 Subject: DropBear on Android In-Reply-To: References: Message-ID: <20120827151306.GY25598@ucc.gu.uwa.edu.au> Hi, There are a few patches at http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2012q1/001251.html I'll probably incorporate those into the next release. Modifications to QuickSSHD's Dropbear are at https://github.com/barryk/android_external_dropbear , or see http://teslacoilsw.com/dropbear I can't think of much relevant that would have changed in Dropbear since QuickSSHD's 0.52. You could see if building that works on your system? Cheers, Matt On Mon, Aug 27, 2012 at 06:05:35PM +0300, Leonid Bloch wrote: > Hello, > > Has anyone successfully compiled and tested the latest Dropbear on Android? > If so, can you please share your modifications? > > After few changes that seemed reasonable to me, I still get various error > messages, and nothing works: > I've tried logging in with a random user, as well as the user that belongs > to my terminal emulator app, then the error of the server was: > "Login attempt for nonexistent user from " > When I patched further, in the spirit of what is written here: > http://roycormier.net/2010/11/02/cross-compiling-dropbear-sshd-for-android > I got something about "shell is missing for the user " > > When tried to run dbclient, the error was: > "dbclient: Exited: Unknown own user" > > The error in scp was: > "unknown user 10118" > > I'd appreciate any ideas or instructions. > > > Best regards, > Leonid. From Reimar.Doeffinger at gmx.de Mon Aug 27 23:51:30 2012 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Mon, 27 Aug 2012 17:51:30 +0200 Subject: DropBear on Android In-Reply-To: <20120827151306.GY25598@ucc.gu.uwa.edu.au> References: <20120827151306.GY25598@ucc.gu.uwa.edu.au> Message-ID: <20120827155130.GA6175@1und1.de> On Mon, Aug 27, 2012 at 11:13:06PM +0800, Matt Johnston wrote: > Hi, > > There are a few patches at > http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2012q1/001251.html > I'll probably incorporate those into the next release. They worked for me to get something usable, but I only every tried the server side. The "shell is missing thing" is what I mentioned under 4) there. The problem with Android is loads of half-assed stub functions that are not well-implemented enough to actually make anything work while at the same time making everything compiles as if there was no issue. From tobias.dussa at kit.edu Thu Aug 30 18:39:50 2012 From: tobias.dussa at kit.edu (Tobias Dussa (SCC)) Date: Thu, 30 Aug 2012 12:39:50 +0200 Subject: How to read from stdin with dbclient Message-ID: <20120830103947.GA22640@kit.edu> Hi, I'm trying to ship something to a script on a remote machine via SSH and catch its output. As an example, let's say that user foo on machine bar has "cat" defined as her shell. Thus, after connecting to bar as foo, anything that is sent to bar is sent back. Theoretically, piping something into the ssh command should result in that something being thrown back. This does indeed work as expected when using openssh's ssh client, like this: echo baz | ssh -qi IDENTITY foo at bar Trying the same with dbclient yields "Failed reading termmodes" for this command: echo baz | dbclient -i DB_IDENTITY foo at bar This points to the fact that no pty is available, which is correct, of course, and can be prevented by using the -T switch, which tells dbclient not to allocate a pty: echo baz | dbclient -T -i DB_IDENTITIY foo at bar However, this is where things go wrong. The "baz" string does still indeed arrive at the remote server and is processed by foo's shell, but is not printed by dbclient. This is unfortunate as I really need to capture the output. So, the obvious question is, how can I get to the output? THX & Cheers, Toby. -- E Pluribus Unix ---- Karlsruhe Institute of Technology (KIT) Steinbuch Centre for Computing (SCC) KIT-CERT Tobias Dussa CERT Manager, CA Manager Zirkel 2 Building 20.21 76131 Karlsruhe, Germany Phone: +49 721 608-42479 Fax: +49 721 608-9-42479 Email: tobias.dussa at kit.edu Web: http://www.kit.edu/ KIT ? University of the State of Baden-Wuerttemberg and National Laboratory of the Helmholtz Association -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5500 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20120830/5e713e26/attachment.bin From lb at tx.technion.ac.il Thu Sep 13 02:15:53 2012 From: lb at tx.technion.ac.il (lb at tx.technion.ac.il) Date: Wed, 12 Sep 2012 21:15:53 +0300 Subject: Dropbear client & server errors on Android Message-ID: <1347473753.5050d15943402@webmail.technion.ac.il> Hi, I successfully compiled the Dropbear client for Android, but when I try to connect to an address it gives me the following error: "Exited: Error resolving '' port ''. Name or service not known" When I try to connect using IP address - all works fine. Is there any way to make Dropbear use some external nameserver, like 8.8.8.8? Or any other solution you can think of? As for the server: I fiddled with it a lot, applied different patches, overcame numerous error messages, but the message I can't overcome now is: "Exit before auth (user '', 0 fails): Exited normally" What can be the problem at this stage? (I'm using pubkey auth) Thanks a lot, Leonid. From chinnaobi at gmail.com Tue Sep 25 16:39:26 2012 From: chinnaobi at gmail.com (chinna obireddy) Date: Tue, 25 Sep 2012 16:39:26 +0800 Subject: Dropbear calling my own command-line parser than /bin/sh Message-ID: Dear All, As per the thread http://thread.gmane.org/gmane.network.ssh.dropbear/68/focus=75 I was successfully made changes to launch CLI application with dropbear ssh. But Putty(SSH client) is still asking for Login name, though this is not going to be used It looks weird for user asking user name twice. Since the CLI application has it's own authentication method. Suggest me how can I completely ignore Authentication packets in the server side. --Reddy. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20120925/a9c56f7f/attachment.htm From matt at ucc.asn.au Tue Sep 25 20:49:14 2012 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 25 Sep 2012 20:49:14 +0800 Subject: Dropbear calling my own command-line parser than /bin/sh In-Reply-To: References: Message-ID: <20120925124914.GE24976@ucc.gu.uwa.edu.au> Hi, Take a look at https://secure.ucc.asn.au/hg/dropbear/rev/0edf08895a33 - it sends "success" for the first auth request. Matt On Tue, Sep 25, 2012 at 04:39:26PM +0800, chinna obireddy wrote: > Dear All, > > As per the thread > http://thread.gmane.org/gmane.network.ssh.dropbear/68/focus=75 I was > successfully made changes to launch CLI application with dropbear ssh. > > But Putty(SSH client) is still asking for Login name, though this is not > going to be used It looks weird for user asking user name twice. Since the > CLI application has it's own authentication method. > > Suggest me how can I completely ignore Authentication packets in the server > side. > > --Reddy. From chinnaobi at gmail.com Wed Sep 26 09:51:55 2012 From: chinnaobi at gmail.com (chinna obireddy) Date: Wed, 26 Sep 2012 09:51:55 +0800 Subject: Dropbear calling my own command-line parser than /bin/sh In-Reply-To: <20120925124914.GE24976@ucc.gu.uwa.edu.au> References: <20120925124914.GE24976@ucc.gu.uwa.edu.au> Message-ID: Hey Matt, I was able to make it work for any username login return authentication success. But the problem is that Putty(Windows) asks for user name, though any username will do actually. I don't want the ssh client ask the user to enter username at all. How could I achieve that ?? SSH client: Login as: press enter -- shouldn't prompt at all username:xxx(CLI auth) password:xxx(CLI auth) Reddy On Tue, Sep 25, 2012 at 8:49 PM, Matt Johnston wrote: > Hi, > > Take a look at > https://secure.ucc.asn.au/hg/dropbear/rev/0edf08895a33 - it > sends "success" for the first auth request. > > Matt > > On Tue, Sep 25, 2012 at 04:39:26PM +0800, chinna obireddy wrote: > > Dear All, > > > > As per the thread > > http://thread.gmane.org/gmane.network.ssh.dropbear/68/focus=75 I was > > successfully made changes to launch CLI application with dropbear ssh. > > > > But Putty(SSH client) is still asking for Login name, though this is not > > going to be used It looks weird for user asking user name twice. Since > the > > CLI application has it's own authentication method. > > > > Suggest me how can I completely ignore Authentication packets in the > server > > side. > > > > --Reddy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20120926/0a310cfe/attachment.htm From matt at ucc.asn.au Wed Sep 26 20:27:23 2012 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 26 Sep 2012 20:27:23 +0800 Subject: Dropbear calling my own command-line parser than /bin/sh In-Reply-To: References: <20120925124914.GE24976@ucc.gu.uwa.edu.au> Message-ID: <20120926122723.GG24976@ucc.gu.uwa.edu.au> Hi, I don't think you can avoid it - the best you can do is to put "something at 192.168.14.1" in the host field so it'll send a username without prompting. The SSH protocol requires a username in all authentication requests, so PuTTY assumes it's going to be necessary. Cheers, Matt On Wed, Sep 26, 2012 at 09:51:55AM +0800, chinna obireddy wrote: > Hey Matt, > > I was able to make it work for any username login return authentication > success. But the problem is that Putty(Windows) asks for user name, though > any username will do actually. I don't want the ssh client ask the user to > enter username at all. How could I achieve that ?? > > SSH client: > > Login as: press enter -- shouldn't prompt at all > username:xxx(CLI auth) > password:xxx(CLI auth) > > Reddy > > On Tue, Sep 25, 2012 at 8:49 PM, Matt Johnston wrote: > > > Hi, > > > > Take a look at > > https://secure.ucc.asn.au/hg/dropbear/rev/0edf08895a33 - it > > sends "success" for the first auth request. > > > > Matt > > > > On Tue, Sep 25, 2012 at 04:39:26PM +0800, chinna obireddy wrote: > > > Dear All, > > > > > > As per the thread > > > http://thread.gmane.org/gmane.network.ssh.dropbear/68/focus=75 I was > > > successfully made changes to launch CLI application with dropbear ssh. > > > > > > But Putty(SSH client) is still asking for Login name, though this is not > > > going to be used It looks weird for user asking user name twice. Since > > the > > > CLI application has it's own authentication method. > > > > > > Suggest me how can I completely ignore Authentication packets in the > > server > > > side. > > > > > > --Reddy. > > From chinnaobi at gmail.com Thu Sep 27 00:48:24 2012 From: chinnaobi at gmail.com (chinna obireddy) Date: Thu, 27 Sep 2012 00:48:24 +0800 Subject: Dropbear calling my own command-line parser than /bin/sh In-Reply-To: <20120926122723.GG24976@ucc.gu.uwa.edu.au> References: <20120925124914.GE24976@ucc.gu.uwa.edu.au> <20120926122723.GG24976@ucc.gu.uwa.edu.au> Message-ID: Hey Matt, I got an Idea to avoid this may be I can read the same username and pass this username as an option to CLI when login. I created another username called cliusername in authstate struct and I am trying to access it in session_command function, svr-chansession.c. Any inputs how to do this ?? Thank you for your support. Reddy. On Wed, Sep 26, 2012 at 8:27 PM, Matt Johnston wrote: > Hi, > > I don't think you can avoid it - the best you can do is to > put "something at 192.168.14.1" in the host field so it'll send > a username without prompting. > > The SSH protocol requires a username in all authentication > requests, so PuTTY assumes it's going to be necessary. > > Cheers, > Matt > > On Wed, Sep 26, 2012 at 09:51:55AM +0800, chinna obireddy wrote: > > Hey Matt, > > > > I was able to make it work for any username login return authentication > > success. But the problem is that Putty(Windows) asks for user name, > though > > any username will do actually. I don't want the ssh client ask the user > to > > enter username at all. How could I achieve that ?? > > > > SSH client: > > > > Login as: press enter -- shouldn't prompt at all > > username:xxx(CLI auth) > > password:xxx(CLI auth) > > > > Reddy > > > > On Tue, Sep 25, 2012 at 8:49 PM, Matt Johnston wrote: > > > > > Hi, > > > > > > Take a look at > > > https://secure.ucc.asn.au/hg/dropbear/rev/0edf08895a33 - it > > > sends "success" for the first auth request. > > > > > > Matt > > > > > > On Tue, Sep 25, 2012 at 04:39:26PM +0800, chinna obireddy wrote: > > > > Dear All, > > > > > > > > As per the thread > > > > http://thread.gmane.org/gmane.network.ssh.dropbear/68/focus=75 I was > > > > successfully made changes to launch CLI application with dropbear > ssh. > > > > > > > > But Putty(SSH client) is still asking for Login name, though this is > not > > > > going to be used It looks weird for user asking user name twice. > Since > > > the > > > > CLI application has it's own authentication method. > > > > > > > > Suggest me how can I completely ignore Authentication packets in the > > > server > > > > side. > > > > > > > > --Reddy. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20120927/31cc2169/attachment.htm