I no longer can ssh to my router.

[robin_listas]

Hi,

When I had 11.0, I could ssh to my router without problems. When I switched
to 11.2, I no longer could (three machines, one new, two upgraded). I have
also tried from a VM 11.1. Putty in another VM also fails.

11.2:

Code:

cer@Telcontar:~> SSH_AUTH_SOCK="" ssh -v router
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /home/cer/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to router [192.168.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/cer/.ssh/id_rsa type 1
debug1: identity file /home/cer/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version dropbear_0.36
debug1: no match: dropbear_0.36
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client 3des-cbc hmac-md5 none
debug1: kex: client->server 3des-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
Read from socket failed: Connection reset by peer
cer@Telcontar:~>

11.1 virtual machine (vmware):

Code:

eleanor:~ # ssh -v router
OpenSSH_5.1p1, OpenSSL 0.9.8h 28 May 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to router [192.168.1.1] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version dropbear_0.36
debug1: no match: dropbear_0.36
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client 3des-cbc hmac-md5 none
debug1: kex: client->server 3des-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
Write failed: Connection reset by peer
eleanor:~ #

Putty, winme: “internal fault: chaos is SSH2 transport layer” and
“connection closed by remote host”. From XP it says “reset by peer”.

Chances are it is some thing in the router (which accepts telnet and http
without problems, so there is conectivity). The configuration for both
telnet and ssh is the same, open (there are no more settings).

Code:

-> remoteaccess show

remote access for FTP is in LAN side
remote access for HTTP is in LAN side
remote access for ICMP is in WAN & LAN sides
remote access for SNMP is in LAN side
remote access for SSH is in LAN side <===
remote access for TELNET is in LAN side <===
remote access for TFTP is in LAN side

Access Control Mode : enable

IP address Subnet mask Interface
172.20.25.0 255.255.255.0 WAN
172.20.45.0 255.255.255.0 WAN
193.152.37.192 255.255.255.240 WAN
0.0.0.0 0.0.0.0 LAN
80.58.63.128 255.255.255.128 WAN

Hit <enter> to continue

---

The router is a Comtrend ADSL router, model CT-536+. I tried hard reseting
it, and restoring configuration from its backup. No change.

What confuses me is that it worked in 11.0. Some configuration changed,
some default protocol changed?

The only test I can still do is install an 11.0 VM and test from that one…

Ideas?

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

[ken_yap]

All releases of Dropbear SSH | freshmeat.net

Dropbear 0.36 is really old. There is mention of a couple of bugs fixed in 0.38 to do with new connections. And this was back in 2003.

However I realise that you may not be able to update the firmware, so you may have to search to see if there are any workarounds from the client side.

[tsu2]

Also, if I were to guess the real root problem is the version of SSH used for encryption. I don’t know if the OpenSSH libraries for older versions of OpenSuSE can install into 11.3, but that would probably solve your problem.

Guessing,
Tony

[robin_listas]

On 2010-12-05 16:06, ken yap wrote:
>
> ‘All releases of Dropbear SSH | freshmeat.net’
> (http://freshmeat.net/projects/dropbear/releases)
>
> Dropbear 0.36 is -really- old. There is mention of a couple of bugs
> fixed in 0.38 to do with new connections. And this was back in 2003.

The router docs are dated 2005…

So, dropbear is the router side version of sshd. I see.

> However I realise that you may not be able to update the firmware,

No, not really possible. I wouldn’t try unless I had a backup router,
because the ISP doesn’t provide any updates at all, it would have be a
hacked one.

> so
> you may have to search to see if there are any workarounds from the
> client side.

I tried the switches I could think of - no good.

And Tsu2:

> Also, if I were to guess the real root problem is the version of SSH
> used for encryption. I don’t know if the OpenSSH libraries for older
> versions of OpenSuSE can install into 11.3, but that would probably
> solve your problem.

So it is indeed that something has changed on the client side ssh that the
router doesn’t accept. I tried changing the cipher: 3des-cbc doesn’t work,
hmac-md5 is unknown:

cer@Telcontar:~> SSH_AUTH_SOCK="" ssh -v -c hmac-md5 router
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009
Unknown cipher type ‘hmac-md5’
cer@Telcontar:~>

And reverting the openssh library is not something I’m willing to do.

Or have a VM 11.0 for the sole purpose of connecting to the router

I’d rather use telnet :-/

Using triple verbose, I see a bit more:

Code:

…

debug1: Remote protocol version 2.0, remote software version dropbear_0.36
debug1: no match: dropbear_0.36
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: 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@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@lysator.liu.se
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@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
debug2: kex_parse_kexinit: ssh-rsa
debug2: kex_parse_kexinit: 3des-cbc
debug2: kex_parse_kexinit: 3des-cbc
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 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 3des-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server 3des-cbc hmac-md5 none
debug2: dh_gen_key: priv key bits set: 197/384
debug2: bits set: 497/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
Read from socket failed: Connection reset by peer
cer@Telcontar:~>

---

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

[ken_yap]

It looks like a protocol handling bug in dropbear. Not much you can do about it on the router end as you say. Just use telnet until the router dies.

[robin_listas]

On 2010-12-05 23:36, ken yap wrote:
>
> It looks like a protocol handling bug in dropbear. Not much you can do
> about it on the router end as you say. Just use telnet until the router
> dies.

There maybe a bug there, but with 11.0 on my side it worked. It has worked
for years, several openSUSE versions. Something has changed in “our” side.
A bug corrected, a protocol dropped… Even putty fails.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

[ken_yap]

Most likely the ssh clients started doing things correctly, thus exposing the dropbear error.

[robin_listas]

On 2010-12-06 02:06, ken yap wrote:
>
> Most likely the ssh clients started doing things correctly, thus
> exposing the dropbear error.

Quite possible - but the result is worse, because I have to use telnet or
http instead.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

[ken_yap]

Get a sufficiently old release of ssh and build a ssh client just for the use of this ancient router.

The universe doesn’t always arrange things the way we would like.

[glistwan]

You could create a VPN tunnel between You and the router and then you’re safe with telnet

Best regards,
Greg

[robin_listas]

On 2010-12-06 04:36, ken yap wrote:
>
> Get a sufficiently old release of ssh and build a ssh client just for
> the use of this ancient router.

5 years, no, 4 (my config backup is dated 200603), is not that ancient. I
can’t replace all my hardware every 5 years, I’m not Mr Gates, rolling in
gold. It is the router supplied by the ISP, who doesn’t do any updates at
all. :-/

Yes, perhaps I could get an “ancient” ssh version, but then I would also
have to add an old openssh library linked statically. Gosh.

I’ll have a look.

> The universe doesn’t always arrange things the way we would like.

I’ll stick a postit in my monitor to remind you of this when /you/ get hit
next time >:-P

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

[malcolmlewis]

@Carlos E. R.

On 2010-12-06 04:36, ken yap wrote:
>
> Get a sufficiently old release of ssh and build a ssh client just for
> the use of this ancient router.

5 years, no, 4 (my config backup is dated 200603), is not that ancient.
I can’t replace all my hardware every 5 years, I’m not Mr Gates,
rolling in gold. It is the router supplied by the ISP, who doesn’t do
any updates at all. :-/

Yes, perhaps I could get an “ancient” ssh version, but then I would also
have to add an old openssh library linked statically. Gosh.

I’ll have a look.

> The universe doesn’t always arrange things the way we would like.

I’ll stick a postit in my monitor to remind you of this when /you/ get
hit next time >:-P

Hi
What firmware version?
http://www.adslzone.net/comtrend536.html
http://www.softwaredriverdownload.com/download_comtrend_ct_536_driver.html

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.32.24-0.2-default
up 12:15, 2 users, load average: 0.00, 0.04, 0.02
GPU GeForce 8600 GTS Silent - Driver Version: 260.19.21

[ken_yap]

@robin_listas

5 years, no, 4 (my config backup is dated 200603), is not that ancient. I
can’t replace all my hardware every 5 years, I’m not Mr Gates, rolling in
gold. It is the router supplied by the ISP, who doesn’t do any updates at
all. :-/

It’s a tradeoff between your time and your money. If it’s a standard ADSL modem, they are getting cheaper by the day. Otherwise spend your spare time compiling ssh. You probably can use the standard SSL library since the bug appears to be in the protocol engine.

> The universe doesn’t always arrange things the way we would like.

I’ll stick a postit in my monitor to remind you of this when /you/ get hit
next time >:-P

You’d be preaching to the converted.

[robin_listas]

On 2010-12-06 16:03, malcolmlewis wrote:

> Hi
> What firmware version?
> http://www.adslzone.net/comtrend536.html

Software Version: A101-220TLF-C35
Bootloader (CFE) Version: 1.0.37-0.7

The one on display is from the ISP Jazztel, which does have an update.
Telefónica does not, and that’s my case.

They give a link to the manufacturer as
“http://www.comtrend.com/tpl/support-CT-536+.htm”, which gives error 404,
not found.

Searching for “536+” finds nothing.

The download page would be this one:

<http://www.comtrend.com/es/links/i$adsl-modem-router$sndes.htm>

which does not list this router. They say:

+++···················
What if my product is not listed above?
…
If you are an end user, we regret to inform you that we cannot fulfill your
special download request due to contract restrictions and security
concerns. We suggest you contact your service provider or product supplier
for further assistance.
···················+±

So, no updates from them either. I have see updates from third parties, but
I’m hesitant of going that road as I don’t have a backup router, nor can I
re-flash the router with the original firmware, there is no procedure for
that, AFAIK.

I would then, perhaps, prefer to buy a good and cheap home router. Does
such a thing exist?

Ah, you posted two links. Lets see the other one…

>> http://www.softwaredriverdownload.com/download_comtrend_ct_536_driver.html

After bypassing several offers to download some babylon translator
whatever, it would download the file “CT-536B-A101-302JAZ-C01_R05.bin2121
KB” which is the jaztel firmware. No good for me.

But thank you for your effort, that was nice.

I could update from here, instead:

<http://www.adslzone.net/firmware-adslzone-poligon.html>

which is a compatible hacked firmware (beta). It is a risk I might take if
I had more problems or expected much more advantages.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

[robin_listas]

On 2010-12-06 16:36, ken yap wrote:

> It’s a tradeoff between your time and your money. If it’s a standard
> ADSL modem, they are getting cheaper by the day.

I know, I know. :-}

But I hate to play that game. You know that we buy a lot of hardware:
computer, display, keyboard, storage devices, printer, scanner, router,
telephone, camera… It is a waste to consider a gadget as too old after 4
years. I can accept not having the most modern features, but I hate losing
a feature that worked when originally bought, because “they” change something.

And cheap… I think it is 50…100 €. My economy is not precisely buoyant
these hard times. I have more time than money.

> Otherwise spend your
> spare time compiling ssh. You probably can use the standard SSL library
> since the bug appears to be in the protocol engine.

I think I’ll try, just to learn if it is that.

>>> The universe doesn’t always arrange things the way we would like.
>>
>> I’ll stick a postit in my monitor to remind you of this when /you/ get
>> hit next time >:-P
>
> You’d be preaching to the converted.

:-}

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

[malcolmlewis]

@Carlos E. R.

On 2010-12-06 16:03, malcolmlewis wrote:
But thank you for your effort, that was nice.

I could update from here, instead:

<http://www.adslzone.net/firmware-adslzone-poligon.html&gt;

which is a compatible hacked firmware (beta). It is a risk I might take
if I had more problems or expected much more advantages.

Hi
Oh well worth a shot, wasn’t sure

Might be time to look at a newer router then?? Maybe just bridge that
one and use your own? That’s what I do, the ISP one is over 5 years
old, but just running in bridged mode to my linksys WRT54G.

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.32.24-0.2-default
up 17:59, 2 users, load average: 0.10, 0.05, 0.01
GPU GeForce 8600 GTS Silent - Driver Version: 260.19.21

[ken_yap]

@robin_listas

I can accept not having the most modern features, but I hate losing
a feature that worked when originally bought, because “they” change something.

These things happen and nobody can be blamed. The manufacturer puts in a version of dropbear, and later, bugs are found in it because some corner cases were not correctly handled, but it’s too late to update all those routers in the field. For a piece of hardware, you’d think they would use the most recent release instead of one 2 years old, but probably the firmware development was frozen.

Once upon a time there were a lot of routers using a broken DNS proxy software called dnrd, whose development was discontinued some time ago. Unfortunately the bug was to mishandle A records when AAAA records existed for that domain name. While no desktop OSes sent out these queries this was not a problem. Then glibc’s resolver stub library started sending AAAA queries and got back garbage for A records. Unfortunately there was no way to turn off this query behaviour of glibc, not that I could find. The only thing I could do was to not use the router’s DNS proxy. It wasn’t even my router so I couldn’t say go buy a new one, unless I was willing to pay for it. However it died sometime later which “solved” that problem.

[robin_listas]

On 2010-12-06 21:47, malcolmlewis wrote:

> Might be time to look at a newer router then?? Maybe just bridge that
> one and use your own? That’s what I do, the ISP one is over 5 years
> old, but just running in bridged mode to my linksys WRT54G.

Not worth it, yet. It is my home network, I can risk using telnet, as long
as I don’t use wifi for configuring the router.

I would consider getting a router with more “mouths”, four are too few. By
your method it would have to be 1 input to several outputs, wifi, firewall
et al. Two devices. I prefer one gadget more capable.

But as I said, I can’t really justify the expense. Yet.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

[robin_listas]

On 2010-12-07 00:06, ken yap wrote:
>
> robin_listas;2262462 Wrote:
>> I can accept not having the most modern features, but I hate losing
>> a feature that worked when originally bought, because “they” change
>> something.
>
> These things happen and nobody can be blamed. The manufacturer puts in
> a version of dropbear, and later, bugs are found in it because some
> corner cases were not correctly handled, but it’s too late to update all
> those routers in the field. For a piece of hardware, you’d think they
> would use the most recent release instead of one 2 years old, but
> probably the firmware development was frozen.

The don’t have to update every device, just offer the update image for
anybody wanting to do it. In this case, it is the responsibility of the ISP
to request that upgrade. And yes, they can be blamed, we have a law in
Spain that electronics devices have to be maintained for I don’t remember
how many years. But it doesn’t happen, at worst they return the money a
year later. And in this case I would have to fight it and I wouldn’t be
able to prove it.

> Once upon a time there were a lot of routers using a broken DNS proxy
> software called dnrd, whose development was discontinued some time ago.
> Unfortunately the bug was to mishandle A records when AAAA records
> existed for that domain name. While no desktop OSes sent out these
> queries this was not a problem. Then glibc’s resolver stub library
> started sending AAAA queries and got back garbage for A records.
> Unfortunately there was no way to turn off this query behaviour of
> glibc, not that I could find. The only thing I could do was to not use
> the router’s DNS proxy. It wasn’t even my router so I couldn’t say go
> buy a new one, unless I was willing to pay for it.

Argh

> However it died
> sometime later which “solved” that problem.

So, it happened to you, and much worse.

By the way, I’m trying to recompile ssh from 11.0 - but I can’t find the
sources. If you know where, speak

So I’m installing 11.0 in a virtual machine to see if it really can connect
to the router. …] Yes, it can, no problem.

And there is no difference in the debug output, till the router disconnects
(in 11.1 or 11.2). Below is the output in 11.0:

Code:

linux-lwmd:~ # ssh -v 1234@192.168.1.1
OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version dropbear_0.36
debug1: no match: dropbear_0.36
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client 3des-cbc hmac-md5 none
debug1: kex: client->server 3des-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host ‘192.168.1.1’ is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password
debug1: Next authentication method: password
1234@192.168.1.1’s password:

With this proof, I could open a bugzilla >:-)

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

[lwfinger]

On 12/06/2010 09:50 PM, Carlos E. R. wrote:
> On 2010-12-07 00:06, ken yap wrote:
>>
>> robin_listas;2262462 Wrote:
>>> I can accept not having the most modern features, but I hate losing
>>> a feature that worked when originally bought, because “they” change
>>> something.
>>
>> These things happen and nobody can be blamed. The manufacturer puts in
>> a version of dropbear, and later, bugs are found in it because some
>> corner cases were not correctly handled, but it’s too late to update all
>> those routers in the field. For a piece of hardware, you’d think they
>> would use the most recent release instead of one 2 years old, but
>> probably the firmware development was frozen.
>
>
> The don’t have to update every device, just offer the update image for
> anybody wanting to do it. In this case, it is the responsibility of the ISP
> to request that upgrade. And yes, they can be blamed, we have a law in
> Spain that electronics devices have to be maintained for I don’t remember
> how many years. But it doesn’t happen, at worst they return the money a
> year later. And in this case I would have to fight it and I wouldn’t be
> able to prove it.
>
>
>> Once upon a time there were a lot of routers using a broken DNS proxy
>> software called dnrd, whose development was discontinued some time ago.
>> Unfortunately the bug was to mishandle A records when AAAA records
>> existed for that domain name. While no desktop OSes sent out these
>> queries this was not a problem. Then glibc’s resolver stub library
>> started sending AAAA queries and got back garbage for A records.
>> Unfortunately there was no way to turn off this query behaviour of
>> glibc, not that I could find. The only thing I could do was to not use
>> the router’s DNS proxy. It wasn’t even my router so I couldn’t say go
>> buy a new one, unless I was willing to pay for it.
>
> Argh
>
>> However it died
>> sometime later which “solved” that problem.
>
> So, it happened to you, and much worse.
>
> By the way, I’m trying to recompile ssh from 11.0 - but I can’t find the
> sources. If you know where, speak
>
>
> So I’m installing 11.0 in a virtual machine to see if it really can connect
> to the router. …] Yes, it can, no problem.
>
> And there is no difference in the debug output, till the router disconnects
> (in 11.1 or 11.2). Below is the output in 11.0:
>
> Code:
> -------------------
> linux-lwmd:~ # ssh -v 1234@192.168.1.1
> OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22.
> debug1: Connection established.
> debug1: permanently_set_uid: 0/0
> debug1: identity file /root/.ssh/id_rsa type -1
> debug1: identity file /root/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version dropbear_0.36
> debug1: no match: dropbear_0.36
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.0
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client 3des-cbc hmac-md5 none
> debug1: kex: client->server 3des-cbc hmac-md5 none
> debug1: sending SSH2_MSG_KEXDH_INIT
> debug1: expecting SSH2_MSG_KEXDH_REPLY
> debug1: Host ‘192.168.1.1’ is known and matches the RSA host key.
> debug1: Found key in /root/.ssh/known_hosts:1
> debug1: ssh_rsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: password
> debug1: Next authentication method: password
> 1234@192.168.1.1’s password:
> -------------------
>
> With this proof, I could open a bugzilla >:-)

Have you tried building and using OpenSSH
(http://www.openssh.com/portable.html)? I just built the latest version with no
missing dependencies.