Cannot access network drive from ssh session

[altaurog]

I have Windows 7 running in a virtualbox vm on a debian 8 host. I have a vbox 'shared folder' set up, which appears on the windows machine as a network drive (\\vboxsrv\myshare) and is mapped in the explore to the E: drive:

C:\Users\IEUser>wmic logicaldisk get caption,description,volumename
Caption  Description         VolumeName        
C:       Local Fixed Disk                    
D:       CD-ROM Disc         VBOXADDITIONS_5.  
E:       Network Connection  VBOX_myshare

When I connect to the windows machine by ssh, I can't see the share:

$ ssh w7
IEUser@localhost's password: 
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

IEUser@IE9WIN7 C:\Users\IEUser>wmic logicaldisk get caption,description,volumename
Caption  Description       VolumeName        
C:       Local Fixed Disk                    
D:       CD-ROM Disc       VBOXADDITIONS_5.  

IEUser@IE9WIN7 C:\Users\IEUser>net use e: '\\vboxsrv\myshare'
System error 67 has occurred.

The network name cannot be found.

I found mention of this in a cygwin thread, but even if that were relevant, a non-cygwin implementation of the solution there seems less than ideal. It looks like I would wrap the sshd in a .bat file and use nssm or srvany to create a service out of it, but I imagine stopping and starting the service would not work as expected because sshd would be be a child process.

[manojampalam]

This is by design. Mapped network drives are associated with a logon session. SSH remote sessions are created with an associated network logon session (these are independent of other logon sessions).

[altaurog]

Got it. But in that case, should there not be a way to map the drive within the ssh session so I can access it? I got an error when I tried to do that, (as shown above).

[quamrulmina]

You can map drive within sshd sesion if you did login with password as follows:
net use t: \vboxsrv\sharename

If logged in via public key or the remote share need a different username and password credential, you can do as follows:
net use t: \vboxsrv\sharename /user:domainname/username *
then type the password when prompted.

[altaurog]

Huh, so it does. That is strange, because I tried it before (with password login) and it didn't work, as I wrote above.

[Ventusfahrer]

well, just to make a comment on network drive letters.

I personally don't like them, because they had a lot of side effects, which are not always visible immediately.

• they are only valid in the session (desktop session) they are created in. They are not visible in the session where the Windows Services are running in. This is also a problem when writing applications you are goint to run as Scheduled Task
• They are user specifc. (keep in mind, that a user account name is only a label, the user is internal idendified by a unique identifier (SID), which is always different for local acounts on different machines and domain accounts. Create a user "peter" on a local machine, deleting the account and create it again on the same machine will result in two different SIDs for this user (with of corse different home directories). c:\users\peter is owned by the first "peter" logged on to the machine. The second user Peter will get an appendis of computername or domainname (depending where the second users belongs to). If this is still not unique, a number is appended to the username.domain.0001 (in case of recreated users after deletion)
• if you define persistent network drive letters - they are not working outside an explorer context. Only the explorer.exe able to reconnect them
• Network drives connected in explorer are not accessible in elevated programs and vice versa
• They are limiting the number of disk volumes you can mount on servers - the alphabet still has only 25 Letters.

Since Windows Vista we are able to use Symbolic Links, allowing you to link UNC path based Directories and Files into the local filesystem, without using network drive letters.

If you need to use a different credential on the network connect, then you should use the Windows Credential Manager (Control Panel) to store the credentials to this location. If you want to define the credentials in cmd.exe, powershell or ssh - then use cmdkey.exe - it will store it in the Windows Credential Manager.

best regards

Peter

[DarwinJS]

You could also try subst on Windows 7 - which can be used on network resources subst e: '\vboxsrv\myshare'

However, you may also be running into Windows built-in protections against delegated authority attacks that prevent pure Windows to Windows WMI calls from getting to network resources on the remote end point.

[zhutouxu]

@altaurog I have met the same problem in windows Server2008 R2. I was login with password method ,when I type 'net use x: \server\folder' , return error msg "System error 67 has occurred.The network name cannot be found." did you have a resolution for this problem ?

[altaurog]

@zhutouxu sorry, no. I believe subst worked reasonably well for me, but I recall that for other reasons SSH just wasn't a workable solution and I ended up just using remote desktop or local VBox.

[DarwinJS]

If you run the SSHD server as the same user you logon to the desktop with AND set EnabledLInkedConnections registry key (https://www.youtube.com/watch?v=kYICwkCnUIk) then you should see the same network drives as the interactive logon.

[uzytkownik]

In my case (on Windows 10) subst displays that path was not found and net use returns error 58.

EDIT: For whatever reason I need to specify both username and password.

[megahall]

@DarwinJS You misspelled EnableLinkedConnections which makes the advice not work.

This is what you actually want:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v "EnableLinkedConnections" /t REG_DWORD /d 0x00000001 /f

[megahall]

However, in my experience, even when following the advice, the mapped drives are still broken. So I think this is a real bug which should be fixed if IT Admins are going to use this successfully for a whole lot of headless SW install tasks and other common SSH uses.

[mgkuhn]

That drive mappings remain restricted to a single session is perfectly sane and fine. However, the problem remains that we still can't access SMB network shares via ssh. The real problem here is #996, namely that sshd does not set up the user-process properly in a new terminal-server session to allow it to store credentials, and therefore both CMDKEY and NET USE fail when they try to store a credential needed to access a file share. That has nothing to do with drive letters (which I'd also rather not use for all the reasons given by @Ventusfahrer, in favor of UNC paths).

[Bruinbrum]

I don't quite agree with the design reasoning given by manojampalam.
We want to use ssh as a secure access to a Windows system for use from Jenkins.

• If I use username:password to connect, then i can map network drives, but I also go to a different 'home'
• If I use the secure key, then I cannot map network drives

So, to use the network drive, I have to go to a more insecure method.

As mgkuhn commented, the problem of accessing network shares via ssh remains. sshd needs to setup the user process such that this will work. Further our network shares are offered by a filer, so I don't want to setup sftp from somewhere else to get the data.

[tekknow]

@megahall Your solution did not work for me. I RDP'd into the remote windows server (which has D: mapped to another remote server and can be seen in Explorer) and issued the reg add command. The registry entry was added successfully. Then I ssh'd into the same remote windows server and did a cd to /cygdrive, then ls. No "d", only "c".

[bersbersbers]

If you run the SSHD server as the same user you logon to the desktop

@DarwinJS how do you do that? I get an Error 1297 if I set the OpenSSH service to start as myself.

[leiless]

This is by design. Mapped network drives are associated with a logon session. SSH remote sessions are created with an associated network logon session (these are independent of other logon sessions).

For those use network drive who struggled with The system cannot find the path specified. error, I recently solved this problem by writing a simple shell wrapper(agent).
And changed the HKLM\SOFTWARE\OpenSSH\DefaultShell key to the agent shell path.

The shell agent simply do two things:

1. Mount a Samba file system to Z:
2. Run cmd.exe(powershell.exe, bash.exe is also possible) as regular

$ ssh [email protected]
[email protected]'s password:
Microsoft Windows [Version 10.0.19041.685]
(c) 2020 Microsoft Corporation. All rights reserved.

lei@DESKTOP-1MHRADK C:\Users\lei>net use
New connections will be remembered.


Status       Local     Remote                    Network

-------------------------------------------------------------------------------
OK           Z:        \\192.168.2.234\foobar    Microsoft Windows Network
The command completed successfully.


lei@DESKTOP-1MHRADK C:\Users\lei>

---

For whom interested in how the agnet shell implemented, the core part(wrote in Golang):

func main() {
	config, err := newConfig(configFile)
	if err != nil {
		panic(err)
	}
	if err := config.mountSamba(); err != nil && err != errDriveNameAlreadyAssigned {
		panic(err)
	}

	args := os.Args[1:]
	cmd := exec.Command(config.Shell, args...)
	cmd.Stdin = os.Stdin
	cmd.Stderr = os.Stderr
	cmd.Stdout = os.Stdout
	if err := cmd.Run(); err != nil {
		if e, ok := err.(*exec.ExitError); ok {
			if e.ExitCode() != -1 {
				os.Exit(e.ExitCode())
			}
		}
		panic(err)
	}
}

---

Update:
A more simple way is that simply reuse ssh connection, when the ssh connection established, use net use to mount network drives.

[mgkuhn]

As mgkuhn commented, the problem of accessing network shares via ssh remains.

The very elegant solution that has since emerged, at least for servers in an Active Directory Domain, is GSSAPI authentication and ticket delegation. If you delete your authorized_keys file on the server (to disable accidental use of public-key authentication), and instead use (on Linux) kinit user@DOMAIN ; ssh -K host to authenticate via Kerberos and delegate from the client to the server your Kerberos ticket, then that enables the server to use your delegated ticket to access your files on a file server on your behalf for you, and you can simply pushd \\share\path\... into the filer UNC path that you want (which will automatically allocate a drive letter as needed, for authentic MS-DOS “look and feel”). That has all worked very well since #1295 was closed by the release of OpenSSH for Windows v7.9. You really don't want to use SSH public-key authentication in an Active Directory domain any more, because it cannot not delegate any credentials for accessing further domain resources.

[nhatkhai]

You can map drive within sshd sesion if you did login with password as follows: net use t: \vboxsrv\sharename

If logged in via public key or the remote share need a different username and password credential, you can do as follows: net use t: \vboxsrv\sharename /user:domainname/username * then type the password when prompted.

1. Look - run automation like Jenkin and passing password around isn't secure at all.
2. This OpenSSH design some how only allow remote in with account and password IFF that account not Admin on the sshd server. This kind of solve the #1 issue by having the Jenkins pre-remote with password. The whole session no longer needed password for access any network file. However, Jenkins Jobs that needed run as admin on the remote machine, it then cannot access network without passing password around!
3. Why Cygwin sshd work perfectly with admin and accessing network using account password. It do not have such weird #2 restriction that causing us count less hours of figuring how to work around with Win-OpenSSH.

Please - allow mode that we can remote in as admin, AND accessing network at least via a account and password method.

Cheers,

[nhatkhai]

The current possible way I found was that run the sshd with a valid domain account (don't use the default Local Account). Have that domain account set as admin on the remote host, and allow that account to access network files.