Hello devs, i stumbled upon a rare but very exasperating bug in openwrt's dropbear,
steps to reproduce: connecting from a debian7 with openssh-client_1:6.6p1-4~bpo70 to an openwrt bb-rc3 running dropbear 2014.63 as server with agent forwarding enabled on client, then try to "daisy-chain" into another host [debian7]-->[openwrtA]-->[openwrtB] so, ssh into openwrtA, and from there do "ssh openwrtB" expected behaviour (this works with dropbear_2012.55): successfully login into openwrtB without being asked for a password, since openwrtA's dropbear forwards the credentials from debian7 to openwrtB actual behaviour: (with 2014.63, and also 2013.59 IIRC) openwrtA dropbear client hangs for a minute or more, finally dying with a timeout error. --- i'm so used to using pubkeys, that it never ocurred to me that it'd make a difference to disable agent forwarding. Today i discovered that if I disable agent forwarding on my openssh-client, then connect to openwrtA, and from there ssh into openwrtB, it will ask for a password and let me login just fine. Hope that serves as a pointer in the right direction :) attached you'll find two pcaps, taken with tcpdump on openwrtA. in the first one, to simplify the setup, i simply did "ssh localhost" (so openwrtA = openwrtB) which works as expected in 2012.55, and produces this bizarre pcap in 2014.63. as a contrast, i also send the result of doing "ssh debian7" (192.168.1.234) from openwrtA. openssh-server reacts just fine, and i can login back to my computer from dropbear-client running on openwrtA in both cases, agent forwarding was enabled on my debian7 openssh-client hope i didn't confuse the hell out of you, sorry to ruin your delightful weekend with such an intricate report, and thanks in advance for any help :) cheers! gui
dropbear_2014.63_ssh-localhost-on-openwrt-trunk.cap
Description: application/vnd.tcpdump.pcap
dropbear_2014.63_ssh-wheezy-from-openwrt-trunk.cap
Description: application/vnd.tcpdump.pcap
