-
Notifications
You must be signed in to change notification settings - Fork 768
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CHRoot doesn't work with network shares #1258
Comments
I think it's related to #139. Did you try password based authentication for your scenario? |
This one may be useful FYI too - #518 Otherwise network share paths are not currently supported with CHRoot - try creating a link to the UNC share and see if that works. |
Yes, I used password based auth. |
You cannot mount network shares with „net use“. The sftp users are only able to use sftp and have no shell access. mklink only works locally. This is Windows... not Linux and there is no NFS where this would simply work. I’m sorry, but I do not see any solution in the referenced cases. |
I was hinting at doing something like this on your server mklink /D D:\share \network\share Please note that I haven't tested it out on my end and cannot guarantee that it would work, but I don't see why it would not work either. |
As I know mklink does only work on local disks. You cannot link to a network share. |
Symbolic links work over different volumes, including a UNC path, but you may have difficulties getting |
I just tested the mklink symbolic link for CHRootDirectory and can confirm that it works. Thank you for the solution/idea |
I'm not happy with this dirty workaround. Can you support UNC path, please? |
You still have the issue with your credentials not being available when using SSH keys. This is a fundamental design by Windows and nothing will change that fact. |
I have not used SSH keys yet with this sshd service. Currently the sshd redirects the user to the home dir with d:\ftproot\mywindomain\username automatically. Just a guess, this may not work with ssh keys, too, but does today. |
Is anyone still working on this issue? Because this would add some advantages of being able to limit the folder that user can see by using Access-based enumeration. I now did this by creating symlink but this has the annoying result that you can use the back button in any SFTP client. |
This is by design, we dont allow for network shares for key based auth. |
@maertendMSFT that makes sense for ssh key based auth. But this does add value if you connect password based with AD groups. Additionally windows is adding more and more support for UNC paths over the years and is also used in more and more situations. Of course access errors will always happen with wrong authentication but that is no difference from normal folders? Or am i seeing this wrong? |
If this is by design, what is then the workaround or suggested solution? Is it really necessary to have the SSHD service run on the fileserver cluster, with no possibility to have SFTP servers in a layer in between? I guess that is not supported then? |
@HenningSR i doubt this will be revisited as they closed the issue. But i still don't fully understand this by design decision on this one. However this is just on of the many side projects in windows so i can understand they don't want to spend the time implementing the UNC path because of network/auth stack that is different. However in that case it's not by design but more like work effort vs gain. |
I have locked down a user to sftp only with
ForceCommand internal-sftp
This works:
and here the login fails:
The user has mydomain\foo1 has full permission on
\\cluster1\sftproot\foo1
.Debugging shows chroot path does not begin at root:
How can I use UNC paths? I do not have enough disk space on this ssh server, but on the file cluster... is this just a syntac issue or really not supported?
If not supported, can you support it, please?
The text was updated successfully, but these errors were encountered: