This tutorial contains screenshots for the English version of Windows 10. Separate instructions for older versions of Windows are also available:
To be able to mount a Windows share over SSH we will need
This part of the tutorial is split into the following steps:
Multiple persons have reported problems after a major Windows 10 upgrade (e.g. from 1803 to 1809). This is due mostly to the disappearance of the Microsoft KM-TEST Loopback Adapter and of the portproxy rule. In order to recover after a Windows 10 upgrade, try
To install the Loopback adapter follow these steps:
Start the Add Hardware Wizard by either going Start->Settings->Control Panel->Add Hardware or by starting a console window with elevated (Administrator) privileges. In the console window type
hdwwiz.exe
The Hardware Wizard will come up:
Click Next to continue:
Select Install the hardware that I manually select from a list and click Next.
Now you'll see:
Select the entry Network adapters and click Next.
In the next screen
first select Microsoft from the list of Manufacturers and then select Microsoft KM-TEST Loopback Adapter from the list of Network Adapters. Finally, click Next once more.
Almost finished:
This is your last chance to abort, otherwise, click Next.
After a while you should see:
Click Finish to exit the Hardware Wizard.
You are now ready to configure your newly installed Loopback adapter. Even though Windows might not ask you to, reboot anyways (heey, it's a Microsoft OS ;-)).
From reports I've seen on the Internet a reboot is sometimes required for the loopback adapter to come up properly.
Now that your newly installed loopback adapter is up and running we must configure it properly:
Starting with Windows 10 update 1903 we need to disable the Windows feature SMB 1.0:
(Thanks to Michael Uhlenberg for pointing this out)
Now we first need to tweak a Windows system driver to overcome the thing that Microsoft broke. The root cause of the problem is that we need to access the file share using TCP port 445. However, when Windows 10 boots this port is grabbed by the system lanmanserver
driver for all interfaces. By delaying the startup of the lanmanserver
driver and by installing a portproxy
rule we can circumvent this. This section explains how to do this:
Start a console window with elevated (Administrator) privileges.
First, we disable the automatic starting of the lanmanserver
driver:
sc config lanmanserver start= delayed-auto
NOTE the space after the start=
! Also, if start= delayed-auto
does not work then try start= demand
Make sure the IpHlpSvc
driver is running at startup, as otherwise the portproxy rules are not executed:
sc config iphlpsvc start= auto
NOTE the space after the start=
!
Thanks to Michael Uhlenberg for pointing out this important driver.
Next we add a portproxy
rule to reroute TCP port 445 to a port of our choosing. For this tutorial, I choose 44445:
netsh interface portproxy add v4tov4 listenaddress=10.255.255.1 listenport=445
connectaddress=10.255.255.1 connectport=44445
IMPORTANT NOTES:
listenaddress
is the address of the Loopback adapter configured in the section earlierconnectaddress
must be identical to the listenaddress
listenaddress=127.0.0.1
does not work. Believe me, I've tried.If all went well you should see something like
The portproxy
rule is persistent, so there should be no need to repeat this step after a reboot.
Of course, now that we have disabled the automatic startup of the 'LanmanServer' driver we have to reboot Windows before proceeding.
Verify that the portproxy
was applied successfully by checking the open ports on the system. Type in the command console
netstat -an | find ":445 "
You should see something like:
If you see only '0.0.0.0:445
' instead then the 'portproxy' rule was not applied correctly. Verify that the right 'portproxy' rule was used
netsh interface portproxy show v4tov4
and verify that the IpHlpSvc
driver is running at Windows startup using
sc query iphlpsvc
Another reason for the 'port grabbing' to fail could be the LanmanWorkstation
driver running at Windows startup. If so, try giving it the same treatment as LanmanServer
. However, on the Windows 10 installations I tested this driver was running at system startup without causing any problems.
After Windows comes up and you have logged in, check the status of the 'lanmanserver' driver. Open a command console (no privilege elevation is required) and type
sc query lanmanserver
The 'LanmanServer' driver should be in the state Running. If it is not, then follow these steps to create a task using the Task Schedule to start it at system startup.
On Windows 10 things are slightly different compared to Windows 7 and 8; it seems that Microsoft has read my tutorial and decided to provide a way to use local shares again ;-) !
Now that we have configured both our loopback adapter we can put it all together by launching a special OpenSSH connection and mounting our Nikhef home directory as a Windows share:
Launch an OpenSSH session with some special port-forwarding rules and login on login2.nikhef.nl
as normal. Open a Command console or terminal and type:
ssh -v -N -n -L 10.255.255.1:44445:beuk.nikhef.nl:445
Yes, there are lots of colons in that -L
option but you need them all.
The first time you start the command with the special port forwarding rules, you will be (probably) be prompted by the Windows Defender Firewall that it has blocked some features:
Allow access to at least Public networks by ticking the checkbox, then click on Allow access as otherwise the port-forwarding will not work.
Make sure port-forwarding is working properly by checking the (verbose) log:
Make sure the line
debug1: Local connections to 10.255.255.1:44445 forwarded to remote address beuk.nikhef.nl:445
is present before continuing.
Go to Start->Run and type \\10.255.255.1\user\<Your-nikhef-userid>
In the Console window you should now see a line
debug1: Connection to port 44445 forwarding to beuk.nikhef.nl:445 requested.
as in the following screenshot:
If this is present then you can decrease the debug logging of the OpenSSH session by removing the -v
option from the command line:
ssh -N -n -L 10.255.255.1:44445:beuk.nikhef.nl:445
Note If you carefully inspect the above screenshot then you will notice that I am using the (built-in) OpenSSH Authentication Agent in combination with an SSH public/private keypair to avoid having to type in my Nikhef password every time.
You will be prompted to authenticate yourself:
For the Username, fill in the domain NIKHEF\ followed by your Nikhef-Windows userid.
For the Password, fill in your Nikhef-Windows password, which might be different from the password you use to log in on login2.nikhef.nl
and press OK.
You should now see your Nikhef home directory in Windows Explorer!
Congratulations!
To make life even easier it might be handy to map a network drive to your Nikhef home directory:
login.nikhef.nl
and press OK.For those wishing to undo the CIFS-over-SSH trick follow these steps:
Start a console window with elevated (Administrator) privileges.
Restore the automatic startup of the lanmanserver
driver by typing
sc config lanmanserver start= auto
NOTE the space after the start=
!
Remove the portproxy
rule by typing
netsh interface portproxy delete v4tov4 listenaddress=10.255.255.1 listenport=445
Remove the firewall rule to allow SSH to do portforwarding from 10.255.255.1:
Start a Device Manager
by typing
devmgmt.msc
Expand the 'Network Adapters', right-click on Loopback adapter and select Uninstall.
If necessary, use the 'Task Scheduler' from the 'Administrative Tasks' menu to delete the task 'Start LanmanServer driver'
_That's all, folks!_reprint:https://www.nikhef.nl/~janjust/CifsOverSSH/Win10Loopback.html#Install
Comments to Jan Just Keijser | lastmod = 26/01/2021 14:42
手机扫一扫
移动阅读更方便
你可能感兴趣的文章