Can not access a mapped network drive through ssh

[Lally11]

I have one server (Microsoft Windows Server 2016) with OpenSSH installed; On this server I have one mapped network drive (K). On this network drive I have one git Project. From another computer I want to clone that git project, but it is saying that is not a git repository. From the server I have direct access to the K.

I have access with ssh to the server, I can clone project that are stored on local drives of the server.

I am using the public key authentication.
How can I clone a project from a mapped network drive from another computer.

[mwtrigg]

On this server I have one mapped network drive (K)

Drives are mapped in the context of user sessions. The "server" does not have a mapped drive. So, has the drive been mapped in the context of the ssh session?

I am using the public key authentication.
How can I clone a project from a mapped network drive from another computer.

Authenticating with a public key will not give you access to network resources from the target machine that require authentication (i.e. the double-hop problem). So, its likely that even if you tried to map a drive, it would fail if it required authentication.
You'll need to authenticate to ssh via password, or kerberos (with delegation)

[jborean93]

Just to add some more info, while you can have a drive mapping for a particular user in the registry they are not actually created by Windows when you logon through the network. They are only done when you have an interactive or RDP logon so if you want to use a mapped drive you need to map it in your session manually. At that point you may as well just use the UNC path.

In saying that what mwtrigg is saying about the double hop problem is going to be an issue when you use public key authentication.

[Lally11]

Hi,

The drive hasn't been mapped in the context of the ssh session.
I am looking for a solution that use the public key authentication.. I don't have knowledge about kerbenos, but for what I read kerbenos seems to be more appropriate from the solution I am searching for.

[jborean93]

If you need to access file on a remote file server you essentially have to provide a way so that the remote session can use that password to access the file server. This can be done automatically if you use password authentication or with Kerberos + delegation. This could also be done explicitly by calling net use with explicit credentials in your SSH session or some other process.

As for mapped drives I would personally give up on using them in SSH. You can always map it manually again in the SSH session but at that point you are better off using the UNC path anyway. Leave mapped drives for interactive usages when you log on normally or with RDP, use UNC for the rest.

[JohnstonJ]

Using UNC paths directly has its own issues, however. For example:

• Visual Studio Code can't work with UNC paths when connecting to VS code over SSH. It just claims the path cannot be found when trying to open. This is despite adding a manual call to "net use" to log in inside of the Windows PowerShell profile due to stored credentionals (e.g. cmdkey) with password authentication doesn't work #2273. Symlinking the UNC path (e.g. C:\repos symlinked to \\host\share\repos) does work, but leads to more glitches in VS Code: Git does not show gutters for symlinked paths that point to a network location microsoft/vscode#229661
• Windows Command Prompt can't have a UNC path as the current directory, which could lead to other issues, starting with a suboptimal experience in the VS Code terminal.

So while the advice to just use UNC paths sounds good in theory, in practice, there is probably well-known software the user wants to use that simply does not play nice with alternatives to mapped network drives, like direct use of UNC paths, or symlinks to the UNC paths. (This is ignoring all the authentication issues, which I worked around with a PowerShell profile containing a net use statement with hard-coded credentials.)