Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/crypto/ssh: problem with Dropbear tunnel #8657

Open
gopherbot opened this Issue Sep 4, 2014 · 14 comments

Comments

Projects
None yet
6 participants
@gopherbot
Copy link

gopherbot commented Sep 4, 2014

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

This comment has been minimized.

Copy link
Contributor

hanwen commented Sep 5, 2014

Comment 1:

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

This comment has been minimized.

Copy link
Author

gopherbot commented Sep 5, 2014

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

This comment has been minimized.

Copy link
Author

gopherbot commented Sep 5, 2014

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

This comment has been minimized.

Copy link
Author

gopherbot commented Sep 5, 2014

Comment 4 by Metal3d:

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

Attachments:

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

This comment has been minimized.

Copy link
Author

gopherbot commented Sep 5, 2014

Comment 5 by Metal3d:

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

This comment has been minimized.

Copy link
Author

gopherbot commented Sep 5, 2014

Comment 6 by Metal3d:

Now... that works.

Attachments:

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

This comment has been minimized.

Copy link
Contributor

hanwen commented Sep 9, 2014

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

This comment has been minimized.

Copy link
Author

gopherbot commented Sep 9, 2014

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

This comment has been minimized.

Copy link
Author

gopherbot commented Sep 9, 2014

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

This comment has been minimized.

Copy link
Author

gopherbot commented Sep 9, 2014

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

This comment has been minimized.

Copy link
Author

gopherbot commented Sep 9, 2014

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

This comment has been minimized.

Copy link
Contributor

griesemer commented Oct 1, 2014

Comment 12:

Labels changed: added repo-crypto.

@gopherbot gopherbot added new labels Oct 1, 2014

@bradfitz bradfitz removed the new label Dec 18, 2014

@mikioh mikioh changed the title code.google.com/p/go.crypto/ssh problem with Dropbear tunnel ssh: problem with Dropbear tunnel Jan 7, 2015

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc changed the title ssh: problem with Dropbear tunnel x/crypto/ssh: problem with Dropbear tunnel Apr 14, 2015

@rsc rsc modified the milestones: Unreleased, Unplanned Apr 14, 2015

@rsc rsc removed the repo-crypto label Apr 14, 2015

@hanwen

This comment has been minimized.

Copy link
Contributor

hanwen commented Aug 21, 2015

ping? any news here?

@saydulk

This comment has been minimized.

Copy link

saydulk commented Oct 29, 2017

how i can see:

  1. Dropbear user multiple login protection
  2. Dropbear user connection status
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.