On Jan 17, 2017, at 1:37 AM, Darren Tucker <dtucker at zip.com.au> wrote:> On Tue, Jan 17, 2017 at 8:05 PM, Romain Vimont <rom at rom1v.com> wrote: > [..] >> So if I understand correctly, making "ssh -D" create a "full" SOCKS5 >> server, including UDP relay?, would require to add a new SSH request >> type (like "relay-udp")? > > Right. SSH has an extension mechanism: message types with an > @somedomain.com are "vendor extensions" that do not require IETF > standardization so it'd be relay-udp@$something. It'd need some kind > of association tracking for UDP host/port pairs to replace the stuff > the kernel does for us with TCP, so it'd probably more complicated to > implement than the existing SOCKS/direct-tcpip support.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. 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. -- Ron Frederick ronf at timeheart.net
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.
Le mercredi 18 janvier 2017 ? 8:55 +1100, Darren Tucker a ?crit :> On Tue, Jan 17, 2017 at 07:42:50AM -0800, Ron Frederick wrote:Thank you for your answers.> [...] > > 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.Even with a separate process handling UDP packets, the "UDP association" must be handled by the SOCKS server over TCP (so the SSH server would still require changes in that case). Anyway, I wanted to start a SOCKS5 server on the computer, a SOCKS5 client on Android, and communicating over adb (thanks to "adb forward" / "adb reverse"). Unfortunately, adb forwarding does not support UDP packets either, so using SOCKS5 for this purpose won't work anyway. Why SOCKS5 requires to transfer UDP packets-to-relay over UDP (instead of using the existant TCP connection) is a mystery for me.> Anyway it seems like a lot of work for little benefitIt would provide a full SOCKS5 server, able to redirect all IP packets.> > 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.Yes, it would require root access on the server. It would be quite equivalent to what SimpleRT does, by creating a tun device manually. <https://github.com/vvviperrr/SimpleRT> Regards, ?om