Tunnel Samba over SSH

One day at work, I started wishing that I could save stuff to a drive on my Linux computer at home. I have ssh for Windows installed (http://www.ssh.com/) and it comes with a handy little file transfer utility, but it would be nicer to be able to map a drive letter to my machine at home. Here's my setup: at work, Windows 2000 Professional, with SSH and the Client for Microsoft Networks installed. At home, RedHat Linux 6.1 running Samba, connected to the internet via a DSL connection. (*Note: SSH from SSH Communications Security is free only for educational use, I think.)

My Linux box at home is running a firewall; basically, it only lets secure shell through (in other words, it is not set up to let port 139 traffic - Samba traffic - through). Also, there is a firewall on my connection at work. So any traffic to or from home must travel through SSH. There is a cool way to set this up in ssh called tunnelling. Basically, what we will do is set the Windows SSH client at work to listen on port 139 - the Samba port - and then transfer any traffic, through SSH and encryption, to port 139 on my computer at home. This will end up making my computer at work look like the server, but it will actually be pulling the information from my computer at home.

Disable File and Print Sharing on the Workstation
Because the computer at work (the SSH client program, actually) will be set up to look like the file server, we need to make sure we turn off any real file sharing that the Win 2000 machine at work may be doing. (Note: I have no idea how you set up SSH tunnelling for Samba if you need to keep file and print sharing turned on on your client machine!) According to http://mindterm.appgate.com/pipermail/mindterm-users/2002q1/000516.html, to turn off file and print sharing on your client machine:

My Network Places->Properties->adaptername->Properties, select 'File and Printer Sharing for Microsoft Networks,' and click 'Uninstall.' Don't worry, you can always click 'Install' to put it back. You must uninstall it, un-checking the box does not work (so says the Microsoft documentation, and it's true)
[http://mindterm.appgate.com/pipermail/mindterm-users/2002q1/000516.html]

Then, make sure LMHOSTS is enabled. We will use this file to list the server name and ip address so that the Windows networking client can find its 'server':

On the Win2k box, make sure LMHOSTS is enabled. To do this, go to My Network Places->Properties->adaptername->Properties, select 'Internet Protocol (TCP/IP)', and click 'Properties.' Then click 'Advanced,' go to the 'WINS' tab, and check 'Enable LMHOSTS lookup.'
[http://mindterm.appgate.com/pipermail/mindterm-users/2002q1/000516.html]

Setup lmhosts
Now, we want to create an entry in the LMHOSTS file so that the Windows networking client can find the 'server' we are creating. Go to C:\WINNT\system32\drivers\etc\lmhosts and at the bottom of the file add a line like this:

127.0.0.1  localsrvr

where 'localsrvr' is the name you want to give to your 'server' you are creating. I actually called it 'localsrver', since it is a server that will only be valid on my Win 2000 workstation, and no other servers on the network were called 'localsrvr'. According to the what I read in http://mindterm.appgate.com/pipermail/mindterm-users/2002q1/000516.html, you probably shouldn't put '#PRE' or '#DOM' after this LMHOSTS line, even though some other folks have suggested it. I really don't know the difference, all I know is that I didn't use '#PRE' or '#DOM' and it worked. Also, I experimented with putting a line like:

127.0.0.1  localhost localsrvr

in the C:\WINNT\system32\drivers\etc\hosts file so that DNS can find it - but then I got weird errors something to the effect of 'duplicate hostname found' or something like that. So as near as I can tell, don't put an entry in the hosts file for localsrvr.

Tunneling Setup
Next, we need to set up the SSH client to actually do the tunneling. Under the Edit menu, under Settings, under Tunneling in the SSH client is a list of Outgoing tunnels that we want the ssh client to set up when we connect. Set up one like the following:

 
Basically, listen on port 139 on the local host (the Win 2000 workstation), and send any traffic from there to port 139 on the other end. Use 'Destination Host' of 'localhost' so that on the Linux host, traffic will flow from the ssh client's port '127.0.0.1:xxxx' to the Samba port '127.0.0.1:139'. This way, if you have Samba restricted to only a few networks (which you should), the ssh tunneled connection will still be able to connect. Also, leave the checkbox marked 'Allow local connections only', which I think keeps other folks from connecting to your new 'server' on your local workstation.

Reboot
Now, it is time to reboot the Windows 2000 workstation to let the Windows networking changes we've made take effect. There are probably better ways to reset things than rebooting, but just to be sure...

Test Tunneling
Once the client Windows workstation has restarted, open SSH and log in to the Linux server. Try connecting to Samba from the Linux box itself: 'telnet localhost 139' from the SSH console. It should connect and give you a blank telnet prompt - if not, you need to make sure Samba is running and that it allows connections from the network address 127.0.0.1. (Note: this test may actually work even if Samba doesn't allow connections from 127.0.0.1 - not sure about this.) To get out of telnet, type '^]' - that is, [Ctrl] + the right bracket key. Then type 'quit'. Now, check to see if you can connect to port 139 on your local Win 2000 system. Open a command prompt and type 'telnet localhost 139'. You should get a blank screen or prompt or something - if you get a 'Connection refused' or otherwise couldn't connect, check your SSH tunnelling settings and make sure you have File and Print Sharing disabled/uninstalled. Before closing down your telnet session, switch over to your SSH window and type 'netstat -tn | grep 139'. You should see at least one pair of connections to/from port 139 on your Linux server:

$ netstat -tn | grep 139
tcp  0  0  127.0.0.1:139   127.0.0.1:2708  ESTABLISHED
tcp  0  0  127.0.0.1:2708  127.0.0.1:139   ESTABLISHED

This means that there is a connection from the SSH client at ip address 127.0.0.1, port 2708 to the Samba server at ip address 127.0.0.1, port 139, and vice versa. Make sure that the ip addresses are 127.0.0.1 - otherwise, make sure that whatever ip addresses are there are allowed access to your Samba server. Then, to get out of telnet, type '^]' and then 'quit'.

Test Windows Client
Finally, at your command prompt, type 'net view localsrvr'. Hopefully, you won't get a 'System error 53 has occurred. The network path was not found.' When I got this error, the problem was that I wasn't connecting from 127.0.0.1 to 127.0.0.1 on the Linux server. If you get an 'access denied' error, don't worry, it is probably just because you need to supply a username and password (you have set up usernames and passwords in Samba, right?). Go to Windows Explorer, and type in '\\localsrvr\sharename' where 'sharename' is the name of one of the shares you have access to. If you don't know the name of one of your shares, you can look in your smb.conf on the Linux server. Hopefully, Windows will then ask you for a username and password, and then you should be able to connect, browse, and/or map drive letters.

Connection speed
Connection speed doesn't seem to be too terribly bad - over a slow internet connection, it might be terribly slow. Several people have suggested that it might help to turn off compression in the SSH client, if you have that turned on.

---

(Warning: Don't blame me if you try this and something goes wrong. I offer these tips for free; you get what you pay for. Kansas State University (who hosts this page) and I assume no responsibility for actions you may take in connection with these tips. You may find additional help at http://mindterm.appgate.com/pipermail/mindterm-users/2002q1/000516.html.)