Open Erik78De opened 5 years ago
My guess is this is a limitation of how of the ChrootDirectory code determines where you are on the file system. Are you allowed to simply enumerate the subfolders in the C:\Symlinks directory structure? Does the behavior change if you use an actual symlink (not a junction) or a volume mounted directly to a folder?
Yes, I can navigate through the structure, and the behaviour is the same wether I use a junction (mklink /J) or a symlink (mklink /d), I don't know any more possibilities how to do this. Actually, the file even gets created, but with 0KB size.
I haven't tried it myself, but I suspect that the only way this is going to work is if you mount a volume to a folder within C:\symlinks. To do that, you need to go into the Disk Management area. Of course, that limits you to only being able to "link" to the roots of those volumes.
On Linux, I believe the symlink would only work in a ChrootDirectory if it points to folder already within the Chroot. So if someone would look into addressing this, it would likely just be to disallow the enumeration and the not allow creation of the file at all.
Sorry, but isn't that a serious bug that should be fixed by the devs?
There's definitely a bug at play, but what it is is debatable. Either you should be able to copy the file or you shouldn't be able to navigate the link. If anything gets fixed, it's probably going to be the latter since that's how Linux behaves.
My problem is that I want to offer two different partitions from my "server" PC, accessible from one common start point, that's why I made it this way: Creating a symlink-path, and putting a link to the C and the D partition there. I am not aware of the situation in Linux, since it does not have that concept of drive letters at all, but from a Windows user's persspective I want to be able to offer both. Before I used SFTP based on SSH, I had a FTP-based solution using IIS, which worked the same way.
So the question is: why shouldn't a user be allowed to do this? The solution to this bug to me is allowing access to the symbolic linked folders, the same way they work without a ChrootDirectory set at all, which also works...
The behavior you are seeing is expected and by design. If symlink is pointed outside of chroot jail, you are not allowed to access that node. I believe this is the same behavior in Unix . If you think otherwise, let us know.
@Erik78De If they are truly two different partitions, just mount the partition as folders under a single subdirectory and that should work. See here: https://docs.microsoft.com/en-us/windows-server/storage/disk-management/assign-a-mount-point-folder-path-to-a-drive
Hi,
We came across similar sftp symptoms in that..
..when using a /D symlink as chrootdirectory (whilst if we dont use a chrootdirectory and navigate to the symlink manually we can indeed download the files from the referred directory, so NTFS is all ok).
Is this something that the code can be updated for, i.e. to allow for file download when chrootdirectory is a /D symlink? or am I doing something wrong?
Info:
sshd_config:
PermitEmptyPasswords no AuthenticationMethods password ForceCommand internal-sftp AllowAgentForwarding no AllowTcpForwarding no GatewayPorts no X11Forwarding no ChrootDirectory C:\the-/D-sym-link Subsystem sftp internal-sftp
Server log: debug3: auth2_update_methods_lists: updating methods list after "password" [preauth] debug2: authentication methods list 0 complete [preauth] debug3: send packet: type 52 [preauth] debug3: mm_request_send entering: type 26 [preauth] debug3: mm_send_keystate: Finished sending state [preauth] debug3: ReadFileEx() ERROR:109, io:000000CFDD89E110 debug3: read - no more data, io:000000CFDD89E110 debug1: monitor_read_log: child log fd closed
Client log (winscp)
2019-10-22 10:49:41.029 Handling network read event on socket 1536 with error 0
2019-10-22 10:49:41.029 Received 38 bytes (0)
2019-10-22 10:49:41.029 Read 4 bytes (34 pending)
2019-10-22 10:49:41.029 Read 34 bytes (0 pending)
2019-10-22 10:49:41.030 Type: SSH_FXP_STATUS, Size: 34, Number: 21251
2019-10-22 10:49:41.030 65,00,00,53,03,00,00,00,03,00,00,00,11,50,65,72,6D,69,73,73,69,6F,6E,20,64,
2019-10-22 10:49:41.030 65,6E,69,65,64,00,00,00,00,
2019-10-22 10:49:41.030 Status code: 3, Message: 21251, Server: Permission denied, Language:
2019-10-22 10:49:41.030 (ETerminal) Permission denied.
2019-10-22 10:49:41.030 Error code: 3
2019-10-22 10:49:41.030 Error message from server: Permission denied
2019-10-22 10:49:41.030 Asking user:
2019-10-22 10:49:41.030 Cannot open remote file '/xxx/xx/x/xxx.txt'. ("Permission denied.
2019-10-22 10:49:41.030 Error code: 3
2019-10-22 10:49:41.030 Error message from server: Permission denied")
2019-10-22 10:49:41.114 Session upkeep
..which is what invokes this error, but I don't understand why this isn't an issue without a chroot jail .
We also have the requirement to do the same. Will this be fixed or do we need to found another sftp solution?
Hi TimPla,
I opened a new issue 1493, as this issue 1403 references outside of the chroot, which we actually don't: Rather our chroot is a symlink, and we stay within the chroot. So, in 1493 I provide a temporary workaround that may work for you as well (but please be aware of the security implications mentioned in 1493).
Kind regards, JJ
Hi, any progress on this issue? We´re facing exactly the same problem
I can also report that I'm getting the same exact issue. The use case in my case was that I wanted to do something like
ChrootDirectory E:\Sftp\Roots\%u
In my configuration, and then just use a hierarchy of directory junctions inside of those SFTP roots to give a "virtual file system" for giving access points into specific parts of the server.
I'm getting the exact same things, I can create directories, delete directories and files, but I cannot upload or download files. It does end up creating an empty file though. So from my point of view, this is broken one way or another. Either it should be impossible to navigate out of the chroot using a junction/symlink, and impossible to do any file operations at all, or it should be possible to do all file operations allowed by ACL.
I also tried a new idea, which was to try to use DFS-N to create this kind of virtual file structure, unfortunately this also does not work because ChrootDirectory does not support UNC paths.
I can also mention this is a fairly common issue to be encountering:
https://superuser.com/questions/1445883/open-ssh-in-windows-10-cannot-copy-files-to-junctions-when-chrootdirectory-is-s https://serverfault.com/questions/967833/issue-hardlink-junction-not-working-when-chroot-all-users-to-c-share-dir-in-win
However, I have identified one possible workaround:
Match User contoso\sftp-user1
ChrootDirectory C:\path\to\stuff
Match User contoso\sftp-user2
ChrootDirectory D:\path\to\different\stuff
Match User contoso\sftp-user3
ChrootDirectory E:\completely\different\path\to\other\stuff
And then you ended up creating individual users for every single directory I want to expose. Pretty terrible, but it has the advantage of working.
One way to make this solution more workable is to just have one single user per directory, use only SSH Key authentication, and manage access by adding/removing SSH keys to those specific users. This way you don't have to be creating a ton of Windows users, but it has the major disadvantage of being harder to audit. (Maybe you can make it log which SSH key was used for every connection? I don't know.)
Of course, I'd much rather either have some kind of "virtual directory" support in sftp, where you can define "virtual mount points" for different directories to be exposed, or simply if somehow symlinks/junctions could be made to "just work" in this case.
If this was Linux, I'd just use a bind mount and call it a day, unfortunately, that's not possible on Windows.
I think the problem is more that that.
The need is to be able to map multiple folders for the same user, thus the need of the symlink.
As an example, I need a shared folder to be accessible by 2 users (but this will escalate) but each of them need their own jailed content. I tried to put the jailed folder inside the shared one but then each of them can see the folder of the other (not navigate to it) but the mere display at the root is not wanted, it must be fully hidden.
Actual folders:
What user1 shall see:
What user2 shall see:
And it's forbidden that any user sees the folder of any other.
like many has mentioned. In chrooted directory I have created directory symlinks to different parts of machine. When you login you are able to access and browse structure. You are also able to create/delete/rename directories. But problem is if you try to upload/download files, then you get error
This is only reason why I can't start using sftp on windows.
Also would suggest to connect with IIS team to see how to add this as option because I would like to replace FTP/S with SFTP.
The fact that symlinks do not work inside of a ChrootDirectory is consistent with how OpenSSH works on Linux so I doubt that's going to change. I know it's not as flexible and a little more dangerous, but a hard link may work.
but it is strange that creating/deleting/renaming folders/files is working in symlinked locations while upload/download files don't work. Shouldn't then even entering/browsing symlink give permission denied? Hard links works on same disk/partition while symlink can point to different disks/partition and even smb locations. But it would be nice to enable upload/download to symlink locations so that we have some flexibility and not that user need to have 10 users because he need access to 10 different locations. I then control what user can with NTFS permissions. Some other sftp servers have similar solution but maybe with virtual folders, and some even have option between system and virtual users. Why not to enable this so that we have good SFTP solution on windows. Maybe option to create some kind of virtual folders with target location under chrootdirectory is better solution. I know that don't exist now but maybe is good feature to implement. I even found this now Simplify your AWS SFTP Structure with chroot and logical directories
I still have the same problem. Any update here?
When I try to copy files to a symlinked / junctioned folder in Windows 10, I get a file of 0KB size and an error "permission denied". Steps to teproduce:
1.) Install the latest OpenSSH Build for Windows (in my case 1607 LTSB, so I install it manually, by downloading the package from the binaries page on Github) 2.) In the Windows file system, create a folder Symlinks on C:. Also create a folder Temp on C:\ to copy data to later 3.) In the Windows file system, create a Junction like this: mklink /J C:\Symlinks\C C:\ 4.) In the sshd_config, set: ChrootDirectory C:\Symlinks 5.) Access your sftp Server using Winscp, Filezilla or a client of your choice 6.) In the sftp client, navigate to /C/Temp (note: /C is the junction we created in setp 3) 7.) the copy process will fail, creating a file of 0KB size, and a permission denied error.
Additional information: if you do NOT set ChrootDirectory, you will be taken to the Users Homepath by default. If you do so, and navigate to your /C/Symlinks/C/Temp folder, and then try to copy a file, everything works fine. So this seems not to be related to any permission issues in Windows. It is some strange behaviour of OpenSSH in combination with ChrootDirectory and Junctions.
Any idea why this is happening? If you need more information, feel free to ask!