Network share unaccessible through SSHd

[MrBatschner]

Host: Windows 2016 x64 with OpenSSH Build 0.0.8.0
Client: PuTTY or xterm

I will refer to the Windows 2016 host with OpenSSH on it as WINHOST.
It is not member of any domain.

We have a networkshare \\server\share, that is open to anyone.

Logging in to WINHOST through RDP and issuing
"dir \\server\share" gives me the directory listing of
\\server\share (without any additional authentication).

Logging in to WINHOST through SSH (same user) and issuing
"dir \\server\share" gives me "Access denied.".

I don't know if this is behavior intended or if there is something
I am missing but anyway, here is the issue report.

[megamorf]

I believe the devs said that logging in via sshd results in a network logon (similar to the double hop problem in PowerShell or when you invoke mstsc with /restrictedAdmin). That means that you only have access to the local system and that you'll have to reauthenticate against other network resources (e.g. net use or New-PSDrive).

[manojampalam]

Yes. This is by design and going by the rules of standard Windows security.

It basically prevents exploiting user's security creds on a compromised host. That said, the design only benefits key based authentication. Since for Basic (password) auth, a compromised host can intercept and steal user creds anyway.

+1, if you feel that we should relax this restriction for Basic auth.

[MrBatschner]

+1
Thank you for the clarification, I understand that this is a security feature.
But how about this scenario: Logging on to a compromised host with key based authentication, so far, my user creds are still fine. I want to access \\server\share and need to provide credentials again (which I would not with an interactive logon). At this point, my creds can be intercepted.
Don't know if you consider this a possible threat, but could you make relaxing these restrictions a configurable option?

[gd197]

+1 IMHO
We fall into this issue and have to write a powershell script which execute the mount with the New-PSDrive command with authentication based on an encrypted file for each ssh logon.
Maybe a configuration option relaxing the security at the service level (or account) can do the trick?

[rghash]

+1 for us as well. We want to use the sshd to remotely start server processes using password authentication, but the remotely started processes needs to access network shares that the userid already has access to, but can't figure out how to get this to work...

[zbordas]

+1 too.

[manojampalam]

Basic authentication is now relaxed. You can do double hop with Basic auth.

[joeyaiello]

Closing as this should work now. If not, feel free to reopen

[TBBle]

Is there any chance of this being changed for public-key connections? Or are we going to need to wait for Kerberos delegation support in this OpenSSH port?

I'm hoping to migrate away from the Cygwin-based OpenSSH daemon: It allows network access from public-key auth, but has a 230-ish character command limit. I believe this works because the service is running as the target user. This is for use as an automated build-slave, so we only really care about one user.

[manojampalam]

This can't be changed for public-key connections, since the underlying Windows APIs don't give us that support. Unfortunately, Kerberos delegation is not coming anytime soon either.

We'll try to get Agent forwarding online in a couple of months - hopefully, this should help you a bit.

[rkeithhill]

@manojampalam What is this:

We'll try to get Agent forwarding online in a couple of months - hopefully, this should help you a bit.

And is it online? We've just run into this with a script we use so there is no option that we've found to provide the password to the ssh.exe. We haven't found an sshpass that runs on Windows. Our current solution is to punt on OpenSSH completely and revert back to using Putty. :-(

[bagajjal]

@rkeithhill - Try this in a powershell window,

1. Set the ENV variables
   $env:DISPLAY = 1
   $env:SSH_ASKPASS="$($env:ComSpec) /c echo user_password"

2. Now do SSH. It shouldn't ask password.
   ssh user@ip

[lygstate]

ping for sshpass support

[I1eoThe0ne]

Work-Around (since - unfortunately - logging in using key-files does not authenticate agains the AD)

net use z: \server\share /user:userName password

After the net use command the user is authenticated - even against the AD and you can access network shares.

[derSchweiger]

We'll try to get Agent forwarding online in a couple of months - hopefully, this should help you a bit.

+1 for this forwarding agent if it allows us to access network resources while authenticating with ssh keys.

[mgkuhn]

Note that Kerberos/GSSAPI authentication and delegation have been available since OpenSSH for Windows 7.9, so in case you are in an Active Directory domain, then that is usually the nicest solution.