Le mardi 17 janvier 2017 ? 9:20 +1100, Darren Tucker a ?crit :> On Tue, Jan 17, 2017 at 1:30 AM, Romain Vimont <rom at rom1v.com> wrote: > [...] > > As a consequence, in particular, a SOCKS5 server started with "ssh -D" > > cannot proxify UDP packets. > > > > Are there deep reasons why OpenSSH does not implement them (security, or > > whatever)? > > ssh -D accepts SOCKS CONNECT requests and maps them to SSH > "direct-tcpip" requests (see RFC4254 section 7.2). These are only > defined for TCP, there's no equivalent for UDP.Thank you for your answer. 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")? Here is some context: I would like to provide a reverse tethering tool for Android that redirects all the packets to a SOCKS5 server. Since "ssh -D" is the simplest way to create a SOCKS5 server (and everyone has an ssh client), starting a reverse tethering would have been easy. Unfortunately, if UDP packets are not relayed, it does not work. An alternative would be to use a tun device on the host and forward the packets (what SimpleRT? does), but this requires root access on the host. Regards, ?om ? <https://tools.ietf.org/html/rfc1928#section-7> ? <https://github.com/vvviperrr/SimpleRT>
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. -- 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.
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