Strange behavior when tunneling smb -> ssh from windows gui -> samba

[David Lechnyr]

Here's a question that has plagued me for the past year, and I could use
some assistance this time around.  If you tunnel SMB sessions (tcp/139) via
SSH from the Windows CLIENT to a Samba server, all works excellent as long
as you remain in a DOS window.  Changing directories, editing files, and so
forth work seamlessly.  Once you use the GUI portion of Windows, however,
attempting to access any file results in a 58-second GUI freeze-up, after
which the message, "The directory is invalid" appears.  I have duplicated
this behavior across Win95/98/2000/ME, multiple Samba 2.x/2.2/current
versions, and on both remote and same-subnet tests.  Packet logging reveals
nothing useful (at least, from my level of understanding of what I'm
seeing) -- only traffic to and from the two boxes via port 22; no broadcast
traffic or any other traffic of any type.  If it's an errant GUI/API call,
that would suck as there's not much that can be done at that point.

I've attached the smb.log and machine.log files, noting where the 58-second
pause occurs.  The logs are from a Samba 2.2.0a box running on Slackware 8.0
with SSH2 version 3.0.1.  Again, I'd like to point out this does not occur
in the DOS Window portions -- in fact, if my users could do all their remote
file manipulation via DOS, I'd be all for it as it works flawlessly.  The
only think I have not done is to attempt to duplicate this using SSH1 (or
OpenSSH) instead of SSH2.  The attached logs are of simply attempting to
open a single line text file called "INSTALL.txt'.

The goal is to have Windows clients establish local port
forwarding/tunneling for localhost:139 to the samba server:139, so that all
session traffic is encrypted.  Yes, we could have an intermediate samba box
do the port forwarding/encryption, but that would only encrypt traffic
_after_ leaving the samba box, and not before (i.e., unsecured public
network).