(Not) Stumped!

(or: “Mounting SAMBA shares through an SSH tunnel in OS X”)

March 29, 2007 update: This post details the frustration I was experiencing at the time. I’ve since written a down-and-dirty, all-inclusive procedure for SSH port forwarding and mounting remote shares on your Mac.

Non-techies, skip this post and continue with the car post below. Gregg et al, please offer advice where you can.

Wish: Map local (OS X) port 139 to remote SAMBA server port 139 through SSH tunnel using standard port forwarding practices. Mount SAMBA share on localhost at standard port 139 (which is port-forwarded to 139 on remote host). Authentication and subsequent traffic goes through tunnel, right?

Reality: Can’t do it. Totally do-able.

Attempted procedures (and a good solution) in some detail after the jump.

Update 2: Before attempting any port-to-port connection, be sure to make sure that type is allowed by all routers and firewalls between the machines. While I made sure the firewall and services on the OS X box allowed the desired connection, I forgot about another intervening firewall. A minor adjustment there, and bickety-bam! Here’s the short list of how to do it:

  1. If you’re using any type of public/private key authentication, copy the keys to root’s home directory: /private/var/root/. If you’re using ssh (like me), you may have to create the .ssh directory there.
  2. Next, either drop to root (if you’ve previously enabled it in NetInfo Manager), or ‘sudo’… and issue your port forward or tunnel command.
  3. Go to Finder; in the “Go” menu, select “Connect to Server…”. When the dialogue box pops up, enter “smb://localhost/SHARE_NAME” where “SHARE_NAME” is the… um… name of the Samba share you want to mount.
  4. Log into the remote box with your Samba username and password. Boo-yah, gramma.

Here’s all the old pain:

Tried:

  1. Enabled root on OS X box, specified root password. ‘su’ now works in Terminal bash shell.
  2. Generated public key for root account, added to list of authorized users on firewall box, which handles all SSH tunneling requests.
  3. Turn OFF firewall on OS X box to allow traffic through all ports, incl. 139.
  4. Turn OFF “Windows Sharing” on OS X box, so no services running/occupying local 139.
  5. As root, map local port 139 to remote box 139 through tunnel. Everything’s fine, it seems.
  6. Try mounting remote share via:
    1. Go » Connect to Server… » smb://localhost/SHARE_NAME
      Nope.

    2. Go » Connect to Server… » smb://127.0.0.1/SHARE_NAME
      Nope.
  7. Create local mount point ~/Desktop/mysmb
    1. me$ mount_smbfs -I localhost -U myname //localhost/SHARE_NAME ~/Desktop/mysmb
      Nope. (mount_smbfs: negotiate phase failed: syserr = Connection reset by peer)

    2. me$ mount_smbfs -U myname //127.0.0.1/SHARE_NAME ~/Desktop/mysmb
      Nope. (same as above)

    Over in my root shell where the port forward was initiated:
    channel 2: open failed: connect failed: Connection refused

Theoretically, my local 139 is mapped to the remote SAMBA server’s port 139… OS X didn’t complain when I set that part up. I’m assuming this has something to do w/ OS X lacking a method to perform authentication through the tunnel?

One other odd observation. When I create the local mount point on the Desktop, it looks like any other folder. But if I just do the straight-out mount:

me$ mount_smbfs -U myname //sambaserver/SHARE_NAME ~/Desktop/mysmb

… it mounts just fine, but the folder icon (~/Desktop/mysmb) disappears from the Desktop—and everywhere else in Finder— altogether. It definitely still exists, as I can navigate to the local mount point, and through the remote directory structure in Terminal w/ no problems.

I’m seriously confused about all this shit.

Any ideas?

Update: Jesse suggested adding the line “127.0.0.1 tunnel” to the /etc/hosts file and attempt connection to “tunnel” instead of “localhost” to circumvent any in-built weirdness whereby SAMBA doesn’t “want” to connect to itself. Alas, that bit of trickery didn’t work either, so I remain stumped.

Advertisements
Posted in Mac

3 thoughts on “(Not) Stumped!

  1. can you, like, send any packets to the tunnel at all? The text reads as 139 to 139; does your ISP allow traffic on that port? Doesn’t smb require some other open port to handle authentication? (been so long … )

    Why are you using SMB, anyway? Don’t you have an XServe? Why not use WebDAV? It uses https, no need for tunnels.

  2. I use SSH tunneling all the time, and in the course of my troubleshooting efforts, successfully mapped multiple remote services/ports to local ports, mostly unprivileged. But, since the “Connect to Server…” option doesn’t seem to honor the smb://localhost:otherport/SHARE_NAME syntax (all progress/error information excluded the alternate port number), I figured I’d try to hook straight into localhost on the standard SAMBA port (139)… which is why I did all the stupid root shit. Normally, I don’t even have to worry about su or sudo b/c the regular user acct. will allow you to map remote low ports to local high ports. Since everything goes over SSH port 22, it wouldn’t even matter if my ISP disallowed traffic on 139 or any other port (save 22).

    Running the port forward ssh -v showed no errors or rejections in the actual setting up of the tunnel. Errors and bad stuff only started happening after attempts to establish the smb connection. Then again, doing it regular style (not through a tunnel, resident on the LAN) and passing user name as an argument never required me to provide a password. But, then again, that’s when shit started disappearing offa’ my Desktop.

    As for smb requiring a separate port for authentication, I’m not sure. I’ll have to break out the O’Reilly book tomorrow to see if that has any add’l info.

    BTW, we’re using SAMBA because it’s the legacy server that the XServe was purchased to replace, which I haven’t set up yet because there’s a ton of shit I have to do before I even consider replicating usernames/numbers/group membership, etc. and then rsync’ing the gigs & gigs of data on the legacy box over to the dual mofo.

Comments are closed.