Skip to content
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

Closed
alexhass opened this issue Sep 26, 2018 · 16 comments
Closed

CHRoot doesn't work with network shares #1258

alexhass opened this issue Sep 26, 2018 · 16 comments

Comments

@alexhass
Copy link

alexhass commented Sep 26, 2018

I have locked down a user to sftp only with ForceCommand internal-sftp

This works:

Match User mydomain\foo1
ChrootDirectory c:\inetpub\sftproot\foo1

and here the login fails:

Match User mydomain\foo1
ChrootDirectory \\cluster1\sftproot\foo1

The user has mydomain\foo1 has full permission on \\cluster1\sftproot\foo1.

Debugging shows chroot path does not begin at root:

debug1: sshd version OpenSSH_for_Windows_7.7, LibreSSL 2.6.4
debug1: user mydomain\\foo1 matched 'User mydomain\\foo1' at line 86
chroot path does not begin at root
debug1: do_cleanup
debug1: do_cleanup
sshd.exe exited on CLUSTER1 with error code 255.

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?

@bagajjal
Copy link
Collaborator

I think it's related to #139.

Did you try password based authentication for your scenario?

@manojampalam
Copy link
Contributor

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.

@manojampalam manojampalam changed the title chroot path does not begin at root (with UNC path) CHRoot doesn't work with network shares Sep 26, 2018
@alexhass
Copy link
Author

alexhass commented Sep 26, 2018

Yes, I used password based auth.

@alexhass
Copy link
Author

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.

@manojampalam
Copy link
Contributor

manojampalam commented Sep 26, 2018

I was hinting at doing something like this on your server

mklink /D D:\share \network\share
set CHRoot to D:\shareLink

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.

@alexhass
Copy link
Author

As I know mklink does only work on local disks. You cannot link to a network share.

@jborean93
Copy link

jborean93 commented Oct 2, 2018

Symbolic links work over different volumes, including a UNC path, but you may have difficulties getting mklink to create a symbolic link as a folder if it can't access the target properly. Junction points and hard links must be situated on the same volume though.

@sipho102
Copy link

sipho102 commented Oct 2, 2018

I just tested the mklink symbolic link for CHRootDirectory and can confirm that it works. Thank you for the solution/idea

@alexhass
Copy link
Author

alexhass commented Oct 31, 2018

I'm not happy with this dirty workaround. Can you support UNC path, please?

@jborean93
Copy link

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.

@alexhass
Copy link
Author

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.

@krapgras
Copy link

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.

@maertendMSFT
Copy link
Collaborator

This is by design, we dont allow for network shares for key based auth.

@krapgras
Copy link

@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?

@ghost
Copy link

ghost commented Sep 23, 2021

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?

@krapgras
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants