A visual guide to SSH tunnels
21–30 of 82 posts
Re: A visual guide to SSH tunnels
#22SSH tunnels are my favorite tool for NAT-busting. I always have to look up the cryptic syntax, but with one strategically placed Raspberry Pi, you can basically get from anywhere to anywhere. And it works just as well on a locked down corporate network as it does on a home network. Why people put up with garbage VPN software is beyond me.
One can further tunnel SSH inside of TLS with Stunnel [0] to get through firewalls that block SSH but permit arbitrary TLS connections. Loading a website through this requires three layers of TCP but assuming the connection is good this should be okay. A couple reasons for a regular VPN: they can be made automatic and persistent so the tunnel is always ready for use, they can tunnel other protocols besides TCP, they…
Re: A visual guide to SSH tunnels
#23I also found the following very nice: (Same info but presented in a different way.)
https://unix.stackexchange.com/questions/115897/whats-ssh-po...
Re: A visual guide to SSH tunnels
#24Re: A visual guide to SSH tunnels
#25Earlier quoted context omitted.
[note I am wrong here - it doesn't support UDP - see below] The ssh SOCKS proxy supports UDP. I use Firefox with a SOCKS proxy via ssh (e.g. ssh -D 2222 hostname) to get around geoblocking and accessing papers via an institutional account. The tsocks program can also let you use a SOCKS proxy for an arbitrary command in linux. I find it much more convenient than a VPN, as it can be easily applied to single programs.
Are you about this? Last time I've checked SSH SOCKS5 only supports TCP traffic, UDP isn't supported and needs extra steps through tools like socat to wrap UDP in TCP. http://lists.mindrot.org/pipermail/openssh-unix-dev/2017-Jan...
Re: A visual guide to SSH tunnels
#26One thing to add is that you can even open tunnels during an interactive session without disconnection.
To do this, type the escape command sequence ~C (will not show) and it will drop you to the control prompt. You can then add tunnels.
ssh>
ssh> -L 8000:localhost:9000
Forwarding port.Re: A visual guide to SSH tunnels
#27Earlier quoted context omitted.
Are you about this? Last time I've checked SSH SOCKS5 only supports TCP traffic, UDP isn't supported and needs extra steps through tools like socat to wrap UDP in TCP. http://lists.mindrot.org/pipermail/openssh-unix-dev/2017-Jan...
It looks like I was wrong about UDP being supported by ssh. Sorry about misleading everyone. I've verified with nc that it doesn't actually forward UDP. I'm amazed that streaming media over this seems to work fine on most sites, though.
Alternatively, you might be unknowingly using un-proxied UDP: Many AV systems only enforce IP restrictions on the signalling protocol (which is often TCP); the actual media can then take whatever path it wants.
By the way, it seems like you can forward UDP over sshuttle [1] when used with tproxy (which seems to be a Linux-only feature)!
Re: A visual guide to SSH tunnels
#28Earlier quoted context omitted.
SSH isn’t a replacement for VPNs. I’d argue that they complement each other. For example, SSH port forwarding is TCP only, so if you need UDP, you‘ll need a VPN.
[note I am wrong here - it doesn't support UDP - see below] The ssh SOCKS proxy supports UDP. I use Firefox with a SOCKS proxy via ssh (e.g. ssh -D 2222 hostname) to get around geoblocking and accessing papers via an institutional account. The tsocks program can also let you use a SOCKS proxy for an arbitrary command in linux. I find it much more convenient than a VPN, as it can be easily applied to single programs.
The less cooperative your applications are (even though cooperation can be somewhat enforced using tsocks, as you mention, which can be further made to apply system-wide using sshuttle [1]), the more a VPN will start to make sense.
Re: A visual guide to SSH tunnels
#29SSH tunnels are my favorite tool for NAT-busting. I always have to look up the cryptic syntax, but with one strategically placed Raspberry Pi, you can basically get from anywhere to anywhere. And it works just as well on a locked down corporate network as it does on a home network. Why people put up with garbage VPN software is beyond me.
SSH isn’t a replacement for VPNs. I’d argue that they complement each other. For example, SSH port forwarding is TCP only, so if you need UDP, you‘ll need a VPN.
Re: A visual guide to SSH tunnels
#30On the remote host, have the vnc server listen only on localhost:5901
This assumes everyone who can ssh to the server should be allowed access.
On your workstation, form an ssh tunnel to that remote host and its port, and link it your own localhost:5901
Open your vnc client GUI and set it to open 127.0.0.1:5901, voila, vnc session.
More fun things: say for example you have a big remote xen dom0 with a lot of unique qemu HVM VMs running on it. Configure each of their .cfg files for xen to spawn a vnc server on localhost only and a unique port number per domU (5902,5903,5904,etc). Then use the same method to connect.