In current versions of Windows an SSH server is built into the system and is enabled as a regular component — no third-party software is required. It can be turned on through system settings or with a single PowerShell command.
How logging in to Windows differs from logging in from Windows
This is about a server on Windows waiting for an incoming SSH connection, not about connecting from Windows to a server on Linux — these are two different roles of the same protocol. For connecting from Windows to a Linux server there is a separate guide — first connection to a VDS over SSH.
Enabling the built-in SSH server step by step
The server is enabled in four actions: add the component, start the service, set it to start automatically, and open the port in the firewall — skipping any of these steps means an incoming connection simply never arrives.
- Add the OpenSSH Server component in system settings
- Start the sshd service
- Set the service to start automatically at system boot
- Open port 22 in the Windows firewall
Add-WindowsCapability -Online -Name OpenSSH.Server # Install the component
Start-Service sshd # Start the service
Set-Service -Name sshd -StartupType Automatic # Enable autostart
New-NetFirewallRule -Name sshd -DisplayName "OpenSSH Server" -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22All four commands run in PowerShell with administrator rights; once they finish the server already accepts connections, and all that is left is setting up the login itself.
Which shell opens by default and how to change it
By default the built-in server opens the classic command prompt, not PowerShell — for many people that is a surprise on the first connection.
reg add "HKLM\SOFTWARE\OpenSSH" /v DefaultShell /t REG_SZ /d "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" /fThe command changes the default shell to PowerShell for every later connection; it takes effect right away, and restarting the service is not required.
Logging in with a key: where to put the public key
The path to the key file depends on whether the user logs in as a regular account or as an administrator — this exact difference is the most common reason a key "does not work".
| User type | Path to the key file | Detail |
|---|---|---|
| Regular user | the .ssh folder in the user profile, the authorized_keys file | Applies only to that account |
| Administrator | a separate shared administrators_authorized_keys file | Permissions on the file itself are checked |
For an administrator the server ignores the personal .ssh folder and only looks at the shared file — placing a key in the usual spot for such a user does nothing.
Permissions on the key file
Windows refuses a key-based login if the permissions on the key file are too broad — this protects against anyone on the machine being able to read the key.
icacls "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "SYSTEM:F" /grant "Administrators:F"The command removes inherited permissions and leaves access only to the system and administrators; without this step the service simply refuses to read the file, even if the key inside it is correct.
Security: what to turn off and restrict
The built-in server behaves like any other SSH server and follows the same security rules — for more on configuring sshd see the article SSH hardening: securing sshd_config.
- Turn off password login and keep only key-based login
- Do not expose port 22 externally without a real need, using a VPN or a tunnel instead
- Limit the list of users who are allowed to log in over SSH
Frequently asked questions
Is third-party software needed for an SSH server on Windows?
No, in current versions of Windows the SSH server is part of the system as an optional component and is enabled through settings or a PowerShell command. Third-party software is only needed in rare cases, for example specific server features that the built-in version does not provide.
Why does key-based login not work?
Most often the reason is the file path: for a regular user the key is looked up in the personal .ssh folder, while for an administrator it is only looked up in the shared administrators_authorized_keys file. The second common reason is permissions on the key file that are too broad, which makes the service refuse to read it.
How do you enable an SSH server on Windows 11?
Through system settings, the OpenSSH Server component is added, then the sshd service is started and set to start automatically. After that all that remains is opening port 22 in the Windows firewall — without this step an incoming connection never reaches the service.
Can SSH be exposed externally?
Technically yes, but an externally exposed port 22 quickly attracts password-guessing attempts from the internet. It is safer to restrict access through a VPN or a tunnel, turn off password login, and keep only key-based login — then an open port stops being a problem.
Conclusion
The built-in SSH server in Windows is enabled in a few minutes and needs no third-party software, but key-based login tends to break on small details — the wrong file path and permissions that are too broad. Those details and the security rules are covered in the sections above.