SSH tunnel on Windows 10 to Linux Samba

Question

I know This question has been asked a few times already but I think my problem might be slightly different. Maybe I'm not understanding the fundamentals of the issue.

I have a Linux Samba share that I would like to ssh tunnel and use from Windows. When I am on the VPN I can access the Samba share and tunneling port 139 works fine on Linux. When I access the share from a Linux machine that is off the VPN all I need to do is forward port 139 like so:

ssh user@remotehost -L 1139:localhost:139

And then mount the drive:

mount -t cifs //remotehost/shared /mnt/cifs -o username=myuser,password=mypass,ip=127.0.0.1,port=1139

For Windows I tried following a tutorial to create a loopback adapter and tunnel via PuTTY: http://www.nikhef.nl/~janjust/CifsOverSSH/Win8Loopback.html

This didn't work so I tried following a different tutorial that uses port 139 instead of 445: https://www.simonholywell.com/post/2009/04/samba-file-share-over-ssh-tunnel/

Neither of this tutorials worked so I guess my first question is which of these ports do I actually need to forward? Do I need port 139, port 445, or both? I don't see what the issue could be.

Let me know if you need any other info, I have tried using nmap to troubleshoot but haven't gotten anywhere.

Answer 1

how to proxy smb to a windows 10 client:

short description with ssh n stuff for tunneling

1. launch hdwwiz.exe

2. network adapters -> Microsoft KM-TEST Loopback Adapter -> finish

3. disable everything except ipv4 in that new network sink

4. inside the ipv4 settings set up a ip, 255.255.255.255 as subnet mask and disable netbios

   • if you cannot decide on an ip simply use 192.168.2.123.
     sadly it's impossible to use 127.0.0.2 or similar for this. windows for some unknown reason will not connect to it.

5. elevated windows shell

   • run sc config lanmanserver start= delayed-auto
     this is sadly required since microsoft will bind it's smb bullshit to 0.0.0.0:445 thus making it impossible to listen to that port yourself.
     microsoft also does not want you to use smb on a port different than 445.
   • run netsh interface portproxy add v4tov4 listenaddress=192.168.2.123 listenport=445 connectaddress=192.168.2.123 connectport=44445
     this will ensure that 445 stays bound as soon as lanmanserver starts. thus making it possible for you to just spawn a listener onto 44445 to listen to 445 without eaddrinuse errors etc.

6. edit %windir%\system32\drivers\etc\hosts and add an appropriate mapping like:
   192.168.2.123 smbproxy

7. reboot

8. just use ssh -L 192.168.2.123:44445:internalsmbhost:445 sshuser@publicjumphost

9. open explorer and navigate to \\smbproxy

you can also create multiple mappings in your hosts file for that.
the benefit would be that multiple users of your laptop / pc could access your nas with different usernames / sessions without windows annoying you that someone else is already using that resource.

feel free to open the task creation tool of windows to start this on system startup.

this was taken from my readme.md i made for my websocket proxy https://gitfap.de/GottZ/websocketproxy

---

EDIT: we are in 2020 now. use wireguard for this. it's much more reliable than ssh.

Answer 2

You should only need to forward port 445. In putty the local port should be loopbackIP:44445(or any other unused port) and the forward destination should be localhost:445 or 127.0.0.1:445.

It worked for me follow the procedure in this link: http://how-to.cc/setup-windows-filesharing-over-ssh

Note that all reference to the service 'smb' needs to be changed to the service 'server'.

If it still doesn't work you can try disabling samba v3 on the windows box or try upgrading samba on the linux server. See this link https://it.awroblew.biz/windows-10-and-problems-accessing-smb-shares/

Answer 3

I have made a different approach to this question. I had this question some time ago, and I followed this guide. But it is more complicated and, (I think I remember) the final throughput is low. Please comment if it's not true.

By the way, you only need to tunnel the TCP port 445 for SAMBA Shares to work.

In short, you can create a virtual machine, with VMWare Workstation Player/Pro or any virtualizer sofware, provided they have bridged networking (I only tested with that two versions of VMWare). Install a Linux server distribution of your choice, I chose Ubuntu Server. In network configuration, configure bridged networking. Inside the virtual machine, manually assign an static IP configuration. then create an SSH tunnel to your SAMBA server (obviously through internet), pointing from TCP port 445 in your Virtual Machine, to TCP port 445 too, on the SAMBA server. Once the tunnel is setup, you can access from your Windows 10 computer, typing in your Windows Explorer path bar:

\\<your virtualmachine static IP>\<SAMBA Share in the SAMBA server>\

Now you can access the SAMBA server from your Windows 10 / VMWare-Ubuntu-Server system. If you need a more broad explanation, you can visit my blog post here.

Notes:

• I think (99% sure) the final throughput, with big files, is what your fiber connection allows. For example, if you have 1Gbps internet in your Windows 10 and 1Gbps in your SAMBA server, for big files, you could see a 130MB/s throughput. I tried with a 300Mbps fiber, and it shows a ~35MB/s throughput. With lots of little files it is different, but it's not because of this approach I made, but, I think, the design of SMB protocol.
• VMWare Workstation Player is free for non-commercial use. You can use it in this setup and there are no drawbacks, related to the Pro version.
• If you want to have this setup in a laptop with Windows, moving in and out of your SAMBA server's LAN, you can do a special trick: assign to the VM-Ubuntu-Server the same local IP as the SAMBA server, so that all your shortcuts to the Samba Shares are the same when you're SSH-tunnelling to your Samba Server, or when you're connecting directly to the SAMBA server, in the same LAN. But don't power on your Virtual Machine inside the SAMBA server's LAN!. I think that would give you some sort of networking problem.
• Regarding the SSH tunnel, you can do a custom systemctl service, to automate the SSH tunnel at boot, so you only need to power on your virtual machine to get it working.
• I'm not sure whether the bridged networking would work with a wireless connection. If you want to make sure, comment here and I will check it out.

--EDITED 2023-01-13--there was a typo--

Answer 4

In Windows, there are two issues at play.

1. The Windows SMB Client only connects on port 445.
2. The Windows SMB Server reserves port 445 on all interfaces at startup, preventing other applications from binding to it (for the purposes of port forwarding).

The following steps overcome the second issue, ultimately allowing you to access your SAMBA share from a Windows PC via the SSH tunnel.

Admin rights are required for the initial setup.

Allow binding to 127.0.0.2

netsh interface ipv4 add address "Loopback Pseudo-Interface 1" 127.0.0.2

The following steps configure Port Forwarding to run before LAN Man Service, which will let us reserve 127.0.0.2:445 for our own use.

Inspect the current dependencies for 'Server' service

sc qc lanmanserver

Add 'iphlpsvc' as a dependency. Note - the space after 'depend' is important.

sc config lanmanserver depend= samss/srv2/iphlpsvc

Create a Port Forward between 127.0.0.2:445 and 127.0.0.1:44500. (Since the Port Forwarding Service now runs first, it means it'll be reserved for our use and not automatically taken by the Windows SMB Component).

  netsh interface portproxy add v4tov4 listenaddress=127.0.0.2 listenport=445 connectaddress=127.0.0.1 connectport=44500

Reboot, check:

  netstat -an | find ":445"

Expect:

  TCP    127.0.0.2:445          0.0.0.0:0              LISTENING

You can now create the tunnel:

ssh user@remotehost -L 127.0.0.1:44500:localhost:445

And in Windows, you can browse:

\\127.0.0.2