Member Avatar for BlackPhoenix

Hi, I plan to install an SFTP server on one of our domain servers, but beforehand I wanted to setup a dummy server on one of my local workstations.

I used OpenSSH to setup a home location with the folder named SSHTestBed, full path: C:\SSHTestBed

I also created a new user named sshuser and set his home folder as SSHTestBed.

When I right-click->Properties on the SSHTestBed folder, the Security tab shows these permissions for sshuser:
Allow for Full Control, Modify, Read & Execute, List Folder Contents, Read, Write

I am able to connect without any problems with that user, but what troubled me is that I don't JUST see that folder like I would on an FTP server. I can hit the back button to go back to the C: Drive and move some folders over to the computer I'm connecting from iwth WinSCP.

How do I lockdown the SFTP server so that a particular connecting user doesn't have free access to the machine running the server? :?:

If it helps, the user sshuser is setup locally under Local Users and Groups under "Member Of" under NO group. Could this be the problem?

  • 2 Contributors
  • 1 Reply
  • 216 Views
  • 3 Days Discussion Span
  • Latest Post Latest Post by lolafuertes

Dani AI

Generated

Quick summary and context: described a local OpenSSH test where the SFTP account could traverse back to the C: drive. was right to point at two causes: (a) the server was never configured to “jail” the account, or (b) NTFS ACLs (group membership like Authenticated Users / Users) permit traversal. Both are common; pick the approach below that fits your OpenSSH build and risk model.

On Windows the cleanest fix is to use OpenSSH’s chroot-style SFTP jail (ChrootDirectory + ForceCommand internal‑sftp) in the sshd_config file (Windows default: %ProgramData%\ssh\sshd_config). The basic idea is: chroot the session to a controlled folder tree, and give the jailed user only a writable subfolder inside that tree. Example sshd_config fragment:

Subsystem sftp internal-sftp

Match User sftponly
    ChrootDirectory C:\sftp\jail\username
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

After editing, test (sshd -t) and restart the OpenSSH service. (learn.microsoft.com)

Important permission rules: the chroot root must be owned by the system/administrators account and must NOT be writable by the jailed user; create an inner folder the user owns for uploads. On Windows use icacls to inspect and fix ACLs. Example (run as admin):

icacls "C:\sftp\jail\username" /inheritance:r
icacls "C:\sftp\jail\username" /setowner "Administrators" /T
mkdir "C:\sftp\jail\username\upload"
icacls "C:\sftp\jail\username\upload" /grant username:(OI)(CI)M /T
icacls "C:\sftp\jail\username"   # verify ACLs

Use icacls/takeown carefully; wrong changes on C:\ can break things. (learn.microsoft.com)

If your test install uses Cygwin or an old OpenSSH build, be aware chroot behavior differs and may not provide a true security boundary (Cygwin chroot has known caveats). If chroot isn’t practical, restrict NTFS ACLs so the SFTP account cannot traverse parents, or install the supported Win32 OpenSSH build and then use ChrootDirectory. Check OpenSSH logs and %ProgramData%\ssh\logs for failures while testing. (cygwin.cygwin.narkive.com)

Member Avatar for lolafuertes

Two possible issues.
1) When installing/configuring the server you allowed to access to all system, instead of only to the desired foldeer
2) The sshuser has permission (direct or indirect) to the root of C: drive. In example, all 'Authenticated users' have permissions to create folders below C:\ and all the permissions except Change permissions, Take ownership and Delete subfolders and files. If the sshuser user will be authenticated (accepted by the logon) he will have the permissions.

Hope this helps

Edited by lolafuertes because: n/a
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.