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
Open

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

gopherbot opened this issue Sep 4, 2014 · 14 comments
Milestone

Comments

@gopherbot
Copy link

@gopherbot 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
Copy link
Contributor

@hanwen 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
Copy link
Author

@gopherbot 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
Copy link
Author

@gopherbot 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
Copy link
Author

@gopherbot 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
Copy link
Author

@gopherbot gopherbot commented Sep 5, 2014

Comment 5 by Metal3d:

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

@gopherbot gopherbot commented Sep 5, 2014

Comment 6 by Metal3d:

Now... that works.

Attachments:

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

@hanwen 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
Copy link
Author

@gopherbot 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
Copy link
Author

@gopherbot 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
Copy link
Author

@gopherbot 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
Copy link
Author

@gopherbot 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
Copy link
Contributor

@griesemer 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
Copy link
Contributor

@hanwen hanwen commented Aug 21, 2015

ping? any news here?

@UbuntuEvangelist
Copy link

@UbuntuEvangelist UbuntuEvangelist 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.