« Over quota | Main | Spamusement »

Tunnelling AppleShare over SSH

This is really just refinement and update to information found elsewhere.

Say you're somehwere with your 'Book (named "rover") running OS X and you'd like to edit some files on your OS X machine (named "bone") at home. You're accustomed to this because you've got your home router set to forward the SSH port to your Mac and you use a dynamic DNS service to have a home hostname (named "doghouse.dyndns.org") so you don't have to figure out what your broadband IP du jour is.

If you were to SSH to your home computer (to edit text files with pico or vi), you'd enter something like "ssh -l flea doghouse.dyndns.org" where "flea" is your username on doghouse (That's a lowercase "ell" after ssh and before "flea"). Note that your home Mac "bone" is called "doghouse.dyndns.org" because that's the public hostname assigned to your IP. You could also use Fugu to transfer whatever files you want to the laptop using SFTP. But gee, it's so much easier when you're using the 'Book at home because you just mount your home directory using AppleShare ("afp:://bone.local"). Fortunately, you can tunnel an AppleShare connection over SSH.

ssh -l flea -L 10548:doghouse.dyndns.org:548 -N doghouse.dyndns.org

You'll be prompted for your password on your home computer as usual and then nothing will happen in the Terminal window. So what's going on here? The beginning and end of the command is like a normal SSH session but in-between you're telling SSH to create a local port ( -L ) numbered 10548 and to connect that local port to port 548 (which is the port used by AppleShare) on doghouse.dyndns.org. Putting -N in front of the second hostname tells ssh that you don't want to open a command prompt on the remote computer because you're only interested in using this encrypted tunnel you've created. "10548" was a fairly arbitrary choice, you could pick any number between 1024 and 32768 but adding "10" to the front of the AppleShare port is a bit easier to remember.

Now you're ready to give it a try. Go to the Finder, Connect to Server and enter afp://localhost:10548" as the server address. "localhost" refers to your own machine, in this case "rover" the 'Book. The AppleShare password prompt will appear asking for login information for the machine "bone," just as if you were using the laptop at home. That's it, you can connect to the share you want and use it just as you would at home (though probably slower due to the slower network connection). When you're done with the share you disconnect as usual then go back to the terminal window used to create the tunnel and press Ctrl-c to close the tunnel.

But wait, there's more! What if the files you wanted to edit weren't on the Mac called "bone" but on another Mac at home (named "hydrant")? No problem, because the tunnel you create doesn't have to be on the same computer as the SSH session.

ssh -l flea -L 10548:hydrant.local:548 -N doghouse.dyndns.org

Everything is the same but instead of "10548" on rover pointing to the AppleShare port on "bone" it's now pointing to the AppleShare port on "hydrant" (you can use the Rendezvous hostname "hydrant.local" because it's bone's job to figure out where hydrant is). When SSH prompts you for the password for user "flea" you're still dealing with an account on bone (aka doghouse.dyndns.org). When you make the AppleShare connection to afp://localhost:10548 you'll now be prompted for a username and password on hydrant.

If you wanted to use AppleShare on both bone and hydrant you could, you'd just have to specify different local ports for each (perhaps "10548" and "11548").

And if you wanted to use SSH to get to hydrant, you can use tunnelling for that too.
ssh -l flea -L 10022:hydrant.local:22 -N doghouse.dyndns.org
All I changed was the port on hydrant to 22 (the SSH port) and the local port to 10022. I didn't have to change the local port number but it can be easier to keep track of the local ports if you use such a numbering system, espcially if you have multiple SSH tunnels going at once.

Comments (1)

I can make the first formula above work also if I replace the second instance of the remote hostname "doghouse.dyndns.org" with "", referring to the local host. In fact, that's the only version that works for me if the remote host's IP address maps to a name that doesn't map back to the same address.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


This page contains a single entry from the blog posted on July 8, 2004 1:13 PM.

The previous post in this blog was Over quota.

The next post in this blog is Spamusement.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.31