Using WinSSHD as SFTP, SCP file server

WinSSHD is a capable SSH server which provides multiple ways of secure remote access to Windows. However, a very frequent usage scenario is to configure WinSSHD strictly as a file server, without exposing the machine to terminal shell, tunneling and other types of access. This tutorial explains step-by-step how to configure WinSSHD for a primary role as an SFTP and SCP file server.

1. Install WinSSHD. Do not start it yet.

2. Click Edit settings. If you have already performed any changes to the settings here, select the root 'Settings' page, click 'Load defaults', enable 'Reset settings to defaults in all descendant pages in the hierarchy', and click OK. This will bring you back to the initial default configuration.

3. Go to Access control > Windows groups. You should see a single group of type 'everyone'. Edit the settings for this group. Disable the Login allowed setting. Click OK. This will prevent direct login into WinSSHD with Windows usernames and passwords.

4. Go to Access control > Virtual groups. There should be a single group called 'Virtual Users'. Edit the settings for this group.

   1. Leave the Windows account domain and Windows account name empty. WinSSHD needs a Windows account to provide a security context for the SSH session. Leaving these settings empty instructs WinSSHD to use a local account that is created and managed by WinSSHD automatically. (This requires WinSSHD 5.02 or newer.)

   2. Disable the following settings:

      • Permit terminal shell. This prevents your users from accessing the command interpreter.

      • Permit exec requests. This prevents your users from executing arbitrary programs via SSH.

      • Permit C2S port forwarding. This prevents your users from accessing other network services through WinSSHD.

      • Permit S2C port forwarding. This prevents your users to provide access to their own network services through WinSSHD.

   3. Change also the default virtual filesystem mount point: set it to a harmless, empty directory. This protects against failure to configure a proper virtual mount point for a particular user. You can change the default mount point by clicking 'Mount points' under 'Virtual filesystem layout' in the page tree on the left, then clicking Edit and setting 'Real root path' to an innocuous directory.

5. Now, go to Access control > Virtual accounts and set up as many accounts as you like. For each account, you only need to set the following settings:

   • Virtual account name. This is the name that your user will use to log in.

   • Virtual account password. This is the password that your user will use to log in (unless you set up public key authentication).

   • Virtual group. Unless you create additional groups, or rename the existing one, you only have one option here: the default group, 'Virtual Users'.

   • Use default layout (under 'Virtual filesystem layout'). Turn this off to configure a virtual filesystem mount point for the user.

   • Mount points under 'Virtual filesystem layout'. Set the default mount point to a directory to which you want to restrict the user. Make sure that the backing Windows account has the desired read or write permissions to this directory.

     You will probably not want to use the default setting here (Real root path set to empty): it provides access to all parts of the filesystem accessible with the backing Windows account's permissions. This is good for remote administration, but unsuitable for a more restricted setup as a file server.

Having configured WinSSHD in this way, it will only accept connections from users who know one of the Virtual account usernames and passwords you have defined. WinSSHD will allow these users to only use SFTP or SCP, and none of the other SSH protocol features, and will restrict their file access to each user's virtual mount point folders.

To guarantee that your users can access the directories you configured for them, make sure that the Windows account WinSSHD_VirtualUsers has Windows filesystem permissions to access those directories. The WinSSHD_VirtualUsers account is not created until WinSSHD has been started at least once, and may be named differently if you installed WinSSHD as a named site. Run "net user" from a Command Prompt to discover the name of this Windows account.

If you installed WinSSHD on a domain controller, the above steps will not be sufficient. Domain controllers do not have local accounts, so WinSSHD cannot manage a local account to provide the security context for virtual users. In this case, consult Configuring groups and accounts in WinSSHD to learn more about how WinSSHD operates, so that you can configure it properly.