x/crypto/ssh: problem with Dropbear tunnel

[gopherbot]

by Metal3d:

What does 'go version' print?

go version go1.3 linux/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. http://play.golang.org/p/CLWHYVgBQs
2. Install dropbear and launch server (change port to not interfer openssh-server)
3. Run the example
4. Try to write something on the 8080 port on the target host
5. Change port connect openssh and not dropbear (port 22)
6. Recheck... that works

What happened?

With dropbear ssh server, Accept() method is blocked. There is not problem with
openssh-server. 

To be precise, ssh tunnel command works as expected, the problem appears only with go
ssh package

See my explanation https://github.com/metal3d/idok/wiki/dropbear

What should have happened instead?

After writing on 8080 port on target, Accept() function should release and let
conn.Read(...) to be executed

Please provide any additional information below.

https://github.com/metal3d/idok/wiki/dropbear

[hanwen]

Comment 1:

in mux.go there is a debugMux variable that you can set to see what is really happening.

[gopherbot]

Comment 2 by Metal3d:

This is what I can log with debugMux = true:
go run main.go 
2014/09/05 16:33:43 decoding(1): 81 &ssh.globalRequestSuccessMsg{Data:[]uint8{}} - 1
bytes
2014/09/05 16:33:55 decoding(1): 90 &ssh.channelOpenMsg{ChanType:"forwarded-tcpip",
PeersId:0x0, PeersWindow:0x10000, MaxPacketSize:0x8000, TypeSpecificData:[]uint8{0x0,
0x0, 0x0, 0x9, 0x6c, 0x6f, 0x63, 0x61, 0x6c, 0x68, 0x6f, 0x73, 0x74, 0x0, 0x0, 0x1f,
0x90, 0x0, 0x0, 0x0, 0x9, 0x31, 0x32, 0x37, 0x2e, 0x30, 0x2e, 0x30, 0x2e, 0x31, 0x0,
0x0, 0xab, 0x4}} - 66 bytes
2014/09/05 16:33:55 send 1: ssh.channelOpenFailureMsg{PeersId:0x0, Reason:0x2,
Message:"could not parse TCP address", Language:"en"}
I can try to understand... but it seems to be very complicated to find what appends
before "could not parse TCP address"... :)

[gopherbot]

Comment 3 by Metal3d:

OK I see... append a log on parseTCPAddr function in client.go and see that the returned
address is:
localhost��   127.0.0.1�
This is not what openssh gives (it returns only ip addresses).
So, I decided to try something... I give you the patch. This is simple... If net.ParseIP
failed (ip is nil), I try to LookupIP()...
If the lookup failed the proces is the same as before. But now... It works with openssh
and dropbear.

Attachments:

1. go.crypto-dropbear-fix.patch (490 bytes)

[gopherbot]

Comment 4 by Metal3d:

A more secured code that test len() of Lookup response.

Attachments:

1. go.crypto-dropbear-fix.patch (507 bytes)

[gopherbot]

Comment 5 by Metal3d:

Bad patch... I retest, change and give you something that works... sorry

[gopherbot]

Comment 6 by Metal3d:

Now... that works.

Attachments:

1. go.crypto-dropbear-fix.patch (539 bytes)

[hanwen]

Comment 7:

I think the problem is in dropbear. According to
https://github.com/metal3d/idok/wiki/dropbear, you are asking for a forward of
"127.0.0.1", if it succeeds, it should reply with forwards that also list the address
"127.0.0.1". 
Arguably, go.crypto/ssh should also deal with textual addresses (client.Listen("tcp",
"localhost"), which should expand to all available loopback interfaces, but even then
the server should respond with either "::" (ipv6) or "127.0.0.1" (ipv4).
We could try a bugfix for dropbear, assuming ipv4 when it replies localhost. Can you
tell me the dropbear version string? You can find it with ssh.Conn.ServerVersion()

[gopherbot]

Comment 8 by Metal3d:

I will do this in a 1 hour, the time I go home at 12:00 :)
I aggree whith you aboute the fact that dropbear generates the problem. But, "ssh"
command to create tunnel seems to not complain about that. 
That could be great if gp.crypto/ssh could fix the problem. Event if I contacted
dropbear's author to take a look. Right, the fix should be in dropbear too.

[gopherbot]

Comment 9 by Metal3d:

I added version (string and []byte) log. That returns:
SSH-2.0-dropbear_2012.55 [83 83 72 45 50 46 48 45 100 114 111 112 98 101 97 114 95 50 48
49 50 46 53 53]
(2012 ??? woow...)

[gopherbot]

Comment 10 by Metal3d:

I contacted raspbmc user that tells me that Debian Wheezy has new release of Dropbear as
"unstable" since... 2 years :)
So, as a lot of user are not spcialist, I'm pretty sure that this version (if not
bumped) will be here for a long time... Debian Jessie use a new release, but I cannot
confirm that the "bug" is present. I will make some tests with a docker container to
test.

[gopherbot]

Comment 11 by Metal3d:

I contacted raspbmc authors to confirme that Dropbear version is 2012 and to know if new
releas exists. I saw that dropbear 2014 is in "unstable" state in Debian Wheezy (raspbmc
is using Wheezy).
Author tells me that the next release (named OSMC) will use a new version of dropbear.
But I can't confirm that the bug is still present.
What I will try is to install a docker container with debian Jessie, and test if the bug
is there.
Anyway, raspbmc is on a lot of raspberry-pi installation and users are not all
specialists... I guess that crypto package can hold a little fix for that kind of ssh
server...

[griesemer]

Comment 12:

Labels changed: added repo-crypto.