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

Feature: SSH/curve transport support #80

Open
edermi opened this issue Dec 8, 2018 · 5 comments
Open

Feature: SSH/curve transport support #80

edermi opened this issue Dec 8, 2018 · 5 comments
Labels
enhancement New feature or request

Comments

@edermi
Copy link

edermi commented Dec 8, 2018

For some use cases it is important to protect data on the wire. TLS is already supported by mangos, but managing a CA, issuing certificates and deploying them takes some effort and is cumbersome especially in ad-hoc deployments. It would be nice to have a slimmer approach like a transport over SSH or the ability to protect available transports with something like curvezmq to fill this gap.

Go has support for SSH built in, so I assume the SSH transport may be easier to implement.

As far as I can see there were plans in the past / mangos v1 to introduce such a thing but I'm not sure if this was dropped, so I would like to express interest in such capabilities.

Thanks for your great work!

@gdamore
Copy link
Contributor

gdamore commented Dec 9, 2018 via email

@glycerine
Copy link

Hi Michael @edermi You can easily tunnel TCP over SSH, so just use NNG with TCP.
https://github.com/glycerine/sshego is a Go library I wrote for keeping the tunnel setup in process as well--but programming to it may be overkill when a shell script or autossh can have you working in minutes.

@edermi
Copy link
Author

edermi commented Dec 28, 2018

Thanks @glycerine, I will have a look. Nevertheless, keeping the number of 3rd-parties low is almost always a good idea, so having this integrated into mangos would still be nicer than relying on another library

@glycerine
Copy link

glycerine commented Dec 28, 2018

@edermi Generally yes. But the ssh libraries are quite large and represent a vast surface area for bugs and tweaks as system integration happens. So large in fact, as to be a real hassle for developers and maintainers. Nicer for users. Much worse for developers. I would strongly recommend against integrating the two. Especially when it is only tunneling. We already have a nice abstraction into layers. Let's not break it without good reason.

@gdamore
Copy link
Contributor

gdamore commented Jan 24, 2019

@glycerine if we used SSH I'd like to do it natively using the standard go libraries to do so. I don't think this would be particularly onerous nor particularly high risk.

The are some reasons not to use SSH tunnels -- these can actually be higher risk, and require more complex setup as typically you're arranging for port forwarding rather than a direct connection to a peer. This proxy also comes at a performance penalty, as the remote side winds up going through a proxy instead of just dealing with the traffic itself.

Of course, there are some flexibillity advantages that come with that cost (like the ability to forward to a machine that doesn't have a direct route to the peer).

The good news is that the SSH proxy method will always be available for everyone, with no effort on my part. If I wind up doing a native SSH transport, that would probably only be direct peer to peer, and would make use of the go native packages (as I've indicated).

@gdamore gdamore added the enhancement New feature or request label Sep 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants