SMB over SSH

Securing Windows File Sharing Using SSH Connection Tunneling

Tunneling Windows file shares is useful if you want to comfortably access files on a Windows machine that is only accessible via SSH, and you don’t want to use SFTP or SCP.

To tunnel Windows file shares over an SSH connection, you need to forward connections on port 139 on the sharing-consumer machine via SSH to the sharing-provider machine. The exact setup differs depending on the version of Windows on the sharing-consumer machine:

* Windows 2000: configure the SSH client to listen on interface and connect to ‘\\\sharename’. This is all that is necessary.
* Windows XP: same as for Windows 2000, but before using the forwarded share, the local (client’s) Windows file sharing server needs to be stopped via ‘net stop server’. To disable it permanently, run ‘sc config lanmanserver start= disabled’. To re-enable it at a later time, run ‘sc config lanmanserver start= auto’. Note the space between ‘start= ‘ and the following parameter – sc will fail without it.

If you want to avoid disabling the file sharing server on the client machine because you want to retain remote access to the client machine’s shared resources, there is another alternative. You can install the Microsoft Loopback Adapter according to instructions relevant to your version of Windows:

* The Loopback Adapter and file share tunneling: Windows XP and 2003
* The Loopback Adapter and file share tunneling: Windows 2000
* The Loopback Adapter and file share tunneling: Windows NT4

If using the Microsoft Loopback Adapter, remember to setup your SSH client appropriately: use the Loopback Adapter’s IP instead of or If you assigned the Loopback Adapter the IP address, configure a client-to-server port forwarding rule to listen on, port 139; then you can connect to ‘\\\sharename’.

If the instructions on this page fail for you, try some of the file share tunneling tips contributed by our users.

Note that, in all cases, you will not be able to browse to the sharing-provider machine via point-and-click – the network path needs to be typed in manually.
Step-by-step instructions

Follow these steps if you wish to get quickly up and started with Windows file sharing over SSH. It is advised that you try to understand what is being done by each one of the steps presented. The difference between understanding and not understanding is frequently the difference between a security measure which works and one that only appears to.

On the server machine: (the file-sharing provider)

1. Install WinSSHD on the server (the machine that has the resources you wish to access with Windows file sharing).
2. No changes to the default WinSSHD configuration are required to use Windows file sharing over SSH. You may wish to make changes to the default WinSSHD configuration later on, to restrict what WinSSHD features are accessible to remote users. However, for the time being, keep your WinSSHD settings at default until your file sharing over SSH is up and running.
3. Apart from installing WinSSHD, the only thing you need to do on the server is ensure that there is a Windows account which you can use to log on locally, and which you are comfortable using through Tunnelier and WinSSHD. If such an account does not yet exist, create one and use it to log on for the first time through the local Windows console to make sure all settings for the new account are initialized.
4. Start the WinSSHD service from the WinSSHD Control Panel.

On the client machine:

1. If the client is running Windows XP or 2003 and you wish to retain the ability to share the client’s resources, install and configure the Microsoft Loopback Adapter.
2. Install Tunnelier on the client (the machine from which you wish to be accessing the server machine’s shared resources).
3. Configure the following settings on the Login tab in Tunnelier. Click also the ‘Help’ link on the Login tab for help with any of these settings.
1. Host: The IP address or DNS name of the server that you are accessing.
2. Port: You will normally use the default value, 22. This must match the port that WinSSHD is listening on. If you have made no changes to the default WinSSHD configuration to change the port it is listening on, use 22.
3. Username: The Windows account name with which to log into the server. This must be a valid Windows account name with local logon permissions on the side of the server.
4. Password: The password with which to log into the server, belonging to the account name specified by Username.
5. Store encrypted password in profile: You may optionally wish to enable this setting so that you will not be asked to reenter the password each time when logging in after Tunnelier has been restarted.
4. In the C2S Forwarding tab in Tunnelier, add a new entry and configure the following settings for this entry. Click also the ‘Help’ link on the C2S Forwarding tab for help with any of these settings.
1. Status: This will be ‘enabled’ by default, leave it that way.
2. Listen interface: The default value is If the client machine is running Windows XP, leave this as it is; you will need to uninstall file and printer sharing on the client machine anyway. If the client machine is running Windows 2000, change this to so that you will not need to uninstall file and printer sharing.
3. List. Port: 139.
4. Destination Host: set this to the interface on which the file sharing server is listening for SMB connections. Setting this to ‘localhost’ or will not work because the file sharing server is usually listening on a specific interface rather than all interfaces, so it will not be possible to go through the loopback connection. To determine the interface where the file sharing server is listening, execute ‘netstat -an’ on the server and examine the output for a line like ‘xxxxxx:139 … LISTENING’. The xxxxxx is the IP address that you need to enter in this field. Normally this will be the IP address associated with the server’s main ethernet adapter.
5. Dest. Port: 139.
5. Click the Login button in Tunnelier and observe the log area for any errors. If the session is established without errors, the SSH setup is running.
6. If you are running Windows XP, you will now need to uninstall (not just disable, but completely uninstall) file and printer sharing on the client machine. This can be done through Network Connections : (each connection) : Properties – select ‘File and Printer Sharing’ in the list box and press the Uninstall button. This needs to be done for each active network connection on the client machine.
7. If you are using earlier versions of Windows (this is confirmed for Windows 2000 but is likely to apply to the 9x/Me series as well), you will not need to uninstall file and printer sharing if you specified as the Tunnelier C2S rule listening interface (above).
8. Once the above steps have been completed, you will be able to connect securely to the shared resources on the server machine using syntax such as \\\sharename or \\\sharename, respectively. This will work as long as the Tunnelier SSH connection remains established.
9. You can make sure that your file sharing connections are going through Tunnelier by checking the Tunnelier log area for a message saying ‘Accepted client-to-server connection from … to …:139’ corresponding to each connection attempt you make. Likewise, when your file sharing connection closes, Tunnelier should output a log message stating ‘Closing client-to-server forwarding channel from … to …:139’.


If you encounter problems establishing the SSH session, you will receive diagnostic information in the Tunnelier log area, as well as in the log entries recorded by WinSSHD on the server side. Especially in the case of an authentication failure, the WinSSHD log entries will contain important diagnostic information. Inspect the WinSSHD log entries using the Windows Event Viewer on the server side.

Please see our contact and support page for more information and links to documents about how to go about resolving problems with Tunnelier and WinSSHD.

Related Post

3 Responses

  1. HawkEYE says:

    I got better one after a few minute..
    by adding this two line before line 602 (/usr/share/system-config-network/netconfpkg/gui/

    if (not isinstance (host.Hostname, str)):

    now it works like charms again.. hehe.. 😎

  2. UncleOp says:

    This was helpful. Summary: if the /etc/hosts file is not well-formed, the python script doesn’t handle it well. In my case, somehow a long entry that was commented out got “line wrapped”, leaving some uncommented garbage on the next line. Fixing the hosts file or adding the above patch “worked”. It seems that some complaint to the user should be generated in such a case, though.

    • HawkEYE says:

      @UncleOp , Glad it help.. thanks for dropping by..


Leave a Reply

Your email address will not be published. Required fields are marked *