Copying files by sftp to junction not possible under Windows 10 when ChrootDirectory is set in sshd_config

[Erik78De]

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!

[NoMoreFood]

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?

[Erik78De]

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.

[NoMoreFood]

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.

[Erik78De]

Sorry, but isn't that a serious bug that should be fixed by the devs?

[NoMoreFood]

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.

[Erik78De]

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

[manojampalam]

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.

[NoMoreFood]

@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

[jjverschoor]

Hi,

We came across similar sftp symptoms in that..

• we could browse the directory structure and retrieve folder listing, but
• we could not download files with error: permission denied,

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

• windows server 2012R2
• OpenSSH v8.0.0.0 installed in C:\program files\OpenSSH
• 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

EDIT1:
This seems a known error: line 599 of fileio.c reads:

/* on W2012, ReadFileEx on file throws a synchronous EOF error*/
else if ((FILETYPE(pio) == FILE_TYPE_DISK)
&& (errno == ERROR_HANDLE_EOF)) {
debug3("read - no more data, io:%p", pio);
errno = 0;
return 0;

..which is what invokes this error, but I don't understand why this isn't an issue without a chroot jail .

[TimPla]

We also have the requirement to do the same. Will this be fixed or do we need to found another sftp solution?

[jjverschoor]

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

[frankhetterich]

Hi,
any progress on this issue? We´re facing exactly the same problem

[pv2b]

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:

Workaround: Use different users for each folder

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.