[Cerowrt-devel] dropbear stops working
mcr at sandelman.ca
Sun Jan 12 19:20:43 EST 2014
Hi, I was running 3.8 until two weeks ago. I had a problem that had
developed where by dropbear (ssh daemon) simply stopped being willing to
accept logins. I still had access through the web ui, but it's hard to
investigate problems that way...
I flashed a new 3800 with 3.10 back on Dec. 25th, and all was well.
I could ssh in, no problem. I went to ssh today, and I get the same
problem as before... My experience from before was that a reboot did *not*
solve the problem.
ssh -v gives me:
obiwan-[~/galaxy/orlando/r6743] mcr 10015 %ssh -v root at budmgmt
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /home/mcr/.ssh/config
debug1: /home/mcr/.ssh/config line 170: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to budmgmt [172.30.42.1] port 22.
debug1: Connection established.
debug1: identity file /home/mcr/.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/mcr/.ssh/id_rsa-cert type -1
debug1: identity file /home/mcr/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-2048
debug1: identity file /home/mcr/.ssh/id_dsa-cert type -1
debug1: identity file /home/mcr/.ssh/id_ecdsa type -1
debug1: identity file /home/mcr/.ssh/id_ecdsa-cert type -1
ssh_exchange_identification: Connection closed by remote host
 17811 exit 255 ssh -v root at budmgmt
I typically operate with about 6 private keys loaded into ssh-agent on my
desktop. On a whim I tried unset SSH_AUTH_SOCK in a fresh shell, but
that didn't change things, nor did combinations after that of things like:
%ssh -i ~/.ssh/id_dsa -v root at budmgmt
on the "budmgmt" IP (the 172.30.42.1 untagged on 3800), I should even be able
to login with a password, but it never gets to that point. I'm thinking that
either something has filled up in a way that survives reboots.
When I had this problem before, I tried starting a new copy of dropbear
From the Network/Fireall/Custom Rules file, since that is a shell
script I can hack:
dropbear -p 2221 &
but that didn't work (nothing listening on port 2221).
I can see nothing in the logs (which also come via UDP/syslog to my desktop).
I'm looking for any advice on how to:
a) restore my ssh access.
b) get better diagnostics from dropbear.
Failing this, I'll upgrade the other unit, restore my settings, and test
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 307 bytes
Desc: not available
More information about the Cerowrt-devel