From zbeckerman at yahoo.com Tue Jan 4 02:24:22 2011 From: zbeckerman at yahoo.com (Zev Beckerman) Date: Mon, 3 Jan 2011 10:24:22 -0800 (PST) Subject: Dropbear - Cygwin - Windows Vista Message-ID: <924254.805.qm@web33405.mail.mud.yahoo.com> The supported version of Cygwin ran with Windows XP. I am trying to run it under Windows Vista with UAC turned off. I successfully compiled under Cygwin (1.7.7), set up the keys and can start the server and client. But i cannot authenticate. Any suggestions? This is what I did. ./configure make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert" ./dropbearkey -t rsa -f dropbear_rsa_host_key ./dropbearkey -t dss -f dropbear_dss_host_key mdkir /home/testuser mkpasswd > /etc/passwd --check to make sure the shell exists that was created in /etc/password for user --start server ./dropbear.exe -E -r dropbear_rsa_host_key -d dropbear_dss_host_key open second Cygin and connect with dbclient ./dbclient testuser at 192.168.1.4 ? --result from client [3904] Jan 03 13:20:53 bad password attempt for 'testuser' from 192.168.1.4:5411 7 ? ? I was under the impression that the mkpasswd linked dropbear users to the Windows account users. The testuser is an Aministrator user. I am using my windows password for that user. Any suggestions please? /Z From zbeckerman at yahoo.com Tue Jan 4 02:26:11 2011 From: zbeckerman at yahoo.com (Zev Beckerman) Date: Mon, 3 Jan 2011 10:26:11 -0800 (PST) Subject: Stand-alone 32 and 64 bit versions Message-ID: <870876.60492.qm@web33404.mail.mud.yahoo.com> If I compiled dropbear (via cygwin) on windows 32 can it be run outside of cygwin as a standalone? What actions need to be completed to so this what users will be valid? Does the same hold true if I compile it on cygwin under a 64 bit machine? Thanks, /Z From redhatter at gentoo.org Tue Jan 4 05:50:55 2011 From: redhatter at gentoo.org (Stuart Longland) Date: Tue, 4 Jan 2011 07:50:55 +1000 Subject: Stand-alone 32 and 64 bit versions In-Reply-To: <870876.60492.qm@web33404.mail.mud.yahoo.com> References: <870876.60492.qm@web33404.mail.mud.yahoo.com> Message-ID: <20110103215055.GD27936@atomos.longlandclan.yi.org> I rarely use Windows (I emigrated from that world over to the Free/Libre software world a long time ago, and only travel back occasionally on business), so take what I say with a grain of salt. ;-) On Mon, Jan 03, 2011 at 10:26:11AM -0800, Zev Beckerman wrote: > If I compiled dropbear (via cygwin) on windows 32 can it be run outside of > cygwin as a standalone? What actions need to be completed to so this what users > will be valid? Does the same hold true if I compile it on cygwin under a 64 bit > machine? My understanding is that anything compiled against Cygwin (i.e. links against Cygwin's DLLs) will require amongst other things, that the Cygwin DLLs are present with the application binary. Cygwin's shell works by starting bash via a batch script. I'd use that as a starting point for your server start script. If need be, modify it to start a shell script which can mirror what a typical Dropbear init script would do on Linux. To be completely free of Cygwin, I'd consider mingw32 or Services for Unix. A caveat here though is that most clients will expect to find a real Unix-like system at the other end of the SSH link. Microsoft, for better or worse decided to do things their own way when it came to Windows, and hence any Unix-like environment idiosyncratic as a result. I wish you luck, I find that platform from Redmond downright hostile when it comes to porting software from a Unix environment. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' I haven't lost my mind... ...it's backed up on a tape somewhere. From michael.wiedmann at aastra.com Tue Jan 11 17:32:24 2011 From: michael.wiedmann at aastra.com (Michael Wiedmann) Date: Tue, 11 Jan 2011 10:32:24 +0100 Subject: Transfer of larges files fails on forwarded ports Message-ID: Given the following scenario (simplified, port no. examples only, omitted auth): User embedded system port 5000 -L ... port 50000 -R ... port 80 ssh client <----------> SSH Server <----------> ssh client (plink/Win) (dropbear/cygwin) (dbclient) Workflow is like: - ssh client on right side (embedded system) initiates ssh session to dropbear ssh server requesting _remote_ port forwarding - ssh client on left side (PC) initiates ssh session to the same dropbear ssh server requesting _local_ port forwarding - User on the left side can point his web browser to localhost:5000 and reaches via ssh tunnel and the forwarded ports the web server on the embedded device (port 80) - this works so far for "simple" web pages: User can browse configuration pages on the embedded device, make changes, etc. BUT if we try to transfer a "large" file via HTTP upload over the tunnel/forwarded port the transfer fails at same point (around 500 kB, varying). If we do the same using only one ssh connection (between server and embedded system) and try to transfer the same large file (using server:50000) everything seems to work (at least we didn't notice any failure on several tries). We suspect a socket read/write error but not even can see a real failure message in the log file (we enabled dropbear TRACE). Any hints how to further localize the observed error? Thanks Michael From roberto.foglietta at gmail.com Tue Jan 11 18:14:06 2011 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Tue, 11 Jan 2011 11:14:06 +0100 Subject: Transfer of larges files fails on forwarded ports In-Reply-To: References: Message-ID: 2011/1/11 Michael Wiedmann : > Given the following scenario (simplified, port no. examples only, > omitted auth): > > User ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?embedded system > port 5000 ? ? -L ... ? ?port 50000 ? ?-R ... ? ?port 80 > ssh client <----------> SSH Server <----------> ssh client > (plink/Win) ? ? ? ? ?(dropbear/cygwin) ? ? ? ? ?(dbclient) > > Workflow is like: > > - ssh client on right side (embedded system) initiates ssh session to > ?dropbear ssh server requesting _remote_ port forwarding > - ssh client on left side (PC) initiates ssh session to the same > ?dropbear ssh server requesting _local_ port forwarding > > - User on the left side can point his web browser to localhost:5000 > ?and reaches via ssh tunnel and the forwarded ports the web server > ?on the embedded device (port 80) > > - this works so far for "simple" web pages: > ?User can browse configuration pages on the embedded device, > ?make changes, etc. > > BUT > > if we try to transfer a "large" file via HTTP upload over the > tunnel/forwarded port > the transfer fails at same point (around 500 kB, varying). > Packet size could vary then overhead/data size too. Could it be 512Kb (fixed size) included TCP/IP protocol overhead? Cheers, -- Roberto A. Foglietta, From anton at pavlenko.net Fri Feb 11 19:42:51 2011 From: anton at pavlenko.net (Anton Pavlenko) Date: Fri, 11 Feb 2011 14:42:51 +0300 Subject: dbclient from crontab? Message-ID: Hello. It looks like I have the same problem as it was described in mail "How to redirect the output of an command executed with dbclient on a remote server? " more than half a year ago. I have a some scripts, which automate different tasks using dbclient with DROPBEAR_PASSWORD feature. Thanks a lot for this! And now I'd like to move one of this script's to cron. But I doesn't work. It looks like problem not with stdout redirection, but with tty control it self. I have tried -t option and dbclient return this error: /path/dropbear-0.52/dbclient: Failed reading termmodes With regards, Antony Pavlenko From matt at ucc.asn.au Sat Feb 12 11:01:45 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 12 Feb 2011 11:01:45 +0800 Subject: dbclient from crontab? In-Reply-To: References: Message-ID: <20110212030145.GJ8454@ucc.gu.uwa.edu.au> Hi, -t won't work without a terminal, so that makes sense. If you redirect input of the command as: DROPBEAR_PASSWORD=hello1234 dbclient hostname command < /dev/zero Does that work? It's a bit of a hack workaround, I need to figure what's going on properly. Cheers, Matt On Fri, Feb 11, 2011 at 02:42:51PM +0300, Anton Pavlenko wrote: > Hello. > It looks like I have the same problem as it was described in mail "How > to redirect the output of an command executed with dbclient on a > remote server? " more than half a year ago. > I have a some scripts, which automate different tasks using dbclient > with DROPBEAR_PASSWORD feature. Thanks a lot for this! > And now I'd like to move one of this script's to cron. > But I doesn't work. > It looks like problem not with stdout redirection, but with tty control it self. > I have tried -t option and dbclient return this error: > > /path/dropbear-0.52/dbclient: Failed reading termmodes > > With regards, > Antony Pavlenko > From anton at pavlenko.net Mon Feb 14 14:33:08 2011 From: anton at pavlenko.net (Anton Pavlenko) Date: Mon, 14 Feb 2011 09:33:08 +0300 Subject: dbclient from crontab? In-Reply-To: <20110212030145.GJ8454@ucc.gu.uwa.edu.au> References: <20110212030145.GJ8454@ucc.gu.uwa.edu.au> Message-ID: Hello, Thanks a lot for this idea. /dev/zero doesn't work, but /dev/ptmx work great at Linux and Solaris. With regards, Antony Pavlenko On Sat, Feb 12, 2011 at 6:01 AM, Matt Johnston wrote: > Hi, > > -t won't work without a terminal, so that makes sense. If > you redirect input of the command as: > > DROPBEAR_PASSWORD=hello1234 dbclient hostname command < /dev/zero > > Does that work? It's a bit of a hack workaround, I need to > figure what's going on properly. > > Cheers, > Matt > > On Fri, Feb 11, 2011 at 02:42:51PM +0300, Anton Pavlenko wrote: > > Hello. > > It looks like I have the same problem as it was described in mail "How > > to redirect the output of an command executed with dbclient on a > > remote server? " more than half a year ago. > > I have a some scripts, which automate different tasks using dbclient > > with DROPBEAR_PASSWORD feature. Thanks a lot for this! > > And now I'd like to move one of this script's to cron. > > But I doesn't work. > > It looks like problem not with stdout redirection, but with tty control > it self. > > I have tried -t option and dbclient return this error: > > > > /path/dropbear-0.52/dbclient: Failed reading termmodes > > > > With regards, > > Antony Pavlenko > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20110214/9b85023c/attachment.htm From matt at ucc.asn.au Thu Feb 24 22:37:02 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 24 Feb 2011 22:37:02 +0800 Subject: Dropbear 0.53 Message-ID: <20110224143702.GQ24077@ucc.gu.uwa.edu.au> Hi all, After much too long a delay Dropbear 0.53 is now released. Tarballs are located at http://matt.ucc.asn.au/dropbear/ as usual, changes are as listed below. Cheers, Matt 0.53 - Thurs 24 February 2011 - Various performance/memory use improvements - Client agent forwarding now works, using OpenSSH's ssh-agent - Improve robustness of client multihop mode - Fix a prime generation bug in bundled libtommath. This is unlikely to have generated any bad keys in the wild. See https://bugzilla.redhat.com/show_bug.cgi?id=615088 http://bugs.gentoo.org/show_bug.cgi?id=328383 http://bugs.gentoo.org/show_bug.cgi?id=328409 - Attempt to build against system libtomcrypt/libtommath if available. This can be disabled with ./configure --enable-bundled-libtom - Make -K (keepalive) and -I (idle timeout) work together sensibly in the client. The idle timeout is no longer reset by SSH_MSG_IGNORE packets. - Compile fix if ENABLE_CLI_PROXYCMD is disabled - /usr/bin/X11/xauth is now the default path - Client remote forward (-L/-R) arguments now accept a listen address - In uClinux avoid trashing the parent process when a session exits - Blowfish is now disabled by default since it has large memory usage - Add option to change zlib windowbits/memlevel. Use less memory by default - DROPBEAR_SMALL_CODE is now disabled by default - SSH_ORIGINAL_COMMAND environment variable is set by the server when an authorized_keys command is specified. - Set SSH_TTY and SSH_CONNECTION environment variables in the server - Client banner is now printed to standard error rather than standard output - Capitalisation in many log messages has been made consistent. This may affect scripts that parse logfiles. 0.52 - Wed 12 November 2008 ... From rob at landley.net Fri Feb 25 14:13:24 2011 From: rob at landley.net (Rob Landley) Date: Fri, 25 Feb 2011 00:13:24 -0600 Subject: Dropbear 0.53 In-Reply-To: <20110224143702.GQ24077@ucc.gu.uwa.edu.au> References: <20110224143702.GQ24077@ucc.gu.uwa.edu.au> Message-ID: <4D674884.2060204@landley.net> On 02/24/2011 08:37 AM, Matt Johnston wrote: > Hi all, > > After much too long a delay Dropbear 0.53 is now released. > Tarballs are located at http://matt.ucc.asn.au/dropbear/ as usual, > changes are as listed below. You broke the build with static linking. Now the build says -lcrypt at the begining of the link line instead of the end like all the other libraries, and with --static that links in lcrypt.a instead of libcrypt.so which is position dependent, and since the first reference to crypt() is in one of the .o files after that the build dies with: svr-authpasswd.o: In function `svr_auth_password': svr-authpasswd.c:(.text+0x90): undefined reference to `crypt' Because libcrypt.a went by without crypt() being copied out of it. Rob From matt at ucc.asn.au Fri Feb 25 19:53:01 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 25 Feb 2011 19:53:01 +0800 Subject: Dropbear 0.53 In-Reply-To: <4D674884.2060204@landley.net> References: <20110224143702.GQ24077@ucc.gu.uwa.edu.au> <4D674884.2060204@landley.net> Message-ID: <20110225115301.GU24077@ucc.gu.uwa.edu.au> On Fri, Feb 25, 2011 at 12:13:24AM -0600, Rob Landley wrote: > On 02/24/2011 08:37 AM, Matt Johnston wrote: > > Hi all, > > > > After much too long a delay Dropbear 0.53 is now released. > > Tarballs are located at http://matt.ucc.asn.au/dropbear/ as usual, > > changes are as listed below. > > You broke the build with static linking. Urgh sorry about that. I'll put up 0.53.1 in a couple of days. If anyone notices other problems please let me know. Cheers, Matt From matt at ucc.asn.au Wed Mar 2 21:53:31 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 2 Mar 2011 21:53:31 +0800 Subject: Dropbear 0.53.1 Message-ID: <20110302135331.GF24077@ucc.gu.uwa.edu.au> Hi, I've put up Dropbear 0.53.1 which fixes a few problems with 0.53. These are mostly compile fixes so if 0.53 worked for you then it's not worth changing. The exception is the zlib memLevel option - it seems that buffers don't get flushed properly so I've removed it. As usual the webpage is http://matt.ucc.asn.au/dropbear/dropbear.html Matt 0.53.1 - Wednesday 2 March 2011 - -lcrypt needs to be before object files for static linking - Compile fix when both client and agent forwarding are disabled - Fix DROPBEAR_PRNGD_SOCKET mode - Don't allow setting zlib memLevel since it seems buggy 0.53 - Thurs 24 February 2011 ... - Add diffie-hellman-group14-sha1 key exchange method (missed this in the original 0.53 changelog) From vapier at gentoo.org Fri Mar 4 16:20:51 2011 From: vapier at gentoo.org (Mike Frysinger) Date: Fri, 4 Mar 2011 03:20:51 -0500 Subject: Dropbear 0.53.1 In-Reply-To: <20110302135331.GF24077@ucc.gu.uwa.edu.au> References: <20110302135331.GF24077@ucc.gu.uwa.edu.au> Message-ID: <201103040320.54132.vapier@gentoo.org> On Wednesday, March 02, 2011 08:53:31 Matt Johnston wrote: > 0.53.1 - Wednesday 2 March 2011 > > - -lcrypt needs to be before object files for static linking odd, the changelog says this should be fixed, but the source says it isnt. CRYPTLIB is still at the start of SVROBJS and static/as-needed building fails. any idea what's up ? -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20110304/a95ef4fc/attachment.pgp From rob at landley.net Sat Mar 5 15:07:49 2011 From: rob at landley.net (Rob Landley) Date: Sat, 05 Mar 2011 01:07:49 -0600 Subject: Dropbear 0.53.1 In-Reply-To: <201103040320.54132.vapier@gentoo.org> References: <20110302135331.GF24077@ucc.gu.uwa.edu.au> <201103040320.54132.vapier@gentoo.org> Message-ID: <4D71E145.5060607@landley.net> On 03/04/2011 02:20 AM, Mike Frysinger wrote: > On Wednesday, March 02, 2011 08:53:31 Matt Johnston wrote: >> 0.53.1 - Wednesday 2 March 2011 >> >> - -lcrypt needs to be before object files for static linking > > odd, the changelog says this should be fixed, but the source says it isnt. > CRYPTLIB is still at the start of SVROBJS and static/as-needed building fails. > any idea what's up ? > -mike Er, I have a bad cold that's been screwing up my head for days, but shouldn't the changelog say -lcrypt needs to be _after_ object files for static linking? By the way, is there a repository anywhere we can pull test versions from between releases? Rob From man at lundinova.se Mon Mar 14 18:37:32 2011 From: man at lundinova.se (Magnus Nilsson) Date: Mon, 14 Mar 2011 11:37:32 +0100 Subject: 45s login delay Message-ID: <4D7DEFEC.70602@lundinova.se> Hello, I have an issue with ~45s delay on every login (ssh, scp etc). Once the link is up dropbear runs fine. After reading these forums, I have disabled reverse lookup and added client IP to /etc/hosts, but that didn't help. I'm running dropbear 0.53.1 on armv4tl, uClinux 2.6.19, built largely like this: http://hi.baidu.com/kkernel/blog/item/ff919681141beddebc3e1e23.html but with --disable-shadow This the verbose output: # ./dropbear -a -F -v TRACE (73): enter loadhostkeys TRACE (73): enter buf_get_priv_key TRACE (73): enter rsa_key_free TRACE (73): leave rsa_key_free: key == NULL TRACE (73): enter buf_get_rsa_priv_key TRACE (73): enter buf_get_rsa_pub_key TRACE (73): leave buf_get_rsa_pub_key: success TRACE (73): leave buf_get_rsa_priv_key TRACE (73): leave buf_get_priv_key TRACE (73): enter buf_get_priv_key TRACE (73): enter dsa_key_free TRACE (73): enter dsa_key_free: key == NULL TRACE (73): enter buf_get_dss_pub_key TRACE (73): leave buf_get_dss_pub_key: success TRACE (73): leave buf_get_priv_key TRACE (73): leave loadhostkeys TRACE (73): listensockets: 1 to try TRACE (73): listening on ':22' TRACE (73): enter dropbear_listen TRACE (73): dropbear_listen: all interfaces TRACE (73): bind(22) failed TRACE (73): leave dropbear_listen: success, 1 socks bound [73] Mar 14 17:17:30 Not backgrounding [74] Mar 14 17:17:39 Child connection from 10.240.22.22:1456 TRACE (74): enter session_init TRACE (74): setnonblocking: 3 TRACE (74): leave setnonblocking TRACE (74): setnonblocking: 5 TRACE (74): leave setnonblocking TRACE (74): kexinitialise() TRACE (74): leave session_init TRACE (74): enter ident_readln TRACE (74): leave ident_readln: return 27 TRACE (74): remoteident: SSH-2.0-PuTTY_Release_0.60 TRACE (74): enter encrypt_packet() TRACE (74): encrypt_packet type is 20 TRACE (74): enter writemac TRACE (74): leave writemac TRACE (74): enter enqueue TRACE (74): leave enqueue TRACE (74): leave encrypt_packet() TRACE (74): DATAALLOWED=0 TRACE (74): -> KEXINIT TRACE (74): enter write_packet TRACE (74): empty queue dequeing TRACE (74): leave write_packet TRACE (74): enter read_packet TRACE (74): packet size is 616, block 8 mac 0 TRACE (74): enter decrypt_packet TRACE (74): enter writemac TRACE (74): leave writemac TRACE (74): leave decrypt_packet TRACE (74): leave read_packet TRACE (74): enter process_packet TRACE (74): process_packet: packet type = 20 TRACE (74): <- KEXINIT TRACE (74): enter recv_msg_kexinit TRACE (74): buf_match_algo: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 TRACE (74): kex algo diffie-hellman-group14-sha1 TRACE (74): buf_match_algo: ssh-rsa,ssh-dss TRACE (74): hostkey algo ssh-rsa TRACE (74): buf_match_algo: aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 TRACE (74): enc c2s is aes256-ctr TRACE (74): buf_match_algo: aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 TRACE (74): enc s2c is aes256-ctr TRACE (74): buf_match_algo: hmac-sha1,hmac-sha1-96,hmac-md5 TRACE (74): hash c2s is hmac-sha1 TRACE (74): buf_match_algo: hmac-sha1,hmac-sha1-96,hmac-md5 TRACE (74): hash s2c is hmac-sha1 TRACE (74): buf_match_algo: none,zlib TRACE (74): hash c2s is none TRACE (74): buf_match_algo: none,zlib TRACE (74): hash s2c is none TRACE (74): leave recv_msg_kexinit TRACE (74): leave process_packet TRACE (74): maybe_empty_reply_queue - no data allowed TRACE (74): enter read_packet TRACE (74): packet size is 272, block 8 mac 0 TRACE (74): enter decrypt_packet TRACE (74): enter writemac TRACE (74): leave writemac TRACE (74): leave decrypt_packet TRACE (74): leave read_packet TRACE (74): enter process_packet TRACE (74): process_packet: packet type = 30 TRACE (74): enter recv_msg_kexdh_init TRACE (74): enter send_msg_kexdh_reply TRACE (74): enter send_msg_kexdh_reply <<<45s delay>>> TRACE (74): enter buf_put_pub_key TRACE (74): enter buf_put_rsa_pub_key TRACE (74): enter buf_putmpint I'd be grateful for any ideas and suggestions. Thanks. Kind regards/Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20110314/723cb6fb/attachment.htm From matt at ucc.asn.au Mon Mar 14 19:59:01 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 14 Mar 2011 19:59:01 +0800 Subject: 45s login delay In-Reply-To: <4D7DEFEC.70602@lundinova.se> References: <4D7DEFEC.70602@lundinova.se> Message-ID: Hi, What clock speed is the CPU? It looks a bit like it's just taking a very long time to perform big-number operations. Cheers, Matt Magnus Nilsson wrote: >Hello, > >I have an issue with ~45s delay on every login (ssh, scp etc). Once the > >link is up dropbear runs fine. > >After reading these forums, I have disabled reverse lookup and added >client IP to /etc/hosts, but that didn't help. > >I'm running dropbear 0.53.1 on armv4tl, uClinux 2.6.19, built largely >like this: >http://hi.baidu.com/kkernel/blog/item/ff919681141beddebc3e1e23.html >but with --disable-shadow > >This the verbose output: ># ./dropbear -a -F -v >TRACE (73): enter loadhostkeys >TRACE (73): enter buf_get_priv_key >TRACE (73): enter rsa_key_free >TRACE (73): leave rsa_key_free: key == NULL >TRACE (73): enter buf_get_rsa_priv_key >TRACE (73): enter buf_get_rsa_pub_key >TRACE (73): leave buf_get_rsa_pub_key: success >TRACE (73): leave buf_get_rsa_priv_key >TRACE (73): leave buf_get_priv_key >TRACE (73): enter buf_get_priv_key >TRACE (73): enter dsa_key_free >TRACE (73): enter dsa_key_free: key == NULL >TRACE (73): enter buf_get_dss_pub_key >TRACE (73): leave buf_get_dss_pub_key: success >TRACE (73): leave buf_get_priv_key >TRACE (73): leave loadhostkeys >TRACE (73): listensockets: 1 to try >TRACE (73): listening on ':22' >TRACE (73): enter dropbear_listen >TRACE (73): dropbear_listen: all interfaces >TRACE (73): bind(22) failed >TRACE (73): leave dropbear_listen: success, 1 socks bound >[73] Mar 14 17:17:30 Not backgrounding >[74] Mar 14 17:17:39 Child connection from 10.240.22.22:1456 >TRACE (74): enter session_init >TRACE (74): setnonblocking: 3 >TRACE (74): leave setnonblocking >TRACE (74): setnonblocking: 5 >TRACE (74): leave setnonblocking >TRACE (74): kexinitialise() >TRACE (74): leave session_init >TRACE (74): enter ident_readln >TRACE (74): leave ident_readln: return 27 >TRACE (74): remoteident: SSH-2.0-PuTTY_Release_0.60 >TRACE (74): enter encrypt_packet() >TRACE (74): encrypt_packet type is 20 >TRACE (74): enter writemac >TRACE (74): leave writemac >TRACE (74): enter enqueue >TRACE (74): leave enqueue >TRACE (74): leave encrypt_packet() >TRACE (74): DATAALLOWED=0 >TRACE (74): -> KEXINIT >TRACE (74): enter write_packet >TRACE (74): empty queue dequeing >TRACE (74): leave write_packet >TRACE (74): enter read_packet >TRACE (74): packet size is 616, block 8 mac 0 >TRACE (74): enter decrypt_packet >TRACE (74): enter writemac >TRACE (74): leave writemac >TRACE (74): leave decrypt_packet >TRACE (74): leave read_packet >TRACE (74): enter process_packet >TRACE (74): process_packet: packet type = 20 >TRACE (74): <- KEXINIT >TRACE (74): enter recv_msg_kexinit >TRACE (74): buf_match_algo: >diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 >TRACE (74): kex algo diffie-hellman-group14-sha1 >TRACE (74): buf_match_algo: ssh-rsa,ssh-dss >TRACE (74): hostkey algo ssh-rsa >TRACE (74): buf_match_algo: >aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 >TRACE (74): enc c2s is aes256-ctr >TRACE (74): buf_match_algo: >aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 >TRACE (74): enc s2c is aes256-ctr >TRACE (74): buf_match_algo: hmac-sha1,hmac-sha1-96,hmac-md5 >TRACE (74): hash c2s is hmac-sha1 >TRACE (74): buf_match_algo: hmac-sha1,hmac-sha1-96,hmac-md5 >TRACE (74): hash s2c is hmac-sha1 >TRACE (74): buf_match_algo: none,zlib >TRACE (74): hash c2s is none >TRACE (74): buf_match_algo: none,zlib >TRACE (74): hash s2c is none >TRACE (74): leave recv_msg_kexinit >TRACE (74): leave process_packet >TRACE (74): maybe_empty_reply_queue - no data allowed >TRACE (74): enter read_packet >TRACE (74): packet size is 272, block 8 mac 0 >TRACE (74): enter decrypt_packet >TRACE (74): enter writemac >TRACE (74): leave writemac >TRACE (74): leave decrypt_packet >TRACE (74): leave read_packet >TRACE (74): enter process_packet >TRACE (74): process_packet: packet type = 30 >TRACE (74): enter recv_msg_kexdh_init >TRACE (74): enter send_msg_kexdh_reply >TRACE (74): enter send_msg_kexdh_reply > ><<<45s delay>>> > >TRACE (74): enter buf_put_pub_key >TRACE (74): enter buf_put_rsa_pub_key >TRACE (74): enter buf_putmpint > > > >I'd be grateful for any ideas and suggestions. Thanks. > >Kind regards/Magnus From man at lundinova.se Mon Mar 14 20:25:07 2011 From: man at lundinova.se (Magnus Nilsson) Date: Mon, 14 Mar 2011 13:25:07 +0100 Subject: 45s login delay In-Reply-To: References: <4D7DEFEC.70602@lundinova.se> Message-ID: <4D7E0923.9090806@lundinova.se> Hi, Thanks for the quick reply. It's at 192MHz. It's this one: http://www.moxa.com/product/EM-1240.htm If this is expected, what can I do to shorten the delay (without compromising security too much)? 45s is a bit long to endure (e.g. WinSCP gives up after 15s). I'll try get top or a better ps on the board to see how busy the cpu gets. Kind regards/Magnus On 2011-03-14 12:59, Matt Johnston wrote: > Hi, > > What clock speed is the CPU? It looks a bit like it's just taking a very long time to perform big-number operations. > > Cheers, > Matt > > Magnus Nilsson wrote: > >> Hello, >> >> I have an issue with ~45s delay on every login (ssh, scp etc). Once the >> >> link is up dropbear runs fine. >> >> After reading these forums, I have disabled reverse lookup and added >> client IP to /etc/hosts, but that didn't help. >> >> I'm running dropbear 0.53.1 on armv4tl, uClinux 2.6.19, built largely >> like this: >> http://hi.baidu.com/kkernel/blog/item/ff919681141beddebc3e1e23.html >> but with --disable-shadow >> >> This the verbose output: >> # ./dropbear -a -F -v >> TRACE (73): enter loadhostkeys >> TRACE (73): enter buf_get_priv_key >> TRACE (73): enter rsa_key_free >> TRACE (73): leave rsa_key_free: key == NULL >> TRACE (73): enter buf_get_rsa_priv_key >> TRACE (73): enter buf_get_rsa_pub_key >> TRACE (73): leave buf_get_rsa_pub_key: success >> TRACE (73): leave buf_get_rsa_priv_key >> TRACE (73): leave buf_get_priv_key >> TRACE (73): enter buf_get_priv_key >> TRACE (73): enter dsa_key_free >> TRACE (73): enter dsa_key_free: key == NULL >> TRACE (73): enter buf_get_dss_pub_key >> TRACE (73): leave buf_get_dss_pub_key: success >> TRACE (73): leave buf_get_priv_key >> TRACE (73): leave loadhostkeys >> TRACE (73): listensockets: 1 to try >> TRACE (73): listening on ':22' >> TRACE (73): enter dropbear_listen >> TRACE (73): dropbear_listen: all interfaces >> TRACE (73): bind(22) failed >> TRACE (73): leave dropbear_listen: success, 1 socks bound >> [73] Mar 14 17:17:30 Not backgrounding >> [74] Mar 14 17:17:39 Child connection from 10.240.22.22:1456 >> TRACE (74): enter session_init >> TRACE (74): setnonblocking: 3 >> TRACE (74): leave setnonblocking >> TRACE (74): setnonblocking: 5 >> TRACE (74): leave setnonblocking >> TRACE (74): kexinitialise() >> TRACE (74): leave session_init >> TRACE (74): enter ident_readln >> TRACE (74): leave ident_readln: return 27 >> TRACE (74): remoteident: SSH-2.0-PuTTY_Release_0.60 >> TRACE (74): enter encrypt_packet() >> TRACE (74): encrypt_packet type is 20 >> TRACE (74): enter writemac >> TRACE (74): leave writemac >> TRACE (74): enter enqueue >> TRACE (74): leave enqueue >> TRACE (74): leave encrypt_packet() >> TRACE (74): DATAALLOWED=0 >> TRACE (74): -> KEXINIT >> TRACE (74): enter write_packet >> TRACE (74): empty queue dequeing >> TRACE (74): leave write_packet >> TRACE (74): enter read_packet >> TRACE (74): packet size is 616, block 8 mac 0 >> TRACE (74): enter decrypt_packet >> TRACE (74): enter writemac >> TRACE (74): leave writemac >> TRACE (74): leave decrypt_packet >> TRACE (74): leave read_packet >> TRACE (74): enter process_packet >> TRACE (74): process_packet: packet type = 20 >> TRACE (74):<- KEXINIT >> TRACE (74): enter recv_msg_kexinit >> TRACE (74): buf_match_algo: >> diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 >> TRACE (74): kex algo diffie-hellman-group14-sha1 >> TRACE (74): buf_match_algo: ssh-rsa,ssh-dss >> TRACE (74): hostkey algo ssh-rsa >> TRACE (74): buf_match_algo: >> aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 >> TRACE (74): enc c2s is aes256-ctr >> TRACE (74): buf_match_algo: >> aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 >> TRACE (74): enc s2c is aes256-ctr >> TRACE (74): buf_match_algo: hmac-sha1,hmac-sha1-96,hmac-md5 >> TRACE (74): hash c2s is hmac-sha1 >> TRACE (74): buf_match_algo: hmac-sha1,hmac-sha1-96,hmac-md5 >> TRACE (74): hash s2c is hmac-sha1 >> TRACE (74): buf_match_algo: none,zlib >> TRACE (74): hash c2s is none >> TRACE (74): buf_match_algo: none,zlib >> TRACE (74): hash s2c is none >> TRACE (74): leave recv_msg_kexinit >> TRACE (74): leave process_packet >> TRACE (74): maybe_empty_reply_queue - no data allowed >> TRACE (74): enter read_packet >> TRACE (74): packet size is 272, block 8 mac 0 >> TRACE (74): enter decrypt_packet >> TRACE (74): enter writemac >> TRACE (74): leave writemac >> TRACE (74): leave decrypt_packet >> TRACE (74): leave read_packet >> TRACE (74): enter process_packet >> TRACE (74): process_packet: packet type = 30 >> TRACE (74): enter recv_msg_kexdh_init >> TRACE (74): enter send_msg_kexdh_reply >> TRACE (74): enter send_msg_kexdh_reply >> >> <<<45s delay>>> >> >> TRACE (74): enter buf_put_pub_key >> TRACE (74): enter buf_put_rsa_pub_key >> TRACE (74): enter buf_putmpint >> >> >> >> I'd be grateful for any ideas and suggestions. Thanks. >> >> Kind regards/Magnus From matt at ucc.asn.au Mon Mar 14 20:27:42 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 14 Mar 2011 20:27:42 +0800 Subject: 45s login delay In-Reply-To: <4D7E0923.9090806@lundinova.se> References: <4D7DEFEC.70602@lundinova.se> <4D7E0923.9090806@lundinova.se> Message-ID: <20110314122742.GY24077@ucc.gu.uwa.edu.au> If you only give the server a DSS key how does it perform? That should be quicker than RSA. Cheers, Matt On Mon, Mar 14, 2011 at 01:25:07PM +0100, Magnus Nilsson wrote: > Hi, > > Thanks for the quick reply. It's at 192MHz. > It's this one: http://www.moxa.com/product/EM-1240.htm > > If this is expected, what can I do to shorten the delay (without > compromising security too much)? 45s is a bit long to endure (e.g. > WinSCP gives up after 15s). > I'll try get top or a better ps on the board to see how busy the cpu gets. > > Kind regards/Magnus > > > On 2011-03-14 12:59, Matt Johnston wrote: > >Hi, > > > >What clock speed is the CPU? It looks a bit like it's just taking a very long time to perform big-number operations. > > > >Cheers, > >Matt > > > >Magnus Nilsson wrote: > > > >>Hello, > >> > >>I have an issue with ~45s delay on every login (ssh, scp etc). Once the > >> > >>link is up dropbear runs fine. > >> > >>After reading these forums, I have disabled reverse lookup and added > >>client IP to /etc/hosts, but that didn't help. > >> > >>I'm running dropbear 0.53.1 on armv4tl, uClinux 2.6.19, built largely > >>like this: > >>http://hi.baidu.com/kkernel/blog/item/ff919681141beddebc3e1e23.html > >>but with --disable-shadow > >> > >>This the verbose output: > >># ./dropbear -a -F -v > >>TRACE (73): enter loadhostkeys > >>TRACE (73): enter buf_get_priv_key > >>TRACE (73): enter rsa_key_free > >>TRACE (73): leave rsa_key_free: key == NULL > >>TRACE (73): enter buf_get_rsa_priv_key > >>TRACE (73): enter buf_get_rsa_pub_key > >>TRACE (73): leave buf_get_rsa_pub_key: success > >>TRACE (73): leave buf_get_rsa_priv_key > >>TRACE (73): leave buf_get_priv_key > >>TRACE (73): enter buf_get_priv_key > >>TRACE (73): enter dsa_key_free > >>TRACE (73): enter dsa_key_free: key == NULL > >>TRACE (73): enter buf_get_dss_pub_key > >>TRACE (73): leave buf_get_dss_pub_key: success > >>TRACE (73): leave buf_get_priv_key > >>TRACE (73): leave loadhostkeys > >>TRACE (73): listensockets: 1 to try > >>TRACE (73): listening on ':22' > >>TRACE (73): enter dropbear_listen > >>TRACE (73): dropbear_listen: all interfaces > >>TRACE (73): bind(22) failed > >>TRACE (73): leave dropbear_listen: success, 1 socks bound > >>[73] Mar 14 17:17:30 Not backgrounding > >>[74] Mar 14 17:17:39 Child connection from 10.240.22.22:1456 > >>TRACE (74): enter session_init > >>TRACE (74): setnonblocking: 3 > >>TRACE (74): leave setnonblocking > >>TRACE (74): setnonblocking: 5 > >>TRACE (74): leave setnonblocking > >>TRACE (74): kexinitialise() > >>TRACE (74): leave session_init > >>TRACE (74): enter ident_readln > >>TRACE (74): leave ident_readln: return 27 > >>TRACE (74): remoteident: SSH-2.0-PuTTY_Release_0.60 > >>TRACE (74): enter encrypt_packet() > >>TRACE (74): encrypt_packet type is 20 > >>TRACE (74): enter writemac > >>TRACE (74): leave writemac > >>TRACE (74): enter enqueue > >>TRACE (74): leave enqueue > >>TRACE (74): leave encrypt_packet() > >>TRACE (74): DATAALLOWED=0 > >>TRACE (74): -> KEXINIT > >>TRACE (74): enter write_packet > >>TRACE (74): empty queue dequeing > >>TRACE (74): leave write_packet > >>TRACE (74): enter read_packet > >>TRACE (74): packet size is 616, block 8 mac 0 > >>TRACE (74): enter decrypt_packet > >>TRACE (74): enter writemac > >>TRACE (74): leave writemac > >>TRACE (74): leave decrypt_packet > >>TRACE (74): leave read_packet > >>TRACE (74): enter process_packet > >>TRACE (74): process_packet: packet type = 20 > >>TRACE (74):<- KEXINIT > >>TRACE (74): enter recv_msg_kexinit > >>TRACE (74): buf_match_algo: > >>diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > >>TRACE (74): kex algo diffie-hellman-group14-sha1 > >>TRACE (74): buf_match_algo: ssh-rsa,ssh-dss > >>TRACE (74): hostkey algo ssh-rsa > >>TRACE (74): buf_match_algo: > >>aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 > >>TRACE (74): enc c2s is aes256-ctr > >>TRACE (74): buf_match_algo: > >>aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 > >>TRACE (74): enc s2c is aes256-ctr > >>TRACE (74): buf_match_algo: hmac-sha1,hmac-sha1-96,hmac-md5 > >>TRACE (74): hash c2s is hmac-sha1 > >>TRACE (74): buf_match_algo: hmac-sha1,hmac-sha1-96,hmac-md5 > >>TRACE (74): hash s2c is hmac-sha1 > >>TRACE (74): buf_match_algo: none,zlib > >>TRACE (74): hash c2s is none > >>TRACE (74): buf_match_algo: none,zlib > >>TRACE (74): hash s2c is none > >>TRACE (74): leave recv_msg_kexinit > >>TRACE (74): leave process_packet > >>TRACE (74): maybe_empty_reply_queue - no data allowed > >>TRACE (74): enter read_packet > >>TRACE (74): packet size is 272, block 8 mac 0 > >>TRACE (74): enter decrypt_packet > >>TRACE (74): enter writemac > >>TRACE (74): leave writemac > >>TRACE (74): leave decrypt_packet > >>TRACE (74): leave read_packet > >>TRACE (74): enter process_packet > >>TRACE (74): process_packet: packet type = 30 > >>TRACE (74): enter recv_msg_kexdh_init > >>TRACE (74): enter send_msg_kexdh_reply > >>TRACE (74): enter send_msg_kexdh_reply > >> > >><<<45s delay>>> > >> > >>TRACE (74): enter buf_put_pub_key > >>TRACE (74): enter buf_put_rsa_pub_key > >>TRACE (74): enter buf_putmpint > >> > >> > >> > >>I'd be grateful for any ideas and suggestions. Thanks. > >> > >>Kind regards/Magnus From man at lundinova.se Mon Mar 14 21:19:30 2011 From: man at lundinova.se (Magnus Nilsson) Date: Mon, 14 Mar 2011 14:19:30 +0100 Subject: 45s login delay In-Reply-To: <20110314122742.GY24077@ucc.gu.uwa.edu.au> References: <4D7DEFEC.70602@lundinova.se> <4D7E0923.9090806@lundinova.se> <20110314122742.GY24077@ucc.gu.uwa.edu.au> Message-ID: <4D7E15E2.8080405@lundinova.se> You mean like 'ssh -c 3des root at 10.240.22.103'? (I also deleted /etc/dropbear_rsa_host_key to be sure) Unfortunately I get the exact same delay - 45s. Kind regards/Magnus On 2011-03-14 13:27, Matt Johnston wrote: > If you only give the server a DSS key how does it perform? > That should be quicker than RSA. > > Cheers, > Matt > > On Mon, Mar 14, 2011 at 01:25:07PM +0100, Magnus Nilsson wrote: >> Hi, >> >> Thanks for the quick reply. It's at 192MHz. >> It's this one: http://www.moxa.com/product/EM-1240.htm >> >> If this is expected, what can I do to shorten the delay (without >> compromising security too much)? 45s is a bit long to endure (e.g. >> WinSCP gives up after 15s). >> I'll try get top or a better ps on the board to see how busy the cpu gets. >> >> Kind regards/Magnus >> >> >> On 2011-03-14 12:59, Matt Johnston wrote: >>> Hi, >>> >>> What clock speed is the CPU? It looks a bit like it's just taking a very long time to perform big-number operations. >>> >>> Cheers, >>> Matt >>> >>> Magnus Nilsson wrote: >>> >>>> Hello, >>>> >>>> I have an issue with ~45s delay on every login (ssh, scp etc). Once the >>>> >>>> link is up dropbear runs fine. >>>> >>>> After reading these forums, I have disabled reverse lookup and added >>>> client IP to /etc/hosts, but that didn't help. >>>> >>>> I'm running dropbear 0.53.1 on armv4tl, uClinux 2.6.19, built largely >>>> like this: >>>> http://hi.baidu.com/kkernel/blog/item/ff919681141beddebc3e1e23.html >>>> but with --disable-shadow >>>> >>>> This the verbose output: >>>> # ./dropbear -a -F -v >>>> TRACE (73): enter loadhostkeys >>>> TRACE (73): enter buf_get_priv_key >>>> TRACE (73): enter rsa_key_free >>>> TRACE (73): leave rsa_key_free: key == NULL >>>> TRACE (73): enter buf_get_rsa_priv_key >>>> TRACE (73): enter buf_get_rsa_pub_key >>>> TRACE (73): leave buf_get_rsa_pub_key: success >>>> TRACE (73): leave buf_get_rsa_priv_key >>>> TRACE (73): leave buf_get_priv_key >>>> TRACE (73): enter buf_get_priv_key >>>> TRACE (73): enter dsa_key_free >>>> TRACE (73): enter dsa_key_free: key == NULL >>>> TRACE (73): enter buf_get_dss_pub_key >>>> TRACE (73): leave buf_get_dss_pub_key: success >>>> TRACE (73): leave buf_get_priv_key >>>> TRACE (73): leave loadhostkeys >>>> TRACE (73): listensockets: 1 to try >>>> TRACE (73): listening on ':22' >>>> TRACE (73): enter dropbear_listen >>>> TRACE (73): dropbear_listen: all interfaces >>>> TRACE (73): bind(22) failed >>>> TRACE (73): leave dropbear_listen: success, 1 socks bound >>>> [73] Mar 14 17:17:30 Not backgrounding >>>> [74] Mar 14 17:17:39 Child connection from 10.240.22.22:1456 >>>> TRACE (74): enter session_init >>>> TRACE (74): setnonblocking: 3 >>>> TRACE (74): leave setnonblocking >>>> TRACE (74): setnonblocking: 5 >>>> TRACE (74): leave setnonblocking >>>> TRACE (74): kexinitialise() >>>> TRACE (74): leave session_init >>>> TRACE (74): enter ident_readln >>>> TRACE (74): leave ident_readln: return 27 >>>> TRACE (74): remoteident: SSH-2.0-PuTTY_Release_0.60 >>>> TRACE (74): enter encrypt_packet() >>>> TRACE (74): encrypt_packet type is 20 >>>> TRACE (74): enter writemac >>>> TRACE (74): leave writemac >>>> TRACE (74): enter enqueue >>>> TRACE (74): leave enqueue >>>> TRACE (74): leave encrypt_packet() >>>> TRACE (74): DATAALLOWED=0 >>>> TRACE (74): -> KEXINIT >>>> TRACE (74): enter write_packet >>>> TRACE (74): empty queue dequeing >>>> TRACE (74): leave write_packet >>>> TRACE (74): enter read_packet >>>> TRACE (74): packet size is 616, block 8 mac 0 >>>> TRACE (74): enter decrypt_packet >>>> TRACE (74): enter writemac >>>> TRACE (74): leave writemac >>>> TRACE (74): leave decrypt_packet >>>> TRACE (74): leave read_packet >>>> TRACE (74): enter process_packet >>>> TRACE (74): process_packet: packet type = 20 >>>> TRACE (74):<- KEXINIT >>>> TRACE (74): enter recv_msg_kexinit >>>> TRACE (74): buf_match_algo: >>>> diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 >>>> TRACE (74): kex algo diffie-hellman-group14-sha1 >>>> TRACE (74): buf_match_algo: ssh-rsa,ssh-dss >>>> TRACE (74): hostkey algo ssh-rsa >>>> TRACE (74): buf_match_algo: >>>> aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 >>>> TRACE (74): enc c2s is aes256-ctr >>>> TRACE (74): buf_match_algo: >>>> aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 >>>> TRACE (74): enc s2c is aes256-ctr >>>> TRACE (74): buf_match_algo: hmac-sha1,hmac-sha1-96,hmac-md5 >>>> TRACE (74): hash c2s is hmac-sha1 >>>> TRACE (74): buf_match_algo: hmac-sha1,hmac-sha1-96,hmac-md5 >>>> TRACE (74): hash s2c is hmac-sha1 >>>> TRACE (74): buf_match_algo: none,zlib >>>> TRACE (74): hash c2s is none >>>> TRACE (74): buf_match_algo: none,zlib >>>> TRACE (74): hash s2c is none >>>> TRACE (74): leave recv_msg_kexinit >>>> TRACE (74): leave process_packet >>>> TRACE (74): maybe_empty_reply_queue - no data allowed >>>> TRACE (74): enter read_packet >>>> TRACE (74): packet size is 272, block 8 mac 0 >>>> TRACE (74): enter decrypt_packet >>>> TRACE (74): enter writemac >>>> TRACE (74): leave writemac >>>> TRACE (74): leave decrypt_packet >>>> TRACE (74): leave read_packet >>>> TRACE (74): enter process_packet >>>> TRACE (74): process_packet: packet type = 30 >>>> TRACE (74): enter recv_msg_kexdh_init >>>> TRACE (74): enter send_msg_kexdh_reply >>>> TRACE (74): enter send_msg_kexdh_reply >>>> >>>> <<<45s delay>>> >>>> >>>> TRACE (74): enter buf_put_pub_key >>>> TRACE (74): enter buf_put_rsa_pub_key >>>> TRACE (74): enter buf_putmpint >>>> >>>> >>>> >>>> I'd be grateful for any ideas and suggestions. Thanks. >>>> >>>> Kind regards/Magnus From man at lundinova.se Mon Mar 14 23:09:19 2011 From: man at lundinova.se (Magnus Nilsson) Date: Mon, 14 Mar 2011 16:09:19 +0100 Subject: 45s login delay In-Reply-To: <4D7E15E2.8080405@lundinova.se> References: <4D7DEFEC.70602@lundinova.se> <4D7E0923.9090806@lundinova.se> <20110314122742.GY24077@ucc.gu.uwa.edu.au> <4D7E15E2.8080405@lundinova.se> Message-ID: <4D7E2F9F.3080409@lundinova.se> Both top and ps are the gimped uClinux versions, but I found the cpu tool: # cpu -r CPU: busy 100% (system=0% user=99% nice=0% idle=0%) CPU: busy 100% (system=0% user=100% nice=0% idle=0%) ... So indeed it looks busy. Any suggestions what I can do to lighten the load? Kind regards/Magnus On 2011-03-14 14:19, Magnus Nilsson wrote: > You mean like 'ssh -c 3des root at 10.240.22.103'? > (I also deleted /etc/dropbear_rsa_host_key to be sure) > > Unfortunately I get the exact same delay - 45s. > > Kind regards/Magnus > > On 2011-03-14 13:27, Matt Johnston wrote: >> If you only give the server a DSS key how does it perform? >> That should be quicker than RSA. >> >> Cheers, >> Matt >> >> On Mon, Mar 14, 2011 at 01:25:07PM +0100, Magnus Nilsson wrote: >>> Hi, >>> >>> Thanks for the quick reply. It's at 192MHz. >>> It's this one: http://www.moxa.com/product/EM-1240.htm >>> >>> If this is expected, what can I do to shorten the delay (without >>> compromising security too much)? 45s is a bit long to endure (e.g. >>> WinSCP gives up after 15s). >>> I'll try get top or a better ps on the board to see how busy the cpu >>> gets. >>> >>> Kind regards/Magnus >>> >>> >>> On 2011-03-14 12:59, Matt Johnston wrote: >>>> Hi, >>>> >>>> What clock speed is the CPU? It looks a bit like it's just taking a >>>> very long time to perform big-number operations. >>>> >>>> Cheers, >>>> Matt >>>> >>>> Magnus Nilsson wrote: >>>> >>>>> Hello, >>>>> >>>>> I have an issue with ~45s delay on every login (ssh, scp etc). >>>>> Once the >>>>> >>>>> link is up dropbear runs fine. >>>>> >>>>> After reading these forums, I have disabled reverse lookup and added >>>>> client IP to /etc/hosts, but that didn't help. >>>>> >>>>> I'm running dropbear 0.53.1 on armv4tl, uClinux 2.6.19, built largely >>>>> like this: >>>>> http://hi.baidu.com/kkernel/blog/item/ff919681141beddebc3e1e23.html >>>>> but with --disable-shadow >>>>> >>>>> This the verbose output: >>>>> # ./dropbear -a -F -v >>>>> TRACE (73): enter loadhostkeys >>>>> TRACE (73): enter buf_get_priv_key >>>>> TRACE (73): enter rsa_key_free >>>>> TRACE (73): leave rsa_key_free: key == NULL >>>>> TRACE (73): enter buf_get_rsa_priv_key >>>>> TRACE (73): enter buf_get_rsa_pub_key >>>>> TRACE (73): leave buf_get_rsa_pub_key: success >>>>> TRACE (73): leave buf_get_rsa_priv_key >>>>> TRACE (73): leave buf_get_priv_key >>>>> TRACE (73): enter buf_get_priv_key >>>>> TRACE (73): enter dsa_key_free >>>>> TRACE (73): enter dsa_key_free: key == NULL >>>>> TRACE (73): enter buf_get_dss_pub_key >>>>> TRACE (73): leave buf_get_dss_pub_key: success >>>>> TRACE (73): leave buf_get_priv_key >>>>> TRACE (73): leave loadhostkeys >>>>> TRACE (73): listensockets: 1 to try >>>>> TRACE (73): listening on ':22' >>>>> TRACE (73): enter dropbear_listen >>>>> TRACE (73): dropbear_listen: all interfaces >>>>> TRACE (73): bind(22) failed >>>>> TRACE (73): leave dropbear_listen: success, 1 socks bound >>>>> [73] Mar 14 17:17:30 Not backgrounding >>>>> [74] Mar 14 17:17:39 Child connection from 10.240.22.22:1456 >>>>> TRACE (74): enter session_init >>>>> TRACE (74): setnonblocking: 3 >>>>> TRACE (74): leave setnonblocking >>>>> TRACE (74): setnonblocking: 5 >>>>> TRACE (74): leave setnonblocking >>>>> TRACE (74): kexinitialise() >>>>> TRACE (74): leave session_init >>>>> TRACE (74): enter ident_readln >>>>> TRACE (74): leave ident_readln: return 27 >>>>> TRACE (74): remoteident: SSH-2.0-PuTTY_Release_0.60 >>>>> TRACE (74): enter encrypt_packet() >>>>> TRACE (74): encrypt_packet type is 20 >>>>> TRACE (74): enter writemac >>>>> TRACE (74): leave writemac >>>>> TRACE (74): enter enqueue >>>>> TRACE (74): leave enqueue >>>>> TRACE (74): leave encrypt_packet() >>>>> TRACE (74): DATAALLOWED=0 >>>>> TRACE (74): -> KEXINIT >>>>> TRACE (74): enter write_packet >>>>> TRACE (74): empty queue dequeing >>>>> TRACE (74): leave write_packet >>>>> TRACE (74): enter read_packet >>>>> TRACE (74): packet size is 616, block 8 mac 0 >>>>> TRACE (74): enter decrypt_packet >>>>> TRACE (74): enter writemac >>>>> TRACE (74): leave writemac >>>>> TRACE (74): leave decrypt_packet >>>>> TRACE (74): leave read_packet >>>>> TRACE (74): enter process_packet >>>>> TRACE (74): process_packet: packet type = 20 >>>>> TRACE (74):<- KEXINIT >>>>> TRACE (74): enter recv_msg_kexinit >>>>> TRACE (74): buf_match_algo: >>>>> diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 >>>>> >>>>> TRACE (74): kex algo diffie-hellman-group14-sha1 >>>>> TRACE (74): buf_match_algo: ssh-rsa,ssh-dss >>>>> TRACE (74): hostkey algo ssh-rsa >>>>> TRACE (74): buf_match_algo: >>>>> aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 >>>>> >>>>> TRACE (74): enc c2s is aes256-ctr >>>>> TRACE (74): buf_match_algo: >>>>> aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 >>>>> >>>>> TRACE (74): enc s2c is aes256-ctr >>>>> TRACE (74): buf_match_algo: hmac-sha1,hmac-sha1-96,hmac-md5 >>>>> TRACE (74): hash c2s is hmac-sha1 >>>>> TRACE (74): buf_match_algo: hmac-sha1,hmac-sha1-96,hmac-md5 >>>>> TRACE (74): hash s2c is hmac-sha1 >>>>> TRACE (74): buf_match_algo: none,zlib >>>>> TRACE (74): hash c2s is none >>>>> TRACE (74): buf_match_algo: none,zlib >>>>> TRACE (74): hash s2c is none >>>>> TRACE (74): leave recv_msg_kexinit >>>>> TRACE (74): leave process_packet >>>>> TRACE (74): maybe_empty_reply_queue - no data allowed >>>>> TRACE (74): enter read_packet >>>>> TRACE (74): packet size is 272, block 8 mac 0 >>>>> TRACE (74): enter decrypt_packet >>>>> TRACE (74): enter writemac >>>>> TRACE (74): leave writemac >>>>> TRACE (74): leave decrypt_packet >>>>> TRACE (74): leave read_packet >>>>> TRACE (74): enter process_packet >>>>> TRACE (74): process_packet: packet type = 30 >>>>> TRACE (74): enter recv_msg_kexdh_init >>>>> TRACE (74): enter send_msg_kexdh_reply >>>>> TRACE (74): enter send_msg_kexdh_reply >>>>> >>>>> <<<45s delay>>> >>>>> >>>>> TRACE (74): enter buf_put_pub_key >>>>> TRACE (74): enter buf_put_rsa_pub_key >>>>> TRACE (74): enter buf_putmpint >>>>> >>>>> >>>>> >>>>> I'd be grateful for any ideas and suggestions. Thanks. >>>>> >>>>> Kind regards/Magnus From rob at landley.net Tue Mar 15 05:53:35 2011 From: rob at landley.net (Rob Landley) Date: Mon, 14 Mar 2011 16:53:35 -0500 Subject: 45s login delay In-Reply-To: <4D7E2F9F.3080409@lundinova.se> References: <4D7DEFEC.70602@lundinova.se> <4D7E0923.9090806@lundinova.se> <20110314122742.GY24077@ucc.gu.uwa.edu.au> <4D7E15E2.8080405@lundinova.se> <4D7E2F9F.3080409@lundinova.se> Message-ID: <4D7E8E5F.8070109@landley.net> On 03/14/2011 10:09 AM, Magnus Nilsson wrote: > Both top and ps are the gimped uClinux versions, but I found the cpu tool: > # cpu -r > CPU: busy 100% (system=0% user=99% nice=0% idle=0%) > CPU: busy 100% (system=0% user=100% nice=0% idle=0%) > ... > > So indeed it looks busy. Any suggestions what I can do to lighten the load? What's using the load? Does the http://busybox.net/downloads/binaries/latest/busybox-armv4tl binary work for you? (or the armv4l one if you're using oabi?) That should let you run "top"... Rob From man at lundinova.se Tue Mar 15 21:02:54 2011 From: man at lundinova.se (Magnus Nilsson) Date: Tue, 15 Mar 2011 14:02:54 +0100 Subject: 45s login delay In-Reply-To: <4D7E8E5F.8070109@landley.net> References: <4D7DEFEC.70602@lundinova.se> <4D7E0923.9090806@lundinova.se> <20110314122742.GY24077@ucc.gu.uwa.edu.au> <4D7E15E2.8080405@lundinova.se> <4D7E2F9F.3080409@lundinova.se> <4D7E8E5F.8070109@landley.net> Message-ID: <4D7F637E.3080605@lundinova.se> Sorry, I was unclear - it's only 100% busy during those 45s. This is what it looks like if I first start the load monitor (-r outputs 1 sample/second), then start to log in from a remote ssh client: # cpu -r CPU: busy 0% (system=0% user=0% nice=0% idle=100%) CPU: busy 24% (system=4% user=19% nice=0% idle=75%) CPU: busy 100% (system=1% user=98% nice=0% idle=0%) CPU: busy 100% (system=0% user=100% nice=0% idle=0%) <39 repeats of the above busy 100%> CPU: busy 100% (system=2% user=97% nice=0% idle=0%) CPU: busy 100% (system=8% user=91% nice=0% idle=0%) CPU: busy 100% (system=22% user=77% nice=0% idle=0%) CPU: busy 100% (system=0% user=100% nice=0% idle=0%) CPU: busy 100% (system=0% user=100% nice=0% idle=0%) CPU: busy 67% (system=8% user=58% nice=0% idle=32%) CPU: busy 0% (system=0% user=0% nice=0% idle=100%) Thanks for the tip on prebuilt busybox Rob, but would I need it in flat format. I don't think arm-elf-elf2flt can do that without reloc info or? And from the above I don't think it would add much info. My question is: Is 45s reasonable on a 192MHz cpu, or do you think I might have some issue with my compilation options (see my first post, http://hi.baidu.com/kkernel/blog/item/ff919681141beddebc3e1e23.html but with --disable-shadow) or something? Anyone who has similar experiences? Or the opposite, someone who's running it on a low-end system without this issue? My next step is probably to trace and see where it's spending the time. Kind regards/Magnus On 2011-03-14 22:53, Rob Landley wrote: > On 03/14/2011 10:09 AM, Magnus Nilsson wrote: >> Both top and ps are the gimped uClinux versions, but I found the cpu tool: >> # cpu -r >> CPU: busy 100% (system=0% user=99% nice=0% idle=0%) >> CPU: busy 100% (system=0% user=100% nice=0% idle=0%) >> ... >> >> So indeed it looks busy. Any suggestions what I can do to lighten the load? > What's using the load? > > Does the http://busybox.net/downloads/binaries/latest/busybox-armv4tl > binary work for you? (or the armv4l one if you're using oabi?) > > That should let you run "top"... > > Rob > From matt at ucc.asn.au Tue Mar 15 21:08:12 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 15 Mar 2011 21:08:12 +0800 Subject: 45s login delay In-Reply-To: <4D7F637E.3080605@lundinova.se> References: <4D7DEFEC.70602@lundinova.se> <4D7E0923.9090806@lundinova.se> <20110314122742.GY24077@ucc.gu.uwa.edu.au> <4D7E15E2.8080405@lundinova.se> <4D7E2F9F.3080409@lundinova.se> <4D7E8E5F.8070109@landley.net> <4D7F637E.3080605@lundinova.se> Message-ID: <20110315130812.GB24077@ucc.gu.uwa.edu.au> On Tue, Mar 15, 2011 at 02:02:54PM +0100, Magnus Nilsson wrote: > Sorry, I was unclear - it's only 100% busy during those 45s. > My question is: > Is 45s reasonable on a 192MHz cpu, or do you think I might have some > issue with my compilation options (see my first post, > http://hi.baidu.com/kkernel/blog/item/ff919681141beddebc3e1e23.html > but with --disable-shadow) or something? > Anyone who has similar experiences? Or the opposite, someone who's > running it on a low-end system without this issue? I haven't tried anything quite that low-end, but the couple of MIPS routers I've tried at ~400mhz take about 1 second for that step. I guess there could be something odd about the architecture that interacts badly with what libtommath is doing, or perhaps the compiler. The binary was built with optimisation enabled? Cheers, Matt From olof.kindgren at orsoc.se Tue Mar 15 21:11:49 2011 From: olof.kindgren at orsoc.se (Olof Kindgren) Date: Tue, 15 Mar 2011 14:11:49 +0100 Subject: 45s login delay In-Reply-To: <20110315130812.GB24077@ucc.gu.uwa.edu.au> References: <4D7DEFEC.70602@lundinova.se> <4D7E0923.9090806@lundinova.se> <20110314122742.GY24077@ucc.gu.uwa.edu.au> <4D7E15E2.8080405@lundinova.se> <4D7E2F9F.3080409@lundinova.se> <4D7E8E5F.8070109@landley.net> <4D7F637E.3080605@lundinova.se> <20110315130812.GB24077@ucc.gu.uwa.edu.au> Message-ID: Hi, I don't have any real numbers right now, but it takes roughly a minute on a 10MHz OpenRISC CPU, so it seems something is up //Olof 2011/3/15 Matt Johnston > On Tue, Mar 15, 2011 at 02:02:54PM +0100, Magnus Nilsson wrote: > > Sorry, I was unclear - it's only 100% busy during those 45s. > > My question is: > > Is 45s reasonable on a 192MHz cpu, or do you think I might have some > > issue with my compilation options (see my first post, > > http://hi.baidu.com/kkernel/blog/item/ff919681141beddebc3e1e23.html > > but with --disable-shadow) or something? > > Anyone who has similar experiences? Or the opposite, someone who's > > running it on a low-end system without this issue? > > I haven't tried anything quite that low-end, but the couple > of MIPS routers I've tried at ~400mhz take about 1 second > for that step. I guess there could be something odd about > the architecture that interacts badly with what libtommath > is doing, or perhaps the compiler. The binary was built with > optimisation enabled? > > Cheers, > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20110315/f550c9a3/attachment.htm From man at lundinova.se Tue Mar 15 22:20:17 2011 From: man at lundinova.se (Magnus Nilsson) Date: Tue, 15 Mar 2011 15:20:17 +0100 Subject: 45s login delay In-Reply-To: <20110315130812.GB24077@ucc.gu.uwa.edu.au> References: <4D7DEFEC.70602@lundinova.se> <4D7E0923.9090806@lundinova.se> <20110314122742.GY24077@ucc.gu.uwa.edu.au> <4D7E15E2.8080405@lundinova.se> <4D7E2F9F.3080409@lundinova.se> <4D7E8E5F.8070109@landley.net> <4D7F637E.3080605@lundinova.se> <20110315130812.GB24077@ucc.gu.uwa.edu.au> Message-ID: <4D7F75A1.1080203@lundinova.se> Good point: the flags in the makefile were are all over the place. Had -01, then -0s in the same gcc line. Made it -03 and now the 45s are down to 30s. Better, but still too long of course. Thanks for that Matt, and for the 1s on 400MHz figure; that makes me feel it's worth to keep looking for the problem. Kind regards/Magnus On 2011-03-15 14:08, Matt Johnston wrote: > On Tue, Mar 15, 2011 at 02:02:54PM +0100, Magnus Nilsson wrote: >> Sorry, I was unclear - it's only 100% busy during those 45s. >> My question is: >> Is 45s reasonable on a 192MHz cpu, or do you think I might have some >> issue with my compilation options (see my first post, >> http://hi.baidu.com/kkernel/blog/item/ff919681141beddebc3e1e23.html >> but with --disable-shadow) or something? >> Anyone who has similar experiences? Or the opposite, someone who's >> running it on a low-end system without this issue? > I haven't tried anything quite that low-end, but the couple > of MIPS routers I've tried at ~400mhz take about 1 second > for that step. I guess there could be something odd about > the architecture that interacts badly with what libtommath > is doing, or perhaps the compiler. The binary was built with > optimisation enabled? > > Cheers, > Matt > From jacmet at sunsite.dk Tue Mar 15 22:44:41 2011 From: jacmet at sunsite.dk (Peter Korsgaard) Date: Tue, 15 Mar 2011 15:44:41 +0100 Subject: 45s login delay In-Reply-To: <4D7F637E.3080605@lundinova.se> (Magnus Nilsson's message of "Tue, 15 Mar 2011 14:02:54 +0100") References: <4D7DEFEC.70602@lundinova.se> <4D7E0923.9090806@lundinova.se> <20110314122742.GY24077@ucc.gu.uwa.edu.au> <4D7E15E2.8080405@lundinova.se> <4D7E2F9F.3080409@lundinova.se> <4D7E8E5F.8070109@landley.net> <4D7F637E.3080605@lundinova.se> Message-ID: <87r5a8moiu.fsf@macbook.be.48ers.dk> >>>>> "Magnus" == Magnus Nilsson writes: Hi, Magnus> Is 45s reasonable on a 192MHz cpu, or do you think I might have Magnus> some issue with my compilation options Here it takes ~1s on a 400MHz ARM9 so I doubt it. -- Bye, Peter Korsgaard From rob at landley.net Wed Mar 16 05:25:26 2011 From: rob at landley.net (Rob Landley) Date: Tue, 15 Mar 2011 16:25:26 -0500 Subject: 45s login delay In-Reply-To: <4D7F637E.3080605@lundinova.se> References: <4D7DEFEC.70602@lundinova.se> <4D7E0923.9090806@lundinova.se> <20110314122742.GY24077@ucc.gu.uwa.edu.au> <4D7E15E2.8080405@lundinova.se> <4D7E2F9F.3080409@lundinova.se> <4D7E8E5F.8070109@landley.net> <4D7F637E.3080605@lundinova.se> Message-ID: <4D7FD946.2040203@landley.net> On 03/15/2011 08:02 AM, Magnus Nilsson wrote: > Sorry, I was unclear - it's only 100% busy during those 45s. > > This is what it looks like if I first start the load monitor (-r outputs > 1 sample/second), then start to log in from a remote ssh client: > # cpu -r > CPU: busy 0% (system=0% user=0% nice=0% idle=100%) > CPU: busy 24% (system=4% user=19% nice=0% idle=75%) > CPU: busy 100% (system=1% user=98% nice=0% idle=0%) > CPU: busy 100% (system=0% user=100% nice=0% idle=0%) > <39 repeats of the above busy 100%> > CPU: busy 100% (system=2% user=97% nice=0% idle=0%) > CPU: busy 100% (system=8% user=91% nice=0% idle=0%) > CPU: busy 100% (system=22% user=77% nice=0% idle=0%) > CPU: busy 100% (system=0% user=100% nice=0% idle=0%) > CPU: busy 100% (system=0% user=100% nice=0% idle=0%) > CPU: busy 67% (system=8% user=58% nice=0% idle=32%) > CPU: busy 0% (system=0% user=0% nice=0% idle=100%) > > Thanks for the tip on prebuilt busybox Rob, but would I need it in flat > format. I don't think arm-elf-elf2flt can do that without reloc info or? > And from the above I don't think it would add much info. > > My question is: > Is 45s reasonable on a 192MHz cpu, No. I had a 200mhz celeron that did 3.2 ssh logins per second ten years ago. (I did a VPN built on top of ssh, dynamic port forwarding, and netcat, and had to benchmark it.) Going from i686 to arm could cost you some performance (ever since the pentium it's had multiple execution cores, speculative execution, instruction reordering and such), but there's no _way_ that's more than an order of magnitude in performance. I could see 4 seconds, but but 45 seconds is pathological. Something is wrong. My next step would be "stick printfs in the source code and see where the big delay is". Hmmm... Do they still _make_ CPUs with no L1 cache? Rob From redhatter at gentoo.org Wed Mar 16 11:07:51 2011 From: redhatter at gentoo.org (Stuart Longland) Date: Wed, 16 Mar 2011 13:07:51 +1000 Subject: dropbear and -lcrypt Message-ID: <4D802987.2070001@gentoo.org> Hi, Not sure what the cause was, but just today I was trying to compile dropbear against ?Clibc-0.9.31 on a mipsel system (native compile). It would bomb out every time at the point where 'dropbear' is linked. I didn't save a logfile of the build unfortunately. The error message was "undefined reference to crypt". I found I could avoid the problem by specifying -lcrypt in LIBS, as per the attachment. Now it successfully builds. Attached is a patch that does this. I'm not sure if this is something ./configure should have picked up. The other possibility is that the build system could be relying on the fact that other libraries it links against, also link against libcrypt and thus it'd get pulled in as a result. On Gentoo we link with the --as-needed flag, which would break this assumption. I'll be doing a rebuild of my ?Clibc environment shortly, so I'll try leaving the patch out once again and get a build logs with and without the patch for comparison in case I've missed something, but figured I'd toss the patch your way for public comment. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' I haven't lost my mind... ...it's backed up on a tape somewhere. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dropbear-0.53.1-lcrypt.diff Url: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20110316/958fdb0b/attachment.txt From peter at turczak.de Wed Mar 16 15:25:05 2011 From: peter at turczak.de (Peter Turczak) Date: Wed, 16 Mar 2011 08:25:05 +0100 Subject: 45s login delay In-Reply-To: <4D7FD946.2040203@landley.net> References: <4D7DEFEC.70602@lundinova.se> <4D7E0923.9090806@lundinova.se> <20110314122742.GY24077@ucc.gu.uwa.edu.au> <4D7E15E2.8080405@lundinova.se> <4D7E2F9F.3080409@lundinova.se> <4D7E8E5F.8070109@landley.net> <4D7F637E.3080605@lundinova.se> <4D7FD946.2040203@landley.net> Message-ID: Hi Magnus, hi Rob, a while ago I made the same observations you did. On an m68k-nommu with 166 MHz the RSA exchange took quite forever. After some profiling I found out the comba multiply routine in libtommath was eating most of the time. It seems gcc produces quite inefficient code there. Libtommath resizes its large integers while calculating leading to more work for user memory management. Therefore I converted dropbear to use libtomsfastmath which helped a lot at the expense of a larger memory footprint. After porting some parts to assembler (which libtomsfastmath has special hooks for) I cut down the time to 10sec which is IMHO much better. The version I did was more a proof of concept and is not shiny and packed but will compile, maybe you could have a look at it. (http://peter.turczak.de/dropbear-tfm.tgz) Rob is right in a way, but openssl uses assembler all along. Furthermore a missing L1 will contribute to slowing the keyexchange to a crawl. Best regards, Peter On Mar 15, 2011, at 10:25 PM, Rob Landley wrote: > On 03/15/2011 08:02 AM, Magnus Nilsson wrote: >> Sorry, I was unclear - it's only 100% busy during those 45s. >> >> This is what it looks like if I first start the load monitor (-r outputs >> 1 sample/second), then start to log in from a remote ssh client: >> # cpu -r >> CPU: busy 0% (system=0% user=0% nice=0% idle=100%) >> CPU: busy 24% (system=4% user=19% nice=0% idle=75%) >> CPU: busy 100% (system=1% user=98% nice=0% idle=0%) >> CPU: busy 100% (system=0% user=100% nice=0% idle=0%) >> <39 repeats of the above busy 100%> >> CPU: busy 100% (system=2% user=97% nice=0% idle=0%) >> CPU: busy 100% (system=8% user=91% nice=0% idle=0%) >> CPU: busy 100% (system=22% user=77% nice=0% idle=0%) >> CPU: busy 100% (system=0% user=100% nice=0% idle=0%) >> CPU: busy 100% (system=0% user=100% nice=0% idle=0%) >> CPU: busy 67% (system=8% user=58% nice=0% idle=32%) >> CPU: busy 0% (system=0% user=0% nice=0% idle=100%) >> >> Thanks for the tip on prebuilt busybox Rob, but would I need it in flat >> format. I don't think arm-elf-elf2flt can do that without reloc info or? >> And from the above I don't think it would add much info. >> >> My question is: >> Is 45s reasonable on a 192MHz cpu, > > No. I had a 200mhz celeron that did 3.2 ssh logins per second ten years > ago. (I did a VPN built on top of ssh, dynamic port forwarding, and > netcat, and had to benchmark it.) Going from i686 to arm could cost you > some performance (ever since the pentium it's had multiple execution > cores, speculative execution, instruction reordering and such), but > there's no _way_ that's more than an order of magnitude in performance. > I could see 4 seconds, but but 45 seconds is pathological. Something > is wrong. > > My next step would be "stick printfs in the source code and see where > the big delay is". > > Hmmm... Do they still _make_ CPUs with no L1 cache? > > Rob From man at lundinova.se Wed Mar 16 18:51:00 2011 From: man at lundinova.se (man at lundinova.se) Date: Wed, 16 Mar 2011 11:51:00 +0100 Subject: 45s login delay In-Reply-To: References: <4D7DEFEC.70602@lundinova.se> <4D7E0923.9090806@lundinova.se> <20110314122742.GY24077@ucc.gu.uwa.edu.au> <4D7E15E2.8080405@lundinova.se> <4D7E2F9F.3080409@lundinova.se> <4D7E8E5F.8070109@landley.net> <4D7F637E.3080605@lundinova.se> <4D7FD946.2040203@landley.net> Message-ID: <1300272660.4d8096149ac14@webmail.lundinova.se> Hi Peter, Thanks for your reply, that's very informative. I tried openssl and got down to around the 10s you're talking about. Doesn't leave space for much else though. I haven't found any real specs for the CPU - but the manufacturer mentions type and size of cache in their other CPUs but not in this one, so I fear the worst. I'll try your converted code and see where that brings me. Kind regards/Magnus Quoting Peter Turczak : > Hi Magnus, > hi Rob, > > a while ago I made the same observations you did. On an m68k-nommu with 166 > MHz the RSA exchange took quite forever. After some profiling I found out the > comba multiply routine in libtommath was eating most of the time. It seems > gcc produces quite inefficient code there. Libtommath resizes its large > integers while calculating leading to more work for user memory management. > Therefore I converted dropbear to use libtomsfastmath which helped a lot at > the expense of a larger memory footprint. After porting some parts to > assembler (which libtomsfastmath has special hooks for) I cut down the time > to 10sec which is IMHO much better. > > The version I did was more a proof of concept and is not shiny and packed but > will compile, maybe you could have a look at it. > (http://peter.turczak.de/dropbear-tfm.tgz) > > Rob is right in a way, but openssl uses assembler all along. Furthermore a > missing L1 will contribute to slowing the keyexchange to a crawl. > > Best regards, > > Peter > > On Mar 15, 2011, at 10:25 PM, Rob Landley wrote: > > > On 03/15/2011 08:02 AM, Magnus Nilsson wrote: > >> Sorry, I was unclear - it's only 100% busy during those 45s. > >> > >> This is what it looks like if I first start the load monitor (-r outputs > >> 1 sample/second), then start to log in from a remote ssh client: > >> # cpu -r > >> CPU: busy 0% (system=0% user=0% nice=0% idle=100%) > >> CPU: busy 24% (system=4% user=19% nice=0% idle=75%) > >> CPU: busy 100% (system=1% user=98% nice=0% idle=0%) > >> CPU: busy 100% (system=0% user=100% nice=0% idle=0%) > >> <39 repeats of the above busy 100%> > >> CPU: busy 100% (system=2% user=97% nice=0% idle=0%) > >> CPU: busy 100% (system=8% user=91% nice=0% idle=0%) > >> CPU: busy 100% (system=22% user=77% nice=0% idle=0%) > >> CPU: busy 100% (system=0% user=100% nice=0% idle=0%) > >> CPU: busy 100% (system=0% user=100% nice=0% idle=0%) > >> CPU: busy 67% (system=8% user=58% nice=0% idle=32%) > >> CPU: busy 0% (system=0% user=0% nice=0% idle=100%) > >> > >> Thanks for the tip on prebuilt busybox Rob, but would I need it in flat > >> format. I don't think arm-elf-elf2flt can do that without reloc info or? > >> And from the above I don't think it would add much info. > >> > >> My question is: > >> Is 45s reasonable on a 192MHz cpu, > > > > No. I had a 200mhz celeron that did 3.2 ssh logins per second ten years > > ago. (I did a VPN built on top of ssh, dynamic port forwarding, and > > netcat, and had to benchmark it.) Going from i686 to arm could cost you > > some performance (ever since the pentium it's had multiple execution > > cores, speculative execution, instruction reordering and such), but > > there's no _way_ that's more than an order of magnitude in performance. > > I could see 4 seconds, but but 45 seconds is pathological. Something > > is wrong. > > > > My next step would be "stick printfs in the source code and see where > > the big delay is". > > > > Hmmm... Do they still _make_ CPUs with no L1 cache? > > > > Rob > > From rob at landley.net Thu Mar 17 08:16:34 2011 From: rob at landley.net (Rob Landley) Date: Wed, 16 Mar 2011 19:16:34 -0500 Subject: 45s login delay In-Reply-To: References: <4D7DEFEC.70602@lundinova.se> <4D7E0923.9090806@lundinova.se> <20110314122742.GY24077@ucc.gu.uwa.edu.au> <4D7E15E2.8080405@lundinova.se> <4D7E2F9F.3080409@lundinova.se> <4D7E8E5F.8070109@landley.net> <4D7F637E.3080605@lundinova.se> <4D7FD946.2040203@landley.net> Message-ID: <4D8152E2.4000307@landley.net> On 03/16/2011 02:25 AM, Peter Turczak wrote: > Hi Magnus, hi Rob, > > a while ago I made the same observations you did. On an m68k-nommu > with 166 MHz the RSA exchange took quite forever. After some > profiling I found out the comba multiply routine in libtommath was > eating most of the time. It seems gcc produces quite inefficient code > there. Libtommath resizes its large integers while calculating > leading to more work for user memory management. User mememory management? It's got a malloc/free in an inner loop? BARF! (Yeah, that'll blow your L1 cache wide open and slow stuff down by at least an order of magnitude. Allocation functions are some of the most cache unfriendly things you can do, pretty much by definition. Unused memory is not cache hot, pretty much by definition. That's sort of the point. Copying the data sucks too, but it's doing the copying on all platforms I'd guess...) Rob From matt at ucc.asn.au Thu Mar 17 23:23:44 2011 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 17 Mar 2011 23:23:44 +0800 Subject: 45s login delay In-Reply-To: <4D8152E2.4000307@landley.net> References: <4D7E0923.9090806@lundinova.se> <20110314122742.GY24077@ucc.gu.uwa.edu.au> <4D7E15E2.8080405@lundinova.se> <4D7E2F9F.3080409@lundinova.se> <4D7E8E5F.8070109@landley.net> <4D7F637E.3080605@lundinova.se> <4D7FD946.2040203@landley.net> <4D8152E2.4000307@landley.net> Message-ID: <20110317152344.GM24077@ucc.gu.uwa.edu.au> On Wed, Mar 16, 2011 at 07:16:34PM -0500, Rob Landley wrote: > On 03/16/2011 02:25 AM, Peter Turczak wrote: > > Hi Magnus, hi Rob, > > > > a while ago I made the same observations you did. On an m68k-nommu > > with 166 MHz the RSA exchange took quite forever. After some > > profiling I found out the comba multiply routine in libtommath was > > eating most of the time. It seems gcc produces quite inefficient code > > there. Libtommath resizes its large integers while calculating > > leading to more work for user memory management. > > User mememory management? It's got a malloc/free in an inner loop? BARF! > > (Yeah, that'll blow your L1 cache wide open and slow stuff down by at > least an order of magnitude. Allocation functions are some of the most > cache unfriendly things you can do, pretty much by definition. Unused > memory is not cache hot, pretty much by definition. That's sort of the > point. Copying the data sucks too, but it's doing the copying on all > platforms I'd guess...) I guess it's possible. Logging in to a server with 1024 bit RSA and RSA authorized_key I get ~229 reallocs in mp_grow(), not a massive number if spread over 45 seconds. The patch below drops it to ~30 reallcs. Magnus: It might be worth seeing if it changes your timing. I haven't looked whether it increases memory usage. Matt --- libtommath/bn_mp_exptmod_fast.c 5a692f134deeab0992612206c16f8bf970b5088c +++ libtommath/bn_mp_exptmod_fast.c 5391873ccf8a11171774425c69f584195b4fdba4 @@ -67,13 +67,13 @@ int mp_exptmod_fast (mp_int * G, mp_int /* init M array */ /* init first cell */ - if ((err = mp_init(&M[1])) != MP_OKAY) { + if ((err = mp_init_size(&M[1], P->used)) != MP_OKAY) { return err; } /* now init the second half of the array */ for (x = 1<<(winsize-1); x < (1 << winsize); x++) { - if ((err = mp_init(&M[x])) != MP_OKAY) { + if ((err = mp_init_size(&M[x], P->alloc+1)) != MP_OKAY) { for (y = 1<<(winsize-1); y < x; y++) { mp_clear (&M[y]); } @@ -96,7 +96,7 @@ int mp_exptmod_fast (mp_int * G, mp_int /* automatically pick the comba one if available (saves quite a few calls/ifs) */ #ifdef BN_FAST_MP_MONTGOMERY_REDUCE_C - if (((P->used * 2 + 1) < MP_WARRAY) && + if (((P->alloc * 2 + 1) < MP_WARRAY) && P->used < (1 << ((CHAR_BIT * sizeof (mp_word)) - (2 * DIGIT_BIT)))) { redux = fast_mp_montgomery_reduce; } else @@ -133,7 +133,7 @@ int mp_exptmod_fast (mp_int * G, mp_int } /* setup result */ - if ((err = mp_init (&res)) != MP_OKAY) { + if ((err = mp_init_size (&res, P->used)) != MP_OKAY) { goto LBL_M; } ============================================================ --- libtommath/bn_mp_init_copy.c fd7c20c0ee3473615de23c59074cf5c6757a20ca +++ libtommath/bn_mp_init_copy.c 841949a75e387e818f2f4d9adedff0ba9c9374c0 @@ -20,7 +20,7 @@ int mp_init_copy (mp_int * a, mp_int * b { int res; - if ((res = mp_init (a)) != MP_OKAY) { + if ((res = mp_init_size (a, b->used)) != MP_OKAY) { return res; } return mp_copy (b, a); ============================================================ --- libtommath/bn_mp_mod.c 3bed12926c4d019853f2b4dac814a7505580380e +++ libtommath/bn_mp_mod.c 9265cd0294d2c86f1c3c73eaa5bf19c30403e13b @@ -22,7 +22,7 @@ mp_mod (mp_int * a, mp_int * b, mp_int * mp_int t; int res; - if ((res = mp_init (&t)) != MP_OKAY) { + if ((res = mp_init_size (&t, b->used)) != MP_OKAY) { return res; } ============================================================ --- libtommath/bn_mp_mulmod.c 935d0f5903589ddf62f42fc691cb2f83aa2832c4 +++ libtommath/bn_mp_mulmod.c ef9063432e3a0c62b7118dfc3d01d04cd4dc8bb9 @@ -21,7 +21,7 @@ int mp_mulmod (mp_int * a, mp_int * b, m int res; mp_int t; - if ((res = mp_init (&t)) != MP_OKAY) { + if ((res = mp_init_size (&t, c->used)) != MP_OKAY) { return res; } From man at lundinova.se Sat Mar 19 01:04:05 2011 From: man at lundinova.se (Magnus Nilsson) Date: Fri, 18 Mar 2011 18:04:05 +0100 Subject: 45s login delay In-Reply-To: <20110317152344.GM24077@ucc.gu.uwa.edu.au> References: <4D7E0923.9090806@lundinova.se> <20110314122742.GY24077@ucc.gu.uwa.edu.au> <4D7E15E2.8080405@lundinova.se> <4D7E2F9F.3080409@lundinova.se> <4D7E8E5F.8070109@landley.net> <4D7F637E.3080605@lundinova.se> <4D7FD946.2040203@landley.net> <4D8152E2.4000307@landley.net> <20110317152344.GM24077@ucc.gu.uwa.edu.au> Message-ID: <4D839085.4080507@lundinova.se> Hi all, @ Matt: Your patch improved it by just a second or two on my rig, so that isn't the bottleneck in my case. @ Peter: I have trouble compiling your code: In file included from fp_mul_comba.c:365: fp_mul_comba_small_set.i: In function `fp_mul_comba_small': fp_mul_comba_small_set.i:1225: internal error--unrecognizable insn: (insn 91872 37787 37788 (set (mem:SI (plus:SI (plus:SI (reg:SI 11 fp) (const_int -4096 [0xfffff000])) (const_int -740 [0xfffffd1c])) 0) (reg:SI 7 r7)) -1 (nil) (nil)) make[1]: *** [fp_mul_comba.o] Error 1 It's likely due to my configuration, but could also be a compatibility issue in your code. Just thought you might want to know. Unfortunately I'm pressed for time and must go with openssl for the time being. It's a monster size-wise, but at 10s it's usable (just). If space becomes an even more of a factor, be assured however that I will revisit dropbear. Thank you all for your input and efforts to help. Kind regards/Magnus On 2011-03-17 16:23, Matt Johnston wrote: > On Wed, Mar 16, 2011 at 07:16:34PM -0500, Rob Landley wrote: >> On 03/16/2011 02:25 AM, Peter Turczak wrote: >>> Hi Magnus, hi Rob, >>> >>> a while ago I made the same observations you did. On an m68k-nommu >>> with 166 MHz the RSA exchange took quite forever. After some >>> profiling I found out the comba multiply routine in libtommath was >>> eating most of the time. It seems gcc produces quite inefficient code >>> there. Libtommath resizes its large integers while calculating >>> leading to more work for user memory management. >> User mememory management? It's got a malloc/free in an inner loop? BARF! >> >> (Yeah, that'll blow your L1 cache wide open and slow stuff down by at >> least an order of magnitude. Allocation functions are some of the most >> cache unfriendly things you can do, pretty much by definition. Unused >> memory is not cache hot, pretty much by definition. That's sort of the >> point. Copying the data sucks too, but it's doing the copying on all >> platforms I'd guess...) > I guess it's possible. Logging in to a server with 1024 bit > RSA and RSA authorized_key I get ~229 reallocs in mp_grow(), > not a massive number if spread over 45 seconds. The patch > below drops it to ~30 reallcs. > > Magnus: It might be worth seeing if it changes your > timing. I haven't looked whether it increases memory usage. > > Matt > > --- libtommath/bn_mp_exptmod_fast.c 5a692f134deeab0992612206c16f8bf970b5088c > +++ libtommath/bn_mp_exptmod_fast.c 5391873ccf8a11171774425c69f584195b4fdba4 > @@ -67,13 +67,13 @@ int mp_exptmod_fast (mp_int * G, mp_int > > /* init M array */ > /* init first cell */ > - if ((err = mp_init(&M[1])) != MP_OKAY) { > + if ((err = mp_init_size(&M[1], P->used)) != MP_OKAY) { > return err; > } > > /* now init the second half of the array */ > for (x = 1<<(winsize-1); x< (1<< winsize); x++) { > - if ((err = mp_init(&M[x])) != MP_OKAY) { > + if ((err = mp_init_size(&M[x], P->alloc+1)) != MP_OKAY) { > for (y = 1<<(winsize-1); y< x; y++) { > mp_clear (&M[y]); > } > @@ -96,7 +96,7 @@ int mp_exptmod_fast (mp_int * G, mp_int > > /* automatically pick the comba one if available (saves quite a few calls/ifs) */ > #ifdef BN_FAST_MP_MONTGOMERY_REDUCE_C > - if (((P->used * 2 + 1)< MP_WARRAY)&& > + if (((P->alloc * 2 + 1)< MP_WARRAY)&& > P->used< (1<< ((CHAR_BIT * sizeof (mp_word)) - (2 * DIGIT_BIT)))) { > redux = fast_mp_montgomery_reduce; > } else > @@ -133,7 +133,7 @@ int mp_exptmod_fast (mp_int * G, mp_int > } > > /* setup result */ > - if ((err = mp_init (&res)) != MP_OKAY) { > + if ((err = mp_init_size (&res, P->used)) != MP_OKAY) { > goto LBL_M; > } > > ============================================================ > --- libtommath/bn_mp_init_copy.c fd7c20c0ee3473615de23c59074cf5c6757a20ca > +++ libtommath/bn_mp_init_copy.c 841949a75e387e818f2f4d9adedff0ba9c9374c0 > @@ -20,7 +20,7 @@ int mp_init_copy (mp_int * a, mp_int * b > { > int res; > > - if ((res = mp_init (a)) != MP_OKAY) { > + if ((res = mp_init_size (a, b->used)) != MP_OKAY) { > return res; > } > return mp_copy (b, a); > ============================================================ > --- libtommath/bn_mp_mod.c 3bed12926c4d019853f2b4dac814a7505580380e > +++ libtommath/bn_mp_mod.c 9265cd0294d2c86f1c3c73eaa5bf19c30403e13b > @@ -22,7 +22,7 @@ mp_mod (mp_int * a, mp_int * b, mp_int * > mp_int t; > int res; > > - if ((res = mp_init (&t)) != MP_OKAY) { > + if ((res = mp_init_size (&t, b->used)) != MP_OKAY) { > return res; > } > > ============================================================ > --- libtommath/bn_mp_mulmod.c 935d0f5903589ddf62f42fc691cb2f83aa2832c4 > +++ libtommath/bn_mp_mulmod.c ef9063432e3a0c62b7118dfc3d01d04cd4dc8bb9 > @@ -21,7 +21,7 @@ int mp_mulmod (mp_int * a, mp_int * b, m > int res; > mp_int t; > > - if ((res = mp_init (&t)) != MP_OKAY) { > + if ((res = mp_init_size (&t, c->used)) != MP_OKAY) { > return res; > } > > From michael.wiedmann at aastra.com Mon Mar 21 18:59:26 2011 From: michael.wiedmann at aastra.com (Michael Wiedmann) Date: Mon, 21 Mar 2011 11:59:26 +0100 Subject: Dropbear - Cygwin - Performance Message-ID: Hi, still struggling with the problem described in a previous post ("Transfer of large files fails on forwarded ports", 2001-01-11). If I use dropbear on a Debian/GNU Linux system, setup remote port forwarding (including "-a"), connect from a client machine (Win, putty) and HTTP GET a file through the tunnel all is like expected - fast. The same setup but the server is a Cygwin/dropbear combination I experience huge performance degradation (at least tenfold, even more). Any hints for this setup? Thanks Michael From redhatter at gentoo.org Tue Mar 22 09:18:05 2011 From: redhatter at gentoo.org (Stuart Longland) Date: Tue, 22 Mar 2011 11:18:05 +1000 Subject: Dropbear - Cygwin - Performance In-Reply-To: References: Message-ID: <20110322011805.GE1016@atomos.longlandclan.yi.org> Hi, On Mon, Mar 21, 2011 at 11:59:26AM +0100, Michael Wiedmann wrote: > The same setup but the server is a Cygwin/dropbear combination I > experience > huge performance degradation (at least tenfold, even more). I wonder if this could be due to some Cygwin quirk? I know for a fact that fork() is quite an expensive operation in Cygwin (no copy-on-write), and I hear its threadding support is somewhat primitive. Maybe that's part of the problem faced? -- Stuart Longland (aka Redhatter, VK4MSL) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' I haven't lost my mind... ...it's backed up on a tape somewhere. From michael.wiedmann at aastra.com Tue Mar 22 15:05:43 2011 From: michael.wiedmann at aastra.com (Michael Wiedmann) Date: Tue, 22 Mar 2011 08:05:43 +0100 Subject: AW: Dropbear - Cygwin - Performance In-Reply-To: <20110322011805.GE1016@atomos.longlandclan.yi.org> References: <20110322011805.GE1016@atomos.longlandclan.yi.org> Message-ID: Hi, On Tue, Mar 22, 2011 at 02:18, Stuart Longland wrote: > I wonder if this could be due to some Cygwin quirk? I know for a fact > that fork() is quite an expensive operation in Cygwin (no > copy-on-write), and I hear its threadding support is somewhat primitive. I'd say that one call to fork() is neglectable. The real problem is the network performance during file transfer through the tunnel. Michael