OpenSSH Server on Windows: install error 0x800f0950, winget fallback, and DefaultShell deciding how commands parse

Observed August to October 2026 on two Windows 10 Pro PCs that were set up for key-based SSH administration. Addresses and account names are omitted. OpenSSH versions were not recorded.

Install failure 0x800f0950

On the first PC, installing the server as a Feature on Demand:

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

failed with error 0x800f0950. The session attributed this to Windows Update being blocked on that machine; that attribution was not tested (no check of the update service or policy is recorded). The workaround that worked was installing the package through winget:

winget install Microsoft.OpenSSH.Preview

after which sshd ran with StartupType Automatic and a firewall rule for port 22 was in place. On the second PC the Feature on Demand install worked, and a one-shot elevated setup script covered the same steps: install, Set-Service sshd -StartupType Automatic, Start-Service sshd, firewall rule, authorise a key, set the default shell, Restart-Service sshd. That script told the user to fall back to the winget package if the first step produced 0x800f0950.

Where the key goes

The setup script wrote the public key to both C:\ProgramData\ssh\administrators_authorized_keys and the user's .ssh\authorized_keys, to cover whether the account is an administrator or not. Both files held the key on both PCs. The commonly cited requirement that administrators_authorized_keys have a locked-down ACL was raised in two sessions as the likely reason for a rejected key, but neither session recorded a confirmed result, so it is not stated here as an observed cause.

Firewall rule and network profile

The firewall rule created by the setup script was limited to the Private and Domain profiles (-Profile Private,Domain). The script's notes say a network that Windows classifies as Public must first be switched with Set-NetConnectionProfile -NetworkCategory Private. On the second PC the profile was changed from Public to Private, but the record says that port 22 was reachable either way, so the profile condition was not shown to matter there; that PC may have had other rules in effect. A third-party firewall in front of Windows Firewall was listed as another possible cause and was not encountered.

DefaultShell decides how a remote command is parsed

The server runs each remote command in the shell named by the registry value HKLM:\SOFTWARE\OpenSSH\DefaultShell. The two PCs differed:

• Windows PowerShell 5.1 (set with New-ItemProperty -Path HKLM:\SOFTWARE\OpenSSH -Name DefaultShell -Value C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -PropertyType String -Force, then Restart-Service sshd). A command such as ssh host 'Get-Service sshd' runs directly. && is not valid in PowerShell 5.1, and running an executable whose path contains spaces needs the call operator, for example & "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" list vms. Without the &, the error was Unexpected token.
• cmd.exe (no value set). PowerShell cmdlets have to be wrapped as powershell -NoProfile -Command "...", with the quoting layers that implies. For anything non-trivial, copying a .ps1 file over SFTP and running it by path avoided the quoting problems.

Checking the registry value first tells which syntax a scripted remote call needs.

Other observations

• On the first PC, the event log showed The OpenSSH SSH Server service terminated unexpectedly 10 times in 6 hours on one day, each followed by an automatic restart. Long-running remote commands died when that happened, so the note recommends short scripts and reconnecting. The cause of the service exits was not found.
• A failed ping said nothing about SSH on those PCs: ICMP echo was blocked by default and TCP 22 could be open at the same time.