This patch adds transparent proxy support on Linux. You can then run `ssh -D $port` and use `iptables -t nat -A OUTPUT -p tcp -d $dest -j REDIRECT --to-ports $port` to tunnel all TCP connections to host $dest via the ssh tunnel. Please apply, since this functionality is quite useful and cannot be efficiently obtained otherwise.
Created attachment 1249 [details] Patch
Created attachment 1250 [details] Remove auto-generated files from diff The bulk of the diff (99.7%, by my calculations :-) is noise from automatically generated files.
Sorry, I had filtered it myself but uploaded the wrong file.
Created attachment 1251 [details] Move Linux code to port-linux.c, add OpenBSD pf rdr support I like this idea, and I've extended it a bit: * added autoconf support * moved linux/netfilter-specific code into openbsd-compat/port-linux.c * added support for OpenBSD pf "rdr" rules * made it easy to add new redirection interfaces. On OpenBSD, you can use something like the following in pf.conf: tun_net="192.168.34.0/24" rdr pass on lo0 proto tcp from any to $tun_net -> 127.0.0.1 port 1080 pass out quick route-to (lo0 127.0.0.1) from any to $tun_net (the route-to is needed because pf rdr rules don't apply to outbound packets, so without it you can't redirect locally originated connections). For anyone wondering how this compares to the tun(4) interface that's already there: it's less flexible (TCP only, requires good name resolution on the client end) but doesn't require privilege on the server (or anything other than standard port forwarding) and doesn't suffer from the TCP-over-IP-over-TCP performance potential problems (ie stacked retransmits when the link experiences packet loss). For the truly twisted: you can also achieve something similar to this patch *without* special kernel support (other than ppp/slip) if you build slirp socksified and point it to a DynamicForward. (I've actually done this, but it turns out I wasn't the first to think of it. I dunno if I'm disappointed or relieved :-)
Nice idea, but why does this need to be in ssh (which would need to then run as root) and not some little "nat-to-socks" tool, or just as a mode to netcat? That way it would not bloat ssh, and could also be used to automatically Tor-ify applications.
(In reply to comment #5) > Nice idea, but why does this need to be in ssh (which would need to > then run as root) It doesn't necessarily need to run as root. On Linux, it doesn't require any privilege at all. On OpenBSD, it needs write access to /dev/pf (I asked the pf guys if there was another way to do it but there wasn't). You could make it setgid, and you could mitigate by opening /dev/pf early then revoking privileges and keeping the descriptor open. > and not some little "nat-to-socks" tool, or just as a > mode to netcat? That way it would not bloat ssh, and could also be > used to automatically Tor-ify applications. Now that might be worth investigating. I looked for such a tool but didn't find one (not that it means it doesn't exist, just that I didn't find it).
Because this avoids the extra overhead and hassle of the nat-to-socks application.
(In reply to comment #7) > Because this avoids the extra overhead and hassle of the nat-to-socks > application. A separate nat-to-socks application does have some advantages, though. You could open the tunnels on demand, and you could use different tunnels based on different conditions (eg: target, current location on the network). Both of those are things that would be useful to me. Going back to comment #6, there's another way it could be done on OpenBSD without running sshd as root: you could use a setuid/setgid helper to return an open descriptor on /dev/pf.
We should decide on this one way or the other: How about we build this into a little helper program in contrib/ ? We could even link against libssh.a that way...
We'll look at this for the next release.
Retarget unclosed bugs from 5.7=>5.8
Retarget unresolved bugs/features to 6.0 release
Retarget unresolved bugs/features to 6.0 release (try again - bugzilla's "change several" isn't)
Retarget from 6.0 to 6.1
Retarget 6.0 => 6.1
I'd like to get this done soon, but the current patch has bitrotted - particularly in the pf department. IMO this would be best as a helper program that: 1) accept()ed connections redirected to it by the packet filter 2) determined (by OS-specific means) the original address 3) connected to a running ssh via it's multiplexing socket and passes in the accepted fd using MUX_C_NEW_STDIO_FWD This makes the helper really small and simple, which is nice because it looks like it will need privileges of some sort on OpenBSD at least.
Retarget uncompleted bugs from 6.1 => 6.2
Retarget bugs from 6.1 => 6.2
retarget to openssh-6.3
Retarget to openssh-6.4
Retarget 6.3 -> 6.4
detargetting until this is rewritten as per comment #15
*** Bug 2526 has been marked as a duplicate of this bug. ***
At least one implementation of this idea as an external redirect->socks server exists (http://darkk.net.ru/redsocks/) and another using LD_PRELOAD (tsocks). I don't think we're ever going to implement this in ssh itself.
closing resolved bugs as of 8.6p1 release