The title above is pretty close to the Google search query I used in vain to find a recipe for tunneling an OSX Samba client to an Ubuntu 14.04 server. Hopefully this post will save someone the hours I spent trying to set this up.
In the end, like so many Unix projects, the answer turned out to be simple. All that’s needed is a configured and functioning Unix/Linux Samba and SSH server . Everything else is on the client side.
I’m not unfamiliar with Samba. I ran it for years between a FreeBSD Unix server and Windows XT workstation. It had its quirks, and still does. When I dumped Windows for a shiny, new Mac Pro in 2009, I switched to NFS. But with each successive OSX upgrade, NFS got flakier to the point where it became useless so I returned to Samba. But Samba is inherently insecure outside of a trusted LAN so for out-of-office occasions I started using SSHFS. Unfortunately, SSHFS relies on deprecated, third-party software on the OSX side and it was s..l..o..w. My PHP Storm IDE was grinding through directory refreshes after Git checkouts.
With the release of OSX Mavericks 10.9, Apple announced that it was dumping yet another networking protocol — it’s own greybeard AFP. To replace it, they embraced SMB2. Or… ta da… Samba. Technically, SMB2 isn’t officially Samba however OSX has unofficially supported Samba clients for several operating system releases. Samba(tm) (the Unix server) is actually a product of the open source team at Samba.org. SMB is an acronym for Server Message Block, which is a proprietary Microsoft protocol. Samba is built to the published white paper spec for SMB.
To wrap this up, Microsoft controls the SMB spec, Samba supports a published subset of that spec and now so does OSX, or at least SMB2. We finally have an open source protocol officially supported by the Big Three.
Back to the task at hand: out in the wilds of the internets Samba hacking is practically a recreational sport. The list of Samba vulnerabilities is long and largely unfixable. There are script-kiddy toolboxes available for breaking into Samba sessions so you don’t even have to be hacker-smart. The take away is that you definitely don’t want to run Samba on a WAN. However, you can mitigate those hazards by tunneling Samba through encrypted SSH, preferably on a public-key authenticated, no-password connection. Sure, it will be slower but slow is better than dead.
The first step is to get your OpenSSH (or equivalent) and Samba servers configured, up and running. There are plenty of excellent tutorials for both so I won’t repeat them. If your Samba connection is working and you can login to an Ubuntu user account on that server over SSH from an OSX terminal, you’re 90% there. Just one thing: it’s a lot handier, not to mention more secure, if you also require RSA-authenticated/no password SSH connections as it will make a hacker’s job a lot more difficult. They’ll have to crack an authenticated SSH session before they can even get to Samba, and that’s a lot harder. But it’s not required to tunnel Samba through SSH.
I said it was easy, and it is. To initiate Samba tunneling you just need two commands and both have to be done by the superuser on your Mac via the Terminal client.
First, set up a localhost alias on OSX reserved for the tunnel. 127.0.0.1 is the default localhost so we’ll use 127.0.0.2:
sudo ifconfig lo0 127.0.0.2 alias up
Then you open the tunnel using the SSH client. In this example, the Ubuntu server running Samba lives on the local LAN at 192.168.1.10. The client is logging into the ‘joe’ user account on that server using the default SSH port 22. You can either use the IP address or the domain name of the server. If you do this over a WAN, make sure that your router is sending port 22 traffic to the Ubuntu server:
sudo ssh -L 127.0.0.2:445:192.168.1.10:445 joe@192.168.1.10
You will need to keep this process running for the duration of your Samba connection. What this does is use port forwarding to tunnel a connection to the Unix Samba port (445) over SSH’s default port 22. You don’t need to open port 445 on your router (in fact, you shouldn’t). You can run an SSH server on whatever unused port you want in case port 22 traffic is already being forwarded to another server. But if you run sshd on an alternate port like port 2202 you’ll need to add that override to the above command (i.e., -p 2202).
To start the Samba connection, go back to the OSX desktop. Click Finder -> Go -> Connect to Server and use this address:
smb://joe@127.0.0.2
If everything is working you should have all your Samba folders mounted in Finder.
My next project will be to automate this task to run when you login to OSX, possibly by using the Automator utility to create a script for System Preferences -> Users & Groups -> Login Items. I’ll amend this article then.