SSH Server for Windows: What It Does, What Windows Includes, and How to Set One Up
The ticket says "we need an SSH server on the Windows box." That is one sentence with at least four possible meanings. The developer who wrote it wants a command prompt on the server from her laptop. The partner who prompted it wants to upload files with an SFTP client. The monitoring vendor wants a tunnel to a database port. The auditor, reading the same ticket later, wants to know which of those three things was actually switched on. All four are "an SSH server." Only one of them is what the ticket meant.
This article untangles the phrase. It explains what an SSH server on Windows actually provides, how an SSH server differs from an SFTP-only server, what Windows includes out of the box and where that stops, and when a dedicated server earns its place. It ends with a decision sheet, a hardening checklist, and the commands that prove the thing works before anyone else is told it does.
It sits in our SFTP In Depth series because, on most Windows servers, file transfer is the reason the SSH port gets opened in the first place. The shell is what comes along with it.
An SSH Server in One Paragraph
An SSH server is a program that listens, normally on TCP port 22, for connections that speak the Secure Shell protocol. It checks who is connecting, by password or by key, and then offers that person one or more services inside an encrypted connection: a command shell, file transfer with SFTP or SCP, and port forwarding, which carries other programs' traffic through the same tunnel. Which of those services is actually available depends on how the server is configured, not on the protocol.
Everything that follows comes from the last sentence. An SSH server is a locked door with several rooms behind it. The protocol decides how the door is locked. The administrator decides which rooms exist.
What an SSH Server on Windows Actually Gives You
Four services ride on an SSH connection. Each is a separate decision, and a server can offer any combination of them.
A remote shell. The person who connects gets a command prompt on the server, running as the Windows account they logged in with. On Windows that prompt is a command processor or a scripting shell, chosen by the server's configuration. Everything they can do at the keyboard of that account, they can now do from anywhere the port is reachable. This is the service most people picture when they hear "SSH," and it is the one with the longest list of consequences.
File transfer. SFTP, the SSH File Transfer Protocol, runs as a subsystem inside the connection and gives a client the ability to list, upload, download, rename, and delete files. SCP, the older Secure Copy, moves single files over the same connection with fewer features. Both inherit the login and the encryption from SSH; neither needs a second port. What SFTP is and how it works inside SSH are covered in their own articles.
Port forwarding. The client can ask the server to carry a connection to some other address, so that a database port, a web console, or a remote desktop that is closed to the internet becomes reachable through the tunnel. This is enormously useful for an administrator working from home. It is exactly as useful for anyone else who gets a login, which is why it has its own section below.
Key-based login. The client proves who it is with a private key that never leaves its machine; the server holds only the matching public key. Passwords can be disabled entirely. This is not a separate service so much as a property of the door, but it is the single feature that makes an SSH server safer than almost anything else you can expose, and it is the first thing to configure after installation.
Older servers of this kind also offered telnet, which is the same remote shell idea with no encryption at all. A few products still support it for equipment on an isolated network that speaks nothing else. On a server reachable from anywhere, telnet belongs in the same drawer as the modem.
SSH Server or SFTP-Only Server: Which One Are You Asking For?
This is the question to settle before buying, installing, or opening a firewall rule, because it decides the size of the risk you are taking on. The two things share a port, a protocol, and an encryption layer. They differ in what the person on the other end can do once they are in.
An SFTP-only server accepts the SSH connection, authenticates the user, and offers nothing but the file transfer subsystem. There is no shell. There is no port forwarding. The user sees a folder and can do folder things. If their password leaks, the attacker gets the same folder and nothing else. This is what a trading partner, a customer uploading documents, or a nightly job from another company should get, without exception.
A full SSH server adds the shell and, by default in most software, port forwarding. This is what your own administrators and developers may need, and what nobody outside the organisation should have. A leaked password here is a leaked server, and with forwarding enabled, possibly a leaked network behind it.
Most real deployments want both, for different people. The partner accounts get SFTP only; the two administrators get a shell with keys. Dedicated server software usually lets you set this per account or per group. The built-in Windows server can be made to do it too, with a configuration file and some care, as the OpenSSH-on-Windows article shows. The point is to decide it on purpose. The number of "SFTP servers" that turn out, on inspection, to be full shells for every account is not small, and each one was somebody's quick setup that worked on the first try.
If you have arrived here wanting only file transfer, you may not need this article's remaining sections at all; what an SFTP server is and how to choose one is the shorter road. If you need the shell or the tunnel, read on.
What Windows Includes, and Where It Stops
Current Windows desktop and server editions ship with OpenSSH, the same SSH server that runs most of the world's Linux machines, as an optional feature. It is free, it is maintained by the operating system vendor, and for a single administrator who wants a shell and an SFTP folder on one machine, it is often all that is needed. Installing it takes a few lines in an elevated scripting shell, and the "free SSH server for Windows" that people search for is, in nearly every case, this one.
What it gives you is the four services above, controlled by a text configuration file and Windows accounts. What it does not give you is anything built for running a service for other people. There is no administration interface beyond a text editor and a service restart. There are no virtual accounts: every user is a Windows account, local or domain, with whatever rights that account has on the machine. Confining a user to a folder is done with a configuration block that is easy to get subtly wrong, and the error shows up as a login that silently works with the wrong permissions rather than one that fails. Logging goes to the event log in a form that answers "did someone connect" but not "what did they transfer." There are no event triggers, no quotas, no web interface for the user who has no client, and no second protocol: an FTPS or HTTPS requirement means a second product anyway.
None of that is a criticism. It is a server built for the administrator's own use, and it does that job well. The gap appears the moment the users are not administrators: a partner who needs their password reset at four in the afternoon, an auditor who wants a transfer log, a department that needs a browser upload page. Each of those can be built around the built-in server with scripts and patience, and plenty of people have. Each is also the kind of thing you build once and then explain to your successor for an hour.
When a Dedicated SSH Server Earns Its Place
A dedicated server is worth the money and the installation when one or more of the following is true. The list is short on purpose; if none applies, use the built-in server and spend the budget elsewhere.
- People outside the organisation log in. Partners, customers, and vendors need accounts that are not Windows accounts, that cannot reach a shell, that are confined to a folder without a configuration file, and that someone on the help desk can create and reset without touching the server.
- Someone will ask what happened. A compliance framework, a customer contract, or a nervous manager wants a log that says who uploaded which file when, kept for a defined period, and preferably readable without a parser.
- Things must happen when files arrive. A received file should be encrypted, moved, renamed, or announced by email without a scheduled task polling the folder every minute.
- More than one protocol is required. One partner insists on FTPS, another sends a link to a browser page, the rest use SFTP. One server with one set of accounts beats three.
- The server must be administered from somewhere else, by someone who should not have a shell on it, through a browser or an API.
- Downtime has a cost that justifies a second node and failover.
A product built for this, such as Sysax Multi Server, bundles the SSH server with the parts the built-in one leaves to you: its own accounts alongside Windows and directory accounts, per-account control of shell access and port forwarding, a web administration interface, detailed transfer logs, event triggers, and FTPS and HTTPS on the same box. The trade is cost and one more product to patch. For a server that only you will ever log in to, that trade is a bad one. For a server that fifty partners log in to, it pays for itself the first week.
Setting One Up: The Eight Decisions
Installation is the easy part, and it varies by product, so this section covers the decisions instead. Make them before installing, write them down, and the installation becomes filling in a form. This sheet is worth copying into the change ticket for every SSH server you stand up.
SSH SERVER DECISION SHEET Server name: sftp.example.com (public address 203.0.113.10) Purpose: [ ] partner file transfer [ ] admin shell [ ] tunnel to: ________ Port: 22 (a different port is a nuisance, not a defence) Who logs in: partners: 3 accounts admins: 2 accounts services: 1 account Account source: [ ] server's own accounts [ ] Windows local [ ] domain Shell access: admins only, by key partners: NO shell Port forwarding: OFF for everyone / ON for: ________ (to which hosts/ports) Login method: partners: password + source address limit admins: key only Home folder per account: D:\transfer\<account> confined: yes Host key fingerprint: SHA256:................................ (published to partners on: ____) Logging: connections + file operations, kept ___ days, copied to: ________ Lockout: 5 failures in 10 minutes -> block address 30 minutes Owner / on-call: name, phone Review date: ________
Three of these lines deserve a word each.
Port. Leave it on 22 unless something already uses it. Moving it to another number hides the server from the laziest scanners for about a week and from nobody else, and it costs you a conversation with every partner and firewall team you ever deal with. The firewall rule itself is covered in the port reference for FTP, FTPS and SFTP.
Account source. Domain accounts are convenient for administrators and a liability for partners: a partner account that is also a domain account can log in to things that are not this server. If the product offers its own accounts, use them for anyone outside the building. If it does not, create dedicated local accounts with no other rights and no password expiry surprises.
Host key fingerprint. The server generates a key pair at installation. The fingerprint of its public key is what clients check to be sure they are talking to your server and not an impostor. Record it, publish it to partners through a channel other than the connection itself, and keep the private key with your backups, or a rebuilt server will greet every client with a warning that it has been replaced. How SSH host keys protect transfers explains what the warning means.
Hardening: What to Lock Before You Open the Port
An SSH server on the internet is attacked within minutes of appearing, by programs that try common user names with common passwords all day, every day, forever. This is not a sign that anyone is interested in you. It is weather. The checklist below is what makes the weather irrelevant.
- Keys for administrators, and then disable their passwords. A key cannot be guessed. Once every administrator has a key, turn password login off for those accounts. SFTP authentication covers generating and installing keys.
- No shell for anyone who only transfers files. Partner, customer, and service accounts get SFTP and nothing else. Check it by logging in as one of them and trying to run a command.
- Port forwarding off unless someone can name the destination. If an administrator needs a tunnel to one database on one host, allow that one destination for that one account. "Forwarding on, because it was the default" is how a file server becomes a doorway.
- Lock out repeated failures by address. Five failures in ten minutes, blocked for half an hour, turns the guessing programs into noise. Ending password attacks by design goes further.
- Modern ciphers only. Disable the old key exchange and cipher algorithms the software still offers for compatibility with clients that no longer exist. Cipher policy without a cryptography degree says which.
- Restrict partner logins by source address where the partner has a fixed one. A password that only works from the partner's own network is a much smaller prize.
- Confine every account to its own folder and test it by trying to navigate upward.
- Log file operations, not just logins, and send the log somewhere the server's own administrator cannot edit.
- Patch the server software on the same schedule as the operating system. An SSH server is the most exposed program on the machine.
Meridian Parts learned item three the expensive way. Their SSH server existed so that one supplier could upload price lists. The supplier's account had a password, a confined folder, and no shell, which was correct. It also had port forwarding enabled, because the server's default was on and the setup guide never mentioned it. When the supplier's password turned up in a leaked list, the person who found it could not run a command and could not see any files outside the folder. They could, however, ask the server to forward a connection to the internal database host, which it did, politely, because that is what forwarding is for. The database was patched and firewalled from the internet. It was not firewalled from its own file server. Nobody had thought of the file server as a network device, which it had quietly been all along.
The fix took one line in the configuration and about four months of meetings.
Testing It From the Client Side
A server that works is one that fails in the right places. These checks take ten minutes and are worth running after every configuration change, from a machine outside the server's own network. The sequence below uses the command-line clients that ship with current Windows, macOS, and Linux; a graphical client can do the same things with more clicking.
REM 1. The port answers and the host key matches the one you published ssh -o StrictHostKeyChecking=ask acme-partner@sftp.example.com REM compare the fingerprint it shows with your record BEFORE typing yes REM 2. A partner account gets a folder and nothing else sftp acme-partner@sftp.example.com sftp> pwd sftp> cd .. (should stay put or be refused) sftp> put test.txt sftp> bye ssh acme-partner@sftp.example.com dir REM expected: refused, or a closed connection. A directory listing here is a finding. REM 3. A partner account cannot open a tunnel ssh -N -L 15432:db.example.com:5432 acme-partner@sftp.example.com REM expected: "administratively prohibited" or an immediate disconnect REM 4. An administrator gets in with a key and NOT with a password ssh -i C:\Users\me\.ssh\id_ed25519 admin@sftp.example.com ssh -o PubkeyAuthentication=no admin@sftp.example.com REM expected: first succeeds, second is refused without a password prompt REM 5. Lockout works REM fail a login six times from a test address; the seventh attempt should be refused outright
Keep the output of a passing run with the decision sheet. The next time someone asks whether partners can get a shell on the server, you will have an answer with a timestamp instead of an opinion.
For the file-transfer half of the test in more detail, how to connect to an FTP server and test it walks through connection, login, and transfer checks for FTP, FTPS, and SFTP alike. Setting up an SFTP server on Windows covers the installation steps for both the built-in server and a dedicated one such as Sysax Multi Server, including publishing the host key and adding users and keys.
The Version to Tell a Colleague
An SSH server on Windows is one encrypted door with up to three rooms behind it: a command shell, file transfer, and port forwarding. Decide which rooms each kind of user gets before you install anything. Partners get file transfer only. Administrators get a shell with keys and no password. Forwarding is off unless someone can name the destination. Windows includes a free SSH server that is right for an administrator's own use and short on the things you need when other people log in: accounts that are not Windows accounts, transfer logs, triggers, a web interface, and other protocols. When those matter, a dedicated server is the cheaper option once you count the hours. Whatever you install, test it from outside by trying to do the things that should fail.
Frequently Asked Questions
What is an SSH server?
Does Windows have a built-in SSH server?
Is an SSH server the same as an SFTP server?
What port does an SSH server use?
Is a free SSH server enough for business use?
Should SSH port forwarding be allowed?
From the Sysax team: we build secure file transfer software for Windows. Sysax Multi Server is an FTP, FTPS, SFTP, and HTTPS server. Sysax FTP Automation handles scheduled, scripted transfers. Free trials are on the download page.