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@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
[2]    17811 exit 255   ssh -v root@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@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
things daily.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [