How to Enable OpenSSH Server on Windows 10 and 11 for Secure Remote Access

The idea itself isn't new, and the "hidden" label in the headline overstates it a little. Microsoft documents the feature openly. The useful part is turning a Windows PC into a proper terminal-managed machine, which takes three steps: install the server, start the service and check the firewall. Here's what that involves, which Windows versions it applies to, and where it stops being useful.

The client is installed. The server usually isn't.​

Most Windows users who type ssh in Terminal are using Microsoft's OpenSSH client. XDA's author said he had been doing that for years without realizing it was a built-in component. The server, sshd, is the part that accepts incoming connections, and it's a separate install.

Microsoft's own install-state table makes this clear:

That table matches the one published in a recent sshflow.com setup guide. Microsoft's getting-started guide sets the baseline as a device running at least Windows Server 2019 or Windows 10 (build 1809). You also need PowerShell 5.1 or later and an account in the built-in Administrators group.

You can confirm the default state yourself. A GitHub note on setting up the server shows the usual result of querying the installed capabilities: the client is installed but not the server, and this is the default configuration.

Summary: If you've used SSH from Windows before, you used the client. To make a Windows PC reachable over SSH, you need the server component as well.

How to enable OpenSSH Server on Windows 10 and 11​

Option 1: Settings​

1. Open Settings and search for Optional features. Depending on your build, the page may be labeled "Add an optional feature" or "Manage optional features."
2. Choose to add or view features, then search for OpenSSH Server.
3. Select it and click Install. Make sure you pick the Server entry. Installing the client again does nothing for incoming connections.

Option 2: Elevated PowerShell​

First, check what's already installed:

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'

Then install the server:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

Microsoft says the command should return RestartNeeded : False.

Start the service and keep it running​

Installing the server doesn't start it. A VirtualizationHowTo guide notes that the service startup type by default is set to Manual. In an elevated PowerShell window, run:

Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'

Microsoft calls the second line optional but recommended. Without it, sshd won't come back after a reboot. If you prefer a GUI, open services.msc, double-click OpenSSH SSH Server, set Startup type to Automatic and click Start.

Confirm the firewall rule​

According to Microsoft, installing OpenSSH Server creates and enables a firewall rule named OpenSSH-Server-In-TCP, which allows inbound TCP port 22. Check that the rule exists rather than assuming it does. If it's missing, Microsoft's documented fix is:

New-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' `
  -DisplayName 'OpenSSH Server (sshd)' -Enabled True `
  -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

This is the step XDA's author means when he says you only need to allow incoming connections through Windows Firewall.

Summary: Install the server, start sshd, set it to Automatic and confirm the port 22 rule.

Connecting and what you get​

From any machine with an SSH client, whether it's another Windows PC, a Linux box or a phone, connect with your Windows account name and the target's IP address or hostname:

ssh [email][email protected][/email]

The first time you connect, the client asks whether to trust the server's host key. Answering yes adds the PC to your known-hosts list. You'll then be prompted for the account password.

The default shell is Command Prompt. Microsoft's example session opens at a plain C:\Users\username> prompt. From there you can type powershell to switch shells, which is what XDA's author does. To make a different shell the default, set a DefaultShell string value under HKLM:\SOFTWARE\OpenSSH. A SAS Workshops write-up shows the pattern: New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Program Files\Git\bin\bash.exe" -PropertyType String -Force. That example points to Git Bash. To use Windows PowerShell instead, point the value at powershell.exe.

Once you're connected, the setup works as XDA describes. You can check processes and services, read system information, change network settings, update packages with Winget, and lock or reboot the machine. The author's favorite use is a lazy one: he opens Termius on his Android phone downstairs and shuts down the PCs upstairs without climbing the stairs. On Windows, shutdown /s /t 0 does that from an SSH session, provided your account has the necessary rights.

The WSL angle and its limits​

The more interesting example in XDA's column is a Paperless-ngx document server. It runs as a Docker container inside an Ubuntu WSL instance on a laptop that a family member also uses for gaming and web browsing. The author can SSH into the WSL environment directly or into the Windows host. He prefers the host because from there he can reboot the machine, troubleshoot at the system level, update Winget packages and create new WSL instances.

Keep in mind that this is one person's home lab, not a guarantee from Microsoft. Two distinctions apply:

• SSH into the Windows host gives you the Windows shell. From there you reach WSL through the wsl command, just as you would locally.
• SSH directly into a WSL distro only works if you've set up a separate SSH server inside that Linux environment. Windows' sshd doesn't provide that.

Neither approach makes every container automatically reachable over the network.

Security: encrypted doesn't mean safe to expose​

Microsoft notes that SSH encrypts all traffic between client and server, which protects against eavesdropping and connection hijacking. Encryption doesn't stop password-guessing, though, and opening port 22 invites login attempts. Some practical steps, based on Microsoft's documentation:

• Use keys instead of passwords. Microsoft's key-management guide recommends public-key authentication and warns that a private key is the equivalent of a password. Standard users keep their keys in C:\Users\username\.ssh\authorized_keys. Administrator accounts work differently: their keys go in C:\ProgramData\ssh\administrators_authorized_keys, and that file's access list must allow only Administrators and SYSTEM. This administrator rule is the most common reason key login fails on Windows.
• Know the identity limits. Microsoft says key-based authentication works with local and Active Directory accounts, but Microsoft Entra ID accounts don't support it. Don't assume every Windows sign-in type will work.
• Restrict who can log in. Use AllowUsers, DenyUsers, AllowGroups or DenyGroups in %ProgramData%\ssh\sshd_config. Where practical, limit the firewall rule to trusted IP addresses.
• Don't port-forward 22 to the internet. XDA's author uses Tailscale for remote access, so the PC is reachable over a private mesh network rather than an open router port. That's a sensible approach, but how you set it up is up to you. Windows doesn't provide it.

Troubleshooting checklist​

If the connection is refused or times out, Microsoft's firewall troubleshooting guide suggests these checks:

1. Is the service running? Get-Service -Name sshd
2. Is it listening? Run netstat -an | findstr :22. You should see 0.0.0.0:22 and [::]:22 in the LISTENING state.
3. Does the firewall rule exist? Check for OpenSSH-Server-In-TCP and make sure it's enabled for your network profile.
4. Is the config valid? Edit C:\ProgramData\ssh\sshd_config, run sshd -t, then Restart-Service sshd.
5. Can the client reach the port? From the client, run Test-NetConnection -ComputerName <host> -Port 22.
6. What do the logs say? In Event Viewer, check Applications and Services Logs > OpenSSH. Log files are also kept in %ProgramData%\ssh\logs.

A refused connection usually points to the firewall. If the port isn't listening, the service is usually stopped or misconfigured.

Where SSH fits alongside Remote Desktop​

XDA's author is fair about the trade-off. SSH doesn't replace a graphical desktop. If you need to click through a GUI installer or see what's on screen, you still need a remote desktop tool. He also notes that the terminal is only useful if you're comfortable with commands.

His strongest argument concerns Windows editions. Windows Home can't host incoming Remote Desktop sessions; that requires Pro or higher. OpenSSH Server has no edition restriction, so a Home laptop running a self-hosted service can still be managed remotely at no extra cost.

The author also says Microsoft "retired the built-in Remote Desktop app." That needs a qualification. Based on general industry knowledge, what Microsoft retired was the Microsoft Store Remote Desktop app, which it moved users off in favor of its newer Windows App. Remote Desktop hosting on Pro editions wasn't affected. Either way, the edition limit is real, and SSH works around it.

Bottom line: Enabling the OpenSSH server takes a few minutes, it's supported and serviced by Microsoft through Windows Update, and it lets you manage Windows PCs the same way as Linux servers. Set up key-based login before you leave it running, and keep port 22 off the public internet.