[Buildroot] simple question about dropbear

[Buildroot] simple question about dropbear

[Johannes Teiwes]

Good morning!

I have dropbear configured to run on my target system. The deamon process shows up in the process list. But as soon as i connect from the outside via ssh the spawned dropbear process takes up 100% cpu and never releases is, even when the external connection request gets canceled.
I have tried to use the generated rsa/dss keys, login as a regular user (non root) but its not changing anything.
Have i overlooked something? Does dropbear has a config like the openssh module which can forbid (root-)login per default?

Kind regards, 
Johannes
--
Johannes Teiwes - jteiwes at tzi.de



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120210/c1278c5c/attachment.html>

[Buildroot] simple question about dropbear

[Peter Korsgaard]

>>>>> "Johannes" == Johannes Teiwes <jteiwes@informatik.uni-bremen.de> writes:

 Johannes> Good morning!

 Johannes> I have dropbear configured to run on my target system. The
 Johannes> deamon process shows up in the process list. But as soon as i
 Johannes> connect from the outside via ssh the spawned dropbear process
 Johannes> takes up 100% cpu and never releases is, even when the
 Johannes> external connection request gets canceled.  I have tried to
 Johannes> use the generated rsa/dss keys, login as a regular user (non
 Johannes> root) but its not changing anything.  Have i overlooked
 Johannes> something? Does dropbear has a config like the openssh module
 Johannes> which can forbid (root-)login per default?

It works fine here. Could you enable strace and use it to see what the
dropbear process is doing?

-- 
Bye, Peter Korsgaard

[Buildroot] simple question about dropbear

[Johannes Teiwes]

Am 10.02.2012 um 11:44 schrieb Peter Korsgaard:

>>>>>> "Johannes" == Johannes Teiwes <jteiwes@informatik.uni-bremen.de> writes:
> 
> Johannes> Good morning!
> 
> Johannes> I have dropbear configured to run on my target system. The
> Johannes> deamon process shows up in the process list. But as soon as i
> Johannes> connect from the outside via ssh the spawned dropbear process
> Johannes> takes up 100% cpu and never releases is, even when the
> Johannes> external connection request gets canceled.  I have tried to
> Johannes> use the generated rsa/dss keys, login as a regular user (non
> Johannes> root) but its not changing anything.  Have i overlooked
> Johannes> something? Does dropbear has a config like the openssh module
> Johannes> which can forbid (root-)login per default?
> 
> It works fine here. Could you enable strace and use it to see what the
> dropbear process is doing?
> 
> -- 
> Bye, Peter Korsgaard


I managed to get strace running after digging a patch for my architecture (microblaze) but the output of tracing dropbear is not of great value.. i guess, that this is because the kernel is not compiled with tracing support - So the next problem, which arises then, is that the kernel (linux-2.6-xlnx) i am using does not support tracing (but i am still trying to find a workaroud for that)

Nonetheless, i attached strace to the /usr/sbin/dropbear process, which is running from the start. Then i started a ssh connection from another computer and this is whats happened:

# strace -p 58 -f
Process 58 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 0
restart_syscall(<... resuming interrupted call ...>) = 0
restart_syscall(<... resuming interrupted call ...>) = 0
restart_syscall(<... resuming interrupted call ...>) = 0
restart_syscall(<... resuming interrupted call ...>) = 0
restart_syscall(<... resuming interrupted call ...>) = 0
restart_syscall(<... resuming interrupted call ...> <unfinished ...>
Process 58 detached
#

So far i can only tell, that dropbear gets stuck in the 7th system call it issues. Any ideas, which/what that could be?

--
Johannes Teiwes - jteiwes at tzi.de



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120213/b2ec8f71/attachment.html>

[Buildroot] simple question about dropbear

[Spenser Gilliland]

Johannes,

I'm having a similar issue with dropbear and have switched to the
openssh server for now.  What patches are you using for microblaze
strace?  I'd like to add them to my build.

To add to this discussion on the client, ssh -vv returns the following
before stalling.

spenser at bourban:~/Code/buildroot/board/ecasp/ausp$ ssh -vv root at 192.168.1.117
OpenSSH_5.9p1 Debian-2ubuntu2, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.117 [192.168.1.117] port 22.
debug1: Connection established.
debug1: identity file /home/spenser/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/spenser/.ssh/id_rsa-cert type -1
debug1: identity file /home/spenser/.ssh/id_dsa type -1
debug1: identity file /home/spenser/.ssh/id_dsa-cert type -1
debug1: identity file /home/spenser/.ssh/id_ecdsa type -1
debug1: identity file /home/spenser/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version dropbear_2011.54
debug1: no match: dropbear_2011.54
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-2ubuntu2
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit:
ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,blowfish-cbc
debug2: kex_parse_kexinit:
aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: zlib,zlib at openssh.com,none
debug2: kex_parse_kexinit: zlib,zlib at openssh.com,none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug2: dh_gen_key: priv key bits set: 123/256
debug2: bits set: 983/2048
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY

Spenser


On Mon, Feb 13, 2012 at 6:43 AM, Johannes Teiwes
<jteiwes@informatik.uni-bremen.de> wrote:
> Am 10.02.2012 um 11:44 schrieb Peter Korsgaard:
>
> "Johannes" == Johannes Teiwes <jteiwes@informatik.uni-bremen.de> writes:
>
>
> Johannes> Good morning!
>
> Johannes> I have dropbear configured to run on my target system. The
> Johannes> deamon process shows up in the process list. But as soon as i
> Johannes> connect from the outside via ssh the spawned dropbear process
> Johannes> takes up 100% cpu and never releases is, even when the
> Johannes> external connection request gets canceled. ?I have tried to
> Johannes> use the generated rsa/dss keys, login as a regular user (non
> Johannes> root) but its not changing anything. ?Have i overlooked
> Johannes> something? Does dropbear has a config like the openssh module
> Johannes> which can forbid (root-)login per default?
>
> It works fine here. Could you enable strace and use it to see what the
> dropbear process is doing?
>
> --
> Bye, Peter Korsgaard
>
>
> I managed to get strace running after digging a patch for my architecture
> (microblaze) but the output of tracing dropbear is not of great value.. i
> guess, that this is because the kernel is not compiled with tracing support
> - So the next problem, which arises then, is that the kernel
> (linux-2.6-xlnx) i am using does not support tracing (but i am still trying
> to find a workaroud for that)
>
> Nonetheless, i attached strace to the /usr/sbin/dropbear process, which is
> running from the start. Then i started a ssh connection from another
> computer and this is whats happened:
>
> # strace -p 58 -f
> Process 58 attached - interrupt to quit
> restart_syscall(<... resuming interrupted call ...>) = 0
> restart_syscall(<... resuming interrupted call ...>) = 0
> restart_syscall(<... resuming interrupted call ...>) = 0
> restart_syscall(<... resuming interrupted call ...>) = 0
> restart_syscall(<... resuming interrupted call ...>) = 0
> restart_syscall(<... resuming interrupted call ...>) = 0
> restart_syscall(<... resuming interrupted call ...> <unfinished ...>
> Process 58 detached
> #
>
> So far i can only tell, that dropbear gets stuck in the 7th system call it
> issues. Any ideas, which/what that could be?
>
> --
> Johannes Teiwes -?jteiwes at tzi.de
>
>
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot



-- 
Spenser Gilliland
Computer Engineer
Illinois Institute of Technology

[Buildroot] simple question about dropbear

[Peter Korsgaard]

>>>>> "Spenser" == Spenser Gilliland <spenser309@gmail.com> writes:

 Spenser> Johannes,
 Spenser> I'm having a similar issue with dropbear and have switched to the
 Spenser> openssh server for now.  What patches are you using for microblaze
 Spenser> strace?  I'd like to add them to my build.

So it might be a microblaze specific issue? This is Microblaze with mmu,
right?

 Spenser> debug1: sending SSH2_MSG_KEXDH_INIT
 Spenser> debug1: expecting SSH2_MSG_KEXDH_REPLY

This is afaik here were it generates the session key. Are you sure it
isn't just slow? Do you have BR2_PACKAGE_DROPBEAR_SMALL enabled?

There recently was some discussion about it on the dropbear list:

http://thread.gmane.org/gmane.network.ssh.dropbear/1018

-- 
Bye, Peter Korsgaard

[Buildroot] simple question about dropbear

[Peter Korsgaard]

>>>>> "Spenser" == Spenser Gilliland <spenser309@gmail.com> writes:

Please keep buildroot discussion on the buildroot list, thanks.

 Spenser> Considering how slow the microblaze is compared to the arm it
 Spenser> will prob take 3-4 min for login.? Ill apply that patch in the
 Spenser> other thread and see if it works any better.

Ok, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] simple question about dropbear

[Spenser Gilliland]

Added the patch from the other thread but it did not help. The login
timeout after 14min and was stuck on the same point according to ssh
-vv.

Spenser

On Mon, Feb 13, 2012 at 3:31 PM, Peter Korsgaard <jacmet@sunsite.dk> wrote:
>>>>>> "Spenser" == Spenser Gilliland <spenser309@gmail.com> writes:
>
> Please keep buildroot discussion on the buildroot list, thanks.
>
> ?Spenser> Considering how slow the microblaze is compared to the arm it
> ?Spenser> will prob take 3-4 min for login.? Ill apply that patch in the
> ?Spenser> other thread and see if it works any better.
>
> Ok, thanks.
>
> --
> Bye, Peter Korsgaard



-- 
Spenser Gilliland
Computer Engineer
Illinois Institute of Technology

[Buildroot] simple question about dropbear

[Peter Korsgaard]

>>>>> "Spenser" == Spenser Gilliland <spenser309@gmail.com> writes:

 Spenser> Added the patch from the other thread but it did not help. The login
 Spenser> timeout after 14min and was stuck on the same point according to ssh
 Spenser> -vv.

Ok :/ Worth a try though.

-- 
Bye, Peter Korsgaard

[Buildroot] simple question about dropbear

[Johannes Teiwes]

Hi Peter,

Am 13.02.2012 um 21:38 schrieb Peter Korsgaard:

>>>>>> "Spenser" == Spenser Gilliland <spenser309@gmail.com> writes:
> 
> Spenser> Johannes,
> Spenser> I'm having a similar issue with dropbear and have switched to the
> Spenser> openssh server for now.  What patches are you using for microblaze
> Spenser> strace?  I'd like to add them to my build.
> 
> So it might be a microblaze specific issue? This is Microblaze with mmu,
> right?

Yes, you're right. But i have problems investigating what the system is
actually doing when stalling the ssh-connection.

> 
> Spenser> debug1: sending SSH2_MSG_KEXDH_INIT
> Spenser> debug1: expecting SSH2_MSG_KEXDH_REPLY
> 
> This is afaik here were it generates the session key. Are you sure it
> isn't just slow? Do you have BR2_PACKAGE_DROPBEAR_SMALL enabled?

I have also BR2_PACKAGE_DROPBEAR_SMALL enabled in my configuration.
The 'slowness' can be the cause since the microblaze machine only runs at about 66MHz.

Is there any way to convince dropbear/ssh to use a small (or precomputed) session key?
If this is possible one could check, if the system-speed is really the limiting factor.

> 
> There recently was some discussion about it on the dropbear list:
> 
> http://thread.gmane.org/gmane.network.ssh.dropbear/1018
> 
> -- 
> Bye, Peter Korsgaard

Any other ideas? 
I am using static device tables and the default dev_table as my structure - maybe 
there are some devices missing or misconfigured for doing ssh right out of the box?

thanks so far,
Johannes

--
Johannes Teiwes - jteiwes at tzi.de



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120214/2b4e62be/attachment.html>

[Buildroot] simple question about dropbear

[Peter Korsgaard]

>>>>> "Johannes" == Johannes Teiwes <jteiwes@informatik.uni-bremen.de> writes:

Hi,

 Johannes> I have also BR2_PACKAGE_DROPBEAR_SMALL enabled in my
 Johannes> configuration.  The 'slowness' can be the cause since the
 Johannes> microblaze machine only runs at about 66MHz.

 Johannes> Is there any way to convince dropbear/ssh to use a small (or
 Johannes> precomputed) session key?  If this is possible one could
 Johannes> check, if the system-speed is really the limiting factor.

Not afaik. You could try disabling DROPBEAR_SMALL and rebuild dropbear
(rm -rf output/build/dropbear-*; make)

 Johannes> I am using static device tables and the default dev_table as
 Johannes> my structure - maybe there are some devices missing or
 Johannes> misconfigured for doing ssh right out of the box?

No, it should afaik work out of the box. Does it put anything sensible
in /var/log/messages?

-- 
Bye, Peter Korsgaard

[Buildroot] simple question about dropbear

[Johannes Teiwes]

Hi Peter, 

Am 14.02.2012 um 10:55 schrieb Peter Korsgaard:

>>>>>> "Johannes" == Johannes Teiwes <jteiwes@informatik.uni-bremen.de> writes:
> 
> Hi,
> 
> Johannes> I have also BR2_PACKAGE_DROPBEAR_SMALL enabled in my
> Johannes> configuration.  The 'slowness' can be the cause since the
> Johannes> microblaze machine only runs at about 66MHz.
> 
> Johannes> Is there any way to convince dropbear/ssh to use a small (or
> Johannes> precomputed) session key?  If this is possible one could
> Johannes> check, if the system-speed is really the limiting factor.
> 
> Not afaik. You could try disabling DROPBEAR_SMALL and rebuild dropbear
> (rm -rf output/build/dropbear-*; make)

Disabling the .._SMALL option and rebuilding didn't help either :/ (same behavior)

> 
> Johannes> I am using static device tables and the default dev_table as
> Johannes> my structure - maybe there are some devices missing or
> Johannes> misconfigured for doing ssh right out of the box?
> 
> No, it should afaik work out of the box. Does it put anything sensible
> in /var/log/messages?

Nothing special so far:

Jan  1 00:01:07 **** authpriv.info dropbear[64]: Child connection from 192.168.xxx.xxx:50429
Jan  1 00:11:42 **** authpriv.info dropbear[64]: Exit before auth: Timeout before auth

> 
> -- 
> Bye, Peter Korsgaard

I think i go for a test drive with openssh.

--
Johannes Teiwes - jteiwes at tzi.de



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120214/8617413d/attachment.html>

[Buildroot] simple question about dropbear

[Johannes Teiwes]

Hi Spenser,

I also tried the -vv flag on ssh and the result was quite similar to yours - before connection stalls the last thing the client sees is this: 

----->8----
debug1: kex: client->server aes128-ctr hmac-md5 none
debug2: dh_gen_key: priv key bits set: 127/256
debug2: bits set: 994/2048
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
...

After ~10m the connection is closed by dropbear.

Regarding the strace-patch: i found it over the strace dev-list (http://www.mail-archive.com/strace-devel at lists.sourceforge.net/msg01692.html). It seems to be included in the most recent version (4.6) of strace but this version is giving me errors when i include it into buildroot directly. So i put my reworked patch file into the package/strace/ folder for version 3.5.20. I attach the patch file to this mail, not sure if this will work on the mailing list ;-).



There are still some warnings during the build of strace but simple monitoring (e.g. exec time) is working.

Am 13.02.2012 um 19:53 schrieb Spenser Gilliland:

> Johannes,
> 
> I'm having a similar issue with dropbear and have switched to the
> openssh server for now.  What patches are you using for microblaze
> strace?  I'd like to add them to my build.
> 
> To add to this discussion on the client, ssh -vv returns the following
> before stalling.
> 
> spenser at bourban:~/Code/buildroot/board/ecasp/ausp$ ssh -vv root at 192.168.1.117
> OpenSSH_5.9p1 Debian-2ubuntu2, OpenSSL 1.0.0e 6 Sep 2011
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to 192.168.1.117 [192.168.1.117] port 22.
> debug1: Connection established.
> debug1: identity file /home/spenser/.ssh/id_rsa type 1
> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
> debug1: identity file /home/spenser/.ssh/id_rsa-cert type -1
> debug1: identity file /home/spenser/.ssh/id_dsa type -1
> debug1: identity file /home/spenser/.ssh/id_dsa-cert type -1
> debug1: identity file /home/spenser/.ssh/id_ecdsa type -1
> debug1: identity file /home/spenser/.ssh/id_ecdsa-cert type -1
> debug1: Remote protocol version 2.0, remote software version dropbear_2011.54
> debug1: no match: dropbear_2011.54
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-2ubuntu2
> debug2: fd 3 setting O_NONBLOCK
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug2: kex_parse_kexinit:
> ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit:
> ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit:
> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
> debug2: kex_parse_kexinit:
> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib
> debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: kex_parse_kexinit:
> diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit:
> aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,blowfish-cbc
> debug2: kex_parse_kexinit:
> aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,blowfish-cbc
> debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5
> debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5
> debug2: kex_parse_kexinit: zlib,zlib at openssh.com,none
> debug2: kex_parse_kexinit: zlib,zlib at openssh.com,none
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: mac_setup: found hmac-md5
> debug1: kex: server->client aes128-ctr hmac-md5 none
> debug2: mac_setup: found hmac-md5
> debug1: kex: client->server aes128-ctr hmac-md5 none
> debug2: dh_gen_key: priv key bits set: 123/256
> debug2: bits set: 983/2048
> debug1: sending SSH2_MSG_KEXDH_INIT
> debug1: expecting SSH2_MSG_KEXDH_REPLY
> 
> Spenser
> 
> 
> On Mon, Feb 13, 2012 at 6:43 AM, Johannes Teiwes
> <jteiwes@informatik.uni-bremen.de> wrote:
>> Am 10.02.2012 um 11:44 schrieb Peter Korsgaard:
>> 
>> "Johannes" == Johannes Teiwes <jteiwes@informatik.uni-bremen.de> writes:
>> 
>> 
>> Johannes> Good morning!
>> 
>> Johannes> I have dropbear configured to run on my target system. The
>> Johannes> deamon process shows up in the process list. But as soon as i
>> Johannes> connect from the outside via ssh the spawned dropbear process
>> Johannes> takes up 100% cpu and never releases is, even when the
>> Johannes> external connection request gets canceled.  I have tried to
>> Johannes> use the generated rsa/dss keys, login as a regular user (non
>> Johannes> root) but its not changing anything.  Have i overlooked
>> Johannes> something? Does dropbear has a config like the openssh module
>> Johannes> which can forbid (root-)login per default?
>> 
>> It works fine here. Could you enable strace and use it to see what the
>> dropbear process is doing?
>> 
>> --
>> Bye, Peter Korsgaard
>> 
>> 
>> I managed to get strace running after digging a patch for my architecture
>> (microblaze) but the output of tracing dropbear is not of great value.. i
>> guess, that this is because the kernel is not compiled with tracing support
>> - So the next problem, which arises then, is that the kernel
>> (linux-2.6-xlnx) i am using does not support tracing (but i am still trying
>> to find a workaroud for that)
>> 
>> Nonetheless, i attached strace to the /usr/sbin/dropbear process, which is
>> running from the start. Then i started a ssh connection from another
>> computer and this is whats happened:
>> 
>> # strace -p 58 -f
>> Process 58 attached - interrupt to quit
>> restart_syscall(<... resuming interrupted call ...>) = 0
>> restart_syscall(<... resuming interrupted call ...>) = 0
>> restart_syscall(<... resuming interrupted call ...>) = 0
>> restart_syscall(<... resuming interrupted call ...>) = 0
>> restart_syscall(<... resuming interrupted call ...>) = 0
>> restart_syscall(<... resuming interrupted call ...>) = 0
>> restart_syscall(<... resuming interrupted call ...> <unfinished ...>
>> Process 58 detached
>> #
>> 
>> So far i can only tell, that dropbear gets stuck in the 7th system call it
>> issues. Any ideas, which/what that could be?
>> 
>> --
>> Johannes Teiwes - jteiwes at tzi.de
>> 
>> 
>> 
>> 
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
> 
> 
> 
> -- 
> Spenser Gilliland
> Computer Engineer
> Illinois Institute of Technology

--
Johannes Teiwes - jteiwes at tzi.de



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120214/55fada80/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strace-add-microblaze-arch.patch
Type: application/octet-stream
Size: 40650 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120214/55fada80/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120214/55fada80/attachment-0003.html>