Sometimes, ssh tunneling a port is insufficient. It’s fantastic if you want to remotely access some system, but suppose you want more of an ad-hoc VPN/proxy, to allow you to, say, browse the web through a remote system?

I thought about setting up squid on a remote system, but that would be a bit of work. Plus, I’d have to take care to lock it down so I wasn’t accidentally running an open proxy, which is all sorts of bad. I could also do OpenVPN, but that’s an even bigger headache to set up.

As it turns out, ssh includes native support for establishing a SOCKS proxy, too. Your local ssh client will stand up a SOCKS proxy on localhost, on a port you specify, and forward traffic through ssh to the remote system. You can then simply point your web browser at your local SOCKS server, and viola!

From the ssh manpage, it’s astonishingly easy:

     -D [bind_address:]port
             Specifies a local ``dynamic'' application-level port forwarding.  This works by
             allocating a socket to listen to port on the local side, optionally bound to the
             specified bind_address.  Whenever a connection is made to this port, the connection
             is forwarded over the secure channel, and the application protocol is then used to
             determine where to connect to from the remote machine.  Currently the SOCKS4 and
             SOCKS5 protocols are supported, and ssh will act as a SOCKS server.  Only root can
             forward privileged ports.  Dynamic port forwardings can also be specified in the
             configuration file.

Add -N to stand up the tunnel but not give you a command prompt, and optionally -C to enable compression. (Typically only useful on slower connections.)

Putting it in action, it looks something like this:

mawagner ~ $ ssh -CND 8000 bos.n1zyy.com

It will continue to run in the foreground without any output. That’s all it takes—you’ve now got a SOCKS server running.

Now, configure your browser to use it. In Firefox, in the Preferences menu, Advanced › Network › Connection › Settings lets you set up a SOCKS proxy. Just fill in the SOCKS proxy line, with “localhost” for the hostname (not the remote server—ssh is listening on localhost and forwarding connections there for you) and whatever port you specified on the command line (8000 in my example).

Chrome seems to want this as command-line flags. On the Mac, it took this ridiculous command to launch:

$ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --proxy-server="socks5://localhost:8000"

Take note that the SOCKS proxy will handle the actual connections, but DNS requests will still take place locally. If you’re trying to hide your traffic from an oppressive regime, this could be bad. It’ll also be bad if you’re trying to connect to something over a great distance and they’re using geo-DNS to steer you to the right place. But when your home ISP just sucks and you want to bypass their overloaded connection to Youtube, this is just the trick.

Last night, I threw together a quick Samba server on a RHEL 6.4 machine at home. (I’m running RHEL, but you’d almost certainly have an identical experience on CentOS.) I set up user homedirs accessed over Samba, and was able to authenticate properly from my Mac laptop.

However, I ran into an issue where I could connect okay, but the mounted share showed as empty. I couldn’t copy files in, and any files already there didn’t show up. A bit of Googling suggests this isn’t an uncommon problem. The share looked blank/empty.

Checking /var/log/messages, I saw a bunch of these entries:

May  9 22:04:02 c6100-n4 smbd[8537]: [2013/05/09 22:04:02.949679,  0] smbd/dir.c:315(dptr_close)
May  9 22:04:02 c6100-n4 smbd[8537]:   Invalid key 0 given to dptr_close

Googling this, I found an article suggesting that it’s caused by SELinux, and another from a SuSE user having the same issue with AppArmor. I really didn’t like the suggestions to disable these services, though; it feels akin to disabling a firewall because it’s too complicated to configure.

And, if you know where to look (man samba_selinux), it’s actually easier to fix this the right way than to persistently disable SELinux:

If you want to allow samba to share users home directories, you must turn on the
samba_enable_home_dirs boolean.

setsebool -P samba_enable_home_dirs 1

It’s annoying that the error in /var/log/messages doesn’t convey anything useful, but I can understand why this behavior would be prohibited by default. Why should a daemon be allowed to read users’ home directories out of the box?

Running the setsebool -P samba_enable_home_dirs 1 command (note that -P makes it persist, and that doing so updates on-disk policies, which takes a moment), everything works great. My clients can see the shares just fine, the cryptic errors aren’t being logged, and SELinux remains in enforcing mode.

I missed the talk at Summit last year, but it turns out that they’re all online… So check out the SELinux for Mere Mortals talk. I’ve come to realize that there are two types of people—people who disable SELinux out of the box because it’s “too hard,” and people who learned how to use it and insist it’s really easy once you understand it. Watch the video and move over to the second category.

Time for another of sporadic roundups of interesting reads on the Internet.

• LG’s 29EA93-P 29″ monitor, 2560×1080, about $700. (At NewEgg, for example.) It’s quite an odd aspect ratio, and you’d save a lot of money and get a lot more screen real estate by buying a pair of 1920×1080 monitors. (For those too lazy to do the the math, 2560×1080 is equivalent to two 1280×1080 monitors side-by-side.) But, two 1920×1080 23″ monitors side-by-side is almost too wide sometimes, and you get that annoying double-bezel in the middle. So despite all that’s rational, I can’t help but crave this thing.
• RailsCast #400 – What’s New in Rails 4. This is now four months old today, so I guess I’m behind the times. But if you haven’t seen it before, it’s a really interesting look at the next Rails.
• There’s also an e-book linked from this week’s Ruby Weekly, Upgrade to Rails 4, if a deeper dive is worth paying a few bucks for.
• And as mentioned in the RailsCast, there’s a great Rails 4 link compilation on the WyeWorks blog. (I will confess that I’ve only read a minority of them thus far.)
• A major remote exploit was discovered in PostgreSQL. Fixed versions were released today. As an interesting aside, they went to some unusual lengths to avoid disclosing the attack before a fix was released.
• On the subject of security, Code Climate came out with an interesting blog post last week, Rails’ Insecure Defaults: 13 Security Gotchas You Should Know About. There’s several in there that I found surprising and alarming, so this is really a must-read. The comments are also interesting — if you skip over the anti-Rails trolls, there’s discussion of some additional things to be mindful of. (Code Climate’s Security Monitor looks pretty interesting and useful as well.)
• I assume most of you are familiar with Coursera. (If not, oh my gosh, go there now.) What I wasn’t aware of until I clicked some wrong links somewhere was Stanford Online which has a bunch of free courses online. (Many, but not all, are through Coursera.)

Oh, and to close out on a lighter note… I saw this the other day: Build to Fail, Fail to Build. What is this I don’t even….., in which a forum member chronicles his landlord’s attempts to build a “shed,” despite an apparent complete lack of requisite skills. Don’t miss the photo updates on page 5, 7, 11, and 17.