Taking too long to connect to SSH

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Upgrade firmware to v1.3.2-20111019
2. Try to connect to SSH

What is the expected output? What do you see instead?
Expected: fast password request
Seeing instead: it takes about 10 seconds until password request

Checking dropbear's log from stderr might be useful. This requires editing 
dropbear's init.d file

Original issue reported on code.google.com by mendelso...@gmail.com on 22 Aug 2012 at 5:44

[GoogleCodeExporter]

It seems to be cpu bound, if you watch top -d 1 during that period dropbear is 
pegging the cpu. Did it go faster with older versions?

There are compile time options for balancing size and performance. I guess I 
could try to see if it makes a difference.

Original comment by stefansc...@googlemail.com on 23 Aug 2012 at 10:33

[GoogleCodeExporter]

Yes, it was going faster on the previous versions. I don't remember noticing 
such a long delay as it has now.

Original comment by mendelso...@gmail.com on 23 Aug 2012 at 7:24

[GoogleCodeExporter]

I just saw on Pietro Leone's thread that v1.3.2-20111019 is able to perform 
public key authentication. Maybe the implementation of this auth method might 
be the cause of this weird behavior.

Original comment by mendelso...@gmail.com on 23 Aug 2012 at 7:32

[GoogleCodeExporter]

No, that doesn't seem to be it. It's still slow with it disabled.

Original comment by stefansc...@googlemail.com on 24 Aug 2012 at 6:50

[GoogleCodeExporter]

I think I found the problem. Dropbear 0.53 added a second key exchange method 
"diffie-hellman-group14-sha1", which is stronger but also more cpu intensive.

If you want to to force the weaker method add -o "KexAlgorithms 
diffie-hellman-group1-sha1" to the ssh/scp command line.

Original comment by stefansc...@googlemail.com on 25 Aug 2012 at 12:51

[GoogleCodeExporter]

It worked like a charm!

But IMHO this issue has potential to harm the processor by frying it on a 
bruteforce attack.

What do you think about removing the support for this key exchange or setting a 
default configuration entry disabling it?

Original comment by mendelso...@gmail.com on 25 Aug 2012 at 1:49

[GoogleCodeExporter]

Heh.. transmission is already doing a good job of keeping the cpu busy most of 
the time, so that shouldn't hurt.

There's no option, so removing support for it means patching the source, it 
looks like a trivial change though. I could also try to add a command line 
option.

Original comment by stefansc...@googlemail.com on 26 Aug 2012 at 11:48

[GoogleCodeExporter]

Ok, I added an option (-x) to dropbear for limiting the key exchange method to 
group 1. It's a bit crude but it works. 

In snake this can be turned on from Services->ssh. By default it's disabled.

Original comment by stefansc...@googlemail.com on 29 Aug 2012 at 6:04