OpenSSH Server for Windows as an SFTP Server: Setup, Limits, and When to Move Up

The best free SFTP server for Windows is already on the machine. It has been there for years, switched off, saying nothing, while administrators downloaded other things. OpenSSH Server ships with Windows as an optional feature. It is the same software that runs on nearly every Linux server in the world, and it costs nothing. For a company that sells an SFTP server, this is an awkward fact to open with. It is also true, so here it is in the first paragraph.

This article is an honest account of OpenSSH Server for Windows used as an SFTP server. It covers what it is, how to install it, and the six things you must configure by hand before it is fit for outside partners. It says what OpenSSH does well and what it leaves to you. It then compares it with a dedicated server, ours, and says when each is the right choice. The disclosure, as on every page in this comparison: Sysax Multi Server is our product.

It is part of our Best SFTP Server for Windows comparison. The full installation walk-through is in how to set up an SFTP server on Windows. This page is about deciding whether OpenSSH is enough.

What OpenSSH Server for Windows Is

OpenSSH is the open-source implementation of SSH, the Secure Shell protocol. It has a client side and a server side. The server side, a service named sshd, accepts encrypted connections on TCP port 22 and offers three things over them: a remote command line, file transfer by SFTP, and file copying by SCP. An OpenSSH SFTP server and an OpenSSH SCP server are therefore the same service. You do not install them separately.

Microsoft builds OpenSSH for Windows and includes it as an optional feature of current Windows Server and desktop releases. It authenticates Windows accounts, local or domain. It is configured by a text file, sshd_config, in C:\ProgramData\ssh. It is updated along with Windows.

The important thing to understand is its purpose. OpenSSH was built to give administrators a secure command line on a remote machine. File transfer is a second service it happens to provide. Using it as an SFTP server for partners means starting from a tool that offers more than you want and removing the excess. Most of this article is about the removing.

Installing It, in Brief

From an elevated PowerShell prompt, three commands install the feature, start the service, and make it start with Windows:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic

The first start generates the host keys and writes a default configuration file. The installer normally creates a Windows Defender Firewall rule for port 22. At this point any Windows account on the machine can log in over SSH and receive a command prompt. That is a working SSH server. It is not yet something to hand to a supplier.

Six Things You Configure by Hand

These are the gaps between "installed" and "ready for outside users." A dedicated SFTP server closes most of them by default. With OpenSSH each one is a deliberate edit.

1. Restrict transfer accounts to SFTP only

By default a login gets a shell. Put transfer accounts in a Windows group and force that group into the file transfer subsystem. Add this at the end of sshd_config:

Match Group sftpusers
    ForceCommand internal-sftp
    ChrootDirectory C:\SFTP\%u
    PermitTTY no
    AllowTcpForwarding no

2. Confine each account to its own folder

The ChrootDirectory line above does this. It makes C:\SFTP\ followed by the user name the top of what that account can see. Without it, an SFTP user can browse much of the server's disk, limited only by Windows file permissions. Create one folder per account and grant that account rights on it alone.

3. Put public keys where the server looks for them

A user's public key goes in .ssh\authorized_keys inside that account's Windows profile folder. For any account in the Administrators group, the server ignores that file and reads C:\ProgramData\ssh\administrators_authorized_keys instead. The file's permissions must also be tight, or the server silently ignores it. This is the step that produces "the key is installed and it still asks for a password." The key is installed. It is installed somewhere the server has decided not to look.

4. Turn on file-level logging

Out of the box, OpenSSH logs connections and logins to the Windows event log. It does not record which files were uploaded or downloaded. For that, raise the log level of the SFTP subsystem and send logs to a file:

SyslogFacility LOCAL0
LogLevel INFO

Match Group sftpusers
    ForceCommand internal-sftp -l VERBOSE
    ChrootDirectory C:\SFTP\%u
    PermitTTY no
    AllowTcpForwarding no

With SyslogFacility LOCAL0, the service writes to a log file under C:\ProgramData\ssh\logs. The lines are plain text. Turning them into an answer to "did the file arrive on the fourteenth?" is a search you will write yourself, and rotating and retaining the file is also yours.

5. Limit password guessing

OpenSSH has no built-in lockout or automatic blocking of addresses. It relies on the Windows account lockout policy, which locks the Windows account itself. Prefer key-only login for transfer accounts by setting PasswordAuthentication no for the group, and restrict the firewall rule to partner addresses where you can.

6. Back up the host keys

The host key files in C:\ProgramData\ssh are what partners' clients have learned to trust. Copy them somewhere safe. If the server is rebuilt without them, every partner's scheduled job stops with a warning about a changed identity.

After any change to sshd_config, run Restart-Service sshd. The options are explained at length in SFTP server configuration, and the reasoning behind confinement in account isolation and jails on transfer servers.

Adding One Partner, Start to Finish

The six items above are one-time setup. The recurring task is adding a partner, and it is worth seeing in full, because it is the job you will do most often. For a new partner named Meridian, with a key they have sent you:

$pw = Read-Host -AsSecureString "Initial password for sftp_meridian"
New-LocalUser -Name "sftp_meridian" -Password $pw -PasswordNeverExpires -Description "SFTP - Meridian Parts"
Add-LocalGroupMember -Group "sftpusers" -Member "sftp_meridian"

New-Item -ItemType Directory -Path "C:\SFTP\sftp_meridian\inbound"
icacls "C:\SFTP\sftp_meridian" /grant "sftp_meridian:(OI)(CI)M"

That creates the Windows account, puts it in the restricted group, and gives it a folder. Three steps remain, and none of them is a single command.

1. Install the partner's public key in the account's authorized_keys file and set the file's permissions so that only that account, administrators, and the system can read it.
2. Add the partner's source addresses to the firewall rule for port 22, if you restrict by address.
3. Log in as the new account from another machine, upload a file, try to leave the folder, and find all of that in the log.

Then record the account, its owner, and its purpose somewhere a colleague will find it. Done carefully, the whole job takes twenty minutes. Done from memory on a Friday, it takes twenty minutes and a follow-up ticket on Monday. Removing a partner is the same list in reverse, and it is the list that tends not to get run.

Keeping It Current

The OpenSSH version included with Windows is updated through Windows Update, along with the rest of the operating system. That is a real advantage: there is no separate product to track. It also means the included version follows Windows' release schedule, and it can trail the newest OpenSSH release by some time. If a security scan reports your SSH version as old, check first whether Windows has patched the specific issue, since fixes are often applied to the included version without changing the number scanners look at.

Newer builds are published separately for those who need a particular feature. Running one means taking on the updates yourself. For a server that partners depend on, the included version kept current by Windows is usually the calmer choice.

What OpenSSH Does Well

Within its scope OpenSSH is excellent, and it deserves a plain statement of that.

• It is free and already licensed. There is nothing to buy and nothing to justify.
• It is the reference implementation. Every SFTP client in existence is tested against OpenSSH. Compatibility problems are rare.
• Its cryptography is current and well reviewed. Few pieces of security software have had more eyes on them.
• It uses real Windows and domain accounts. For internal staff, there is no second password to manage.
• It is patched with the operating system. No separate update process is needed for the included version.
• It is the same on Linux. An administrator who knows it on one platform knows it on the other.

For a handful of technical users who need SFTP and nothing else, on a server run by someone comfortable in a configuration file, it is the right answer. I would choose it there myself. The general case for open-source tools is made in what open source transfer tools genuinely do well.

What It Leaves to You

The limits are not defects. They follow from what the software is for.

It speaks SSH only. There is no FTPS and no HTTPS. When a partner requires FTPS, or when occasional users need a browser upload page, you run a second product beside it, with its own accounts and its own log.

Every user is a Windows account. Giving a supplier SFTP access means creating a Windows login for the supplier on your server. Many security teams object to that, with reason. A transfer account that is also an operating system account is one misconfiguration away from being more.

There is no administration console. Adding a partner means creating a Windows user, a group membership, a folder, a permission, and possibly a key file in exactly the right place. It is five steps in three tools. It works, and it is the kind of work that gets one step skipped at the end of a long day.

There is no second factor built in for SFTP logins, and no FIPS mode of its own.

Audit evidence is a project. The log exists once you enable it. Searching it, keeping it for a year, and producing "everything partner X sent last month" are tasks you build.

Kestrel Payroll ran OpenSSH happily for three clients. It was configured carefully by an administrator who knew it well. Then the client list grew to forty, and the administrator moved to another team. Her replacement inherited a text file, forty Windows accounts, and a folder of notes. The first new client took him a day and a half to add, most of it spent discovering the administrators' key file rule. The first audit request, for six months of upload history by client, took a week of reading logs. Nothing was broken. The server was exactly as good as it had always been. What had changed was the number of things it was being asked to be.

OpenSSH and a Dedicated Server, Side by Side

The table compares OpenSSH Server for Windows with a dedicated multi-protocol server, using Sysax Multi Server as the example because it is the one we know best. Other commercial servers differ in detail; the main comparison page covers five more.

When to Stay, and When to Move Up

Stay with OpenSSH when all of these hold. SFTP is the only protocol anyone will ask for. The users are few and mostly internal or technical. Giving them Windows accounts is acceptable. Somebody on the team is comfortable maintaining the configuration file, and somebody else could take over. Nobody will ask for transfer history as audit evidence.

Move up when any of these becomes true. A partner requires FTPS, or users need a browser page. Outside parties should not hold Windows logins on your server. The account list has grown past what one person can keep in their head. A security review asks for a second factor, a FIPS mode, or a searchable audit log. Or the one person who understood the configuration has left, which is the most common trigger of all and the hardest to see coming.

Moving is not difficult if you prepare. Keep the host name. Export the host keys and import them into the new server, so that partners' clients see no change. Recreate accounts with the same names and folders. Run the two side by side on different ports for a week. The general method is in our migrating transfer workloads series.

A Hardening Checklist for OpenSSH on Windows

If you are staying with OpenSSH, run this list against the server. It is the six hand-configured items plus the housekeeping around them.

OPENSSH SFTP SERVER CHECKLIST (WINDOWS)      Server: __________  Date: ________

ACCESS
[ ] Transfer accounts are in a dedicated group (for example sftpusers)
[ ] Match block forces internal-sftp for that group
[ ] ChrootDirectory set; each account has its own folder
[ ] PermitTTY no and AllowTcpForwarding no for the group
[ ] Tested: a transfer account cannot open a shell
[ ] Tested: a transfer account cannot move above its folder
[ ] Transfer accounts are not members of Administrators

LOGIN
[ ] Key login works for each account; key files are in the right place
[ ] PasswordAuthentication no for the group, where partners can use keys
[ ] Windows account lockout policy reviewed
[ ] Firewall rule for port 22 limited to partner addresses where possible

EVIDENCE
[ ] internal-sftp runs with -l VERBOSE; file actions appear in the log
[ ] Log file location known; rotation and retention arranged
[ ] A test upload was found in the log

CONTINUITY
[ ] Host key files backed up off the server
[ ] sshd_config backed up, with a note of what each change is for
[ ] A second person has added an account using only the notes
[ ] Service set to start automatically; survives a reboot

The second-to-last line is the one that tests whether the setup will outlive its author. If a colleague cannot add an account from the notes, the notes are the next thing to fix. The wider checklist for any transfer server is in what makes an FTP server secure.

The Version to Tell a Colleague

OpenSSH Server for Windows is a free, included feature that provides SFTP and SCP on port 22 using Windows accounts. It is real, well tested, and patched with Windows. Out of the box it gives every account a command shell, so for partners you must restrict accounts to SFTP, confine each to a folder, place key files correctly, enable file-level logging, and back up the host keys. It offers no FTPS, no browser transfer, no console, and no built-in second factor. It is the right choice for a few technical users who need only SFTP. A dedicated server earns its cost when partners multiply, other protocols are required, or audit evidence is expected.

For the step-by-step installation, see how to set up an SFTP server on Windows. For the other free and commercial servers, see the main comparison and FileZilla Server vs Sysax Multi Server.

Frequently Asked Questions