Suppose you have a samba server on server S, and wish to connect to it from a machine C. Perhaps you can't connect directly, because either S can't open port 139, or because you don't trust the security of windows file sharing. (Both are good reasons!)
Cast of characters:
The "simple" solution is to disable file sharing on system C and ssh to S, forwarding port 139 via the ssh connection. Then you can connect to your remote samba share by connecting to "\\localhost". You must disable local file sharing, otherwise it will use port 139, making it impossible for you to tunnel another machine to that port. Unfortunately, Windows will not let you specify a port number for an SMB server; it always uses port 139. So forwarding a remote smb server to a local port other than 139 doesn't get you anywhere. Grumble!
The goal of this page is to help you access files on S from machine C without disabling file sharing on C. The same technique can be used (albeit tediously) to mount an arbitrary number of remote file systems via ssh.
Briefly, our approach is to add virtual network adapters to machine C, so that machine C can have more than one port 139. Our real interface will continue to have local file sharing running, but each virtual interface can be used as the end of an ssh tunnel. For example, we can create a virtual ethernet adapter with a IP address of 10.0.0.1, and forward S:139 to 10.0.0.1:139. This clever idea originally comes from http://lists.samba.org/archive/samba/2004-May/085358.html. I've tried to document what worked for me, which was *slightly* different than what they suggested.
We'll give your computer an additional (fake) IP address, and we'll port forward to that address instead of the computer's real IP. Windows XP will continue to do file sharing on the real IP address. We'll assign it an IP of 10.0.0.1 (that's what we configured putty to use above.)
At this point I had to reboot; it didn't tell me to, but it wasn't working.
Now we test out our connection:
If I've missed something, give me a yell.
Others have tried this and emailed me hints and troubleshooting information. I have not verified this information, but I archive it here in the hope that some of it may be useful to you.
Gissur Thorhallsson writes (9/2010):
I was unable to get it working using just the information on your page and after much googling and forum hunting I came across the page below. It has some windows 7 specific steps (SMB driver tweaks, port redirects via netsh and such) that I think could prove valuable for other users of windows 7. http://www.nikhef.nl/~janjust/CifsOverSSH/VistaLoopback.html
Olaf Zehner writes (12/2007): I could see no shares with only forwarding of port 139. After additionally forwarding port 445 on vista-loopback to 139 on samba, it worked. Robert S writes:
I was recently unable to get this to work on a work PC - until I upgraded PuTTY. It might be worth pointing out that this does not work with older versions of PuTTY, even though they allow port forwarding. It certainly works with version 0.56. I am using PuTTY with PowerMenu, which allows you to send the PuTTY window to the system tray. A good way of avoiding desktop clutter. You can download it at http://www.veridicus.com/tummy/programming/powermenu.Andrew Beck writes:
It seems that microsoft networking attempts to use directory services over port 445. If this fails it then attempts to use port 139. Firstly you need to stop port 445 being bound by windows (google gives options). Personally I use my firewall to block outgoing connections on 445. It also appears that if there are no valid interfaces with netbios over tcp enabled, then windows will not attempt to use port 139. If you are using dialup (which doesn't have this option) and don't have a lan connected, chances are samba over ssh won't work. The work around: Add a second loopback adapter with some IP address. Enable netbios over TCP on this adapter. You never actually use this adapter but it's presence causes windows to fall back to port 139 on the loopback being used for ssh fowarding. It is bizarre, but it works!Sam Samdi writes:
Although things didn't initially work for me, the following did (and might be worth adding to your page, if you feel it is appropriate) With the loopback adaptor: I disabled Client for MS Networks and removed the gateway IP from the TCP/IP setup. With my SSH clients: Putty - for the remote machine I put the WAN/internet IP address (127.0.0.1 didn't work). OpenSSH (Cygwin SSH) - in the SSH config file (../home/user/.ssh/config) I put the following lines: LocalForward 139 wanserver:139 GatewayPorts yes (wanserver is my server's WAN/internet IP; GatewayPorts allows the client to tunnel from all loopback adaptors - 10.0.0.1 as well as 127.0.0.1)
Alex Yakushev and Jeremy Ano suggest increasing the "metric" for the loopback adapter so that it is larger than your primary internet connection (9999 ought to do the trick.) Without this, it seems all internet traffic tried to use the loopback adapter (Windows must have assumed some bogus routing information).
Brent Gerig has an idea for an alternative approach: the whole procedure of creating a loopback adapter might be unnecessary, since any address of the format 127.0.0.x is automatically a loopback address (more rigorously, localhost is 127.0.0.0/8). The notion is that you could forward the samba connection from, for example, 127.0.0.2. I wasn't able to get this to work though; it seemed to me that windows built-in networking binds to all these addresses simultaneously (and so 127.0.0.2:139 becomes an alias for localhost:139).
John Goebel writes (2007-10-08):
Thank you very much for these instructions, they worked flawlessly. I did some experimenting when doing this on a second machine and found some things which might be helpful. Of course they may just be idiosyncratic... 1) The "fake" network card does not need a gateway or DNS server specified; very handy for my notebook, which could have a different gateway at different times. 2) Add "10.0.0.1 samba" to your lmhosts file and you can address the samba server as "samba" ( net use f: \\samba\sharename). This is from http://lists.samba.org/archive/samba/2004-May/085358.html . Those instructions almost worked, no doubt I did something wrong.
David Morris has provided an appropriate invocation for openssl-derived ssh implementations, such as the one provided by cygwin (2008-06-11). This is an alternative to using putty.
ssh -L 10.0.0.1:139:localhost:139 someuser@somehost
This page (C) 2003-2004 by Edwin Olson, eolson@mit.edu. All Rights Reserved. Feel free to link to this page, but do not copy it or its figures.