[Cerowrt-devel] dropbear stops working
dave.taht at gmail.com
Tue Sep 16 08:19:10 EDT 2014
It is highly likely you ran out of flash space. As best as I recall,
babel then was logging to flash, which we fixed somewhere around
You might be able to get somewhere by deleting that log file.
On Mon, Jan 13, 2014 at 2:20 AM, Michael Richardson <mcr at sandelman.ca> wrote:
> 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
> things daily.
> ] 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 [
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
More information about the Cerowrt-devel