mangos
mangos copied to clipboard
nanomsg
Feature: SSH/curve transport support
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!
i am interested in these transport options.
it does come down to what i have time to do. having commercial sponsorship helps for this. absent that its as i find time to do stuff or as others do and send pull requests.
- Garrett
On Sat, Dec 8, 2018, 12:22 PM Michael Eder [email protected] wrote:
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 http://curvezmq.org/ to fill this gap.
Go has support for SSH built in https://godoc.org/golang.org/x/crypto/ssh, 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 https://github.com/nanomsg/mangos/blob/master/PLANS.md#new-transports 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!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nanomsg/mangos-v2/issues/80, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPDfbtiLGFsCSoQUwdgP4Ax0Frfkd_qks5u3B-ggaJpZM4ZJzVV .
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.
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
@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.
@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).