Freshly delivered FOSS screencasts - every Friday.

Thanks for the another beautiful cast. But I have to questions! 1. How can I forward the https:// (i.e. 443) port too I am on Ubuntu? 2. What would be the handy command to stop the forwarding?

I use a slight modification of this SSH tunneling method exclusively when at public hotspots. I go to the extreme method to block all apps from leaking any DNS queries. I do not use socks proxies, but rather the classic http/https/ftp proxy method. I port-forward port 3128 to my remote ssh host which runs a squid proxy using the following option "-L 3128:localhost:3128". Then I set my local PC's proxy to localhost port 3128. Back to my modified/locked-down way of tunneling: After auth'ing to the local web-redirect (Star Bucks, or free auths at McDonald's, etc.), I run my lockdown script which only allows only my SSH session out (it just adds to my iptables). I already have a firewall filtering inbound traffic, but once I auth to the local web-redirect, I firewall (drop) all outbound traffic except my SSH. Nothing leaves my PC at this point except SSH to my own server. I only connect to my own server via IP (not DNS), and of course I already have my SSH host's public key stored locally from a previously trusted connection. Using this locked-down iptables-outbound method, this guarantees that I cannot leak DNS, nor anything else that isn't listening to my system's proxy setting. I also do port-forwarding hacks for my mail-server running on my SSH host, etc. Additionally, I can ssh tunnel through sites that require the use of a local proxy server and/or proxy server auth with proxytunnel (see proxytunnel.sourceforge.net/ ) and custom ~/ssh/config files which automate all of this. All that is required is that they don't filter https traffic (which would require https whitelist-access only, insane to manage) and/or don't do evil things like requiring local CA certs and breaking the SSL cert model by decrypting SSL traffic at the proxy edge and then re-encrypting it. I've never encountered either of these scenarios, but I have heard of both. I would never, ever use a proxy that breaks the SSL cert model (it wouldn't work with SSH tunneling anyway) - but the point is that the corporate proxy server would be able to see all of your traffic (which is why the do it). The whitelist model for http/https traffic is good for certain business models where certain classes/types of workers need internet access to specific B2B (or other easy to define lists) types of websites, but nothing else. I know of some businesses that do this, but I'm never on the VLAN/user auth-level that is restricted by this policy, so it is not a problem for me. One last thing I do is also use openvpn over tcp/443 to a secondary IP on my remote host, and I use this just to get an IPv6 address so that I can reach the IPv6 world directly w/o using squid via the other ssh tunnel. I really use this so that my laptop is reachable via IPv6 from the rest of the world. You could use this same method to give you an IPv4 address that could have internet access that way as well. This is actually a lot cleaner method, but I have a ton of other hacks I'm already doing with SSH port forwarding. SSH port forwarding also recovers faster than openvpn, and works great over my tethered cell phone that way. Love the screencasts, and it inspires me to do some of my own. What do you use to capture them, and what are you using to edit things together? ffmpeg appears to be able to do the job, but a gui FOSS tool would be nicer, especially to edit the bits of audio together and sync with the video.