On Tue, Jan 17, 2017 at 07:42:50AM -0800, Ron Frederick wrote:
[...]
> One thing that makes UDP over SOCKS more complicated for SSH is that
> SOCKS normally keeps the UDP packets it forwards as UDPl, just adding
> a small header to each packet. If you want to get the benefit of the
> SSH encryption here, though, you'd need to open an SSH channel to
> carry these packets, converting them from UDP to being carried within
> the existing SSH TCP connection (much like what SSH already does in the
> SOCKS TCP case) and then converting back to UDP on the other side.
Yeah, I alluded to that with my reference to message types earlier.
If you didn't forward it over the ssh channel otherwise whole exercise
would be pointless since you could acheive the same result with a separate
process that handled UDP on the client.
Anyway it seems like a lot of work for little benefit, and even if it
was done it'd still have an interoperability problem.
> It might be worth looking into where SSH tunnel device forwarding
> would be helpful here (the -w option in OpenSSH). It's already
> designed to tunnel datagrams, and should have no trouble carrying UDP
> packets. It doesn't use SOCKS as the way to get the data to the SSH
> client, though. Instead, it relies on the ability to create a network
> tunnel device. See the SSH-BASED VIRTUAL PRIVATE NETWORKS section
> of the SSH man page for details.
I think the problem for this use case is that it requires root-equivalent
access on both client and server to set up and open the tunnel devices.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
