TL;DR

On Windows Server 2025 the OpenSSH server is installed but not running. In an elevated PowerShell session:

Set-Service -Name sshd -StartupType Automatic
Start-Service -Name sshd
Get-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' |
    Format-Table Name, Enabled, Profile

The stock rule covers the Private profile only. Before connecting, add the profile the server’s network is on; the firewall step below shows how to tell. On a domain-joined server:

Set-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -Profile Domain, Private

On a cloud VM or a workgroup server, whose network is usually Public:

Set-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -Profile Public, Private

Run one, not both: -Profile replaces the rule’s list rather than adding to it.

Then connect from a client:

$ ssh Administrator@server-address

If Set-Service reports that the service does not exist, the capability was removed from your image; the first step below puts it back.

The visible change from Server 2022 is that the install step is usually gone: Server 2025 images carry the OpenSSH.Server capability by default. Server Manager gained a Remote SSH Access toggle on the Local Server page that enables the service. The commands below do the same thing from PowerShell, where they can be scripted, and they check each assumption rather than relying on the image being stock.

Confirm the server capability is present

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*' |
    Format-Table Name, State

On a stock image OpenSSH.Server reads Installed. If it reads NotPresent — a hardened or minimised image may have dropped it — add it the same way as on Server 2022:

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

Start sshd and make it start at boot

The service is registered but stopped. Set the start type before starting it, so a reboot cannot leave the server unreachable:

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

The first start writes the host keys and sshd_config to C:\ProgramData\ssh\.

Confirm the firewall rule

Get-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -ErrorAction SilentlyContinue |
    Format-Table Name, Enabled, Direction, Action, Profile

The rule is normally present with Enabled set to True. If it is present but disabled, enable it; if it is absent, create it:

Enable-NetFirewallRule -Name 'OpenSSH-Server-In-TCP'

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

Run whichever of the two applies, not both. A rule created this way covers every profile.

The stock rule covers the Private profile only, so check which profile the server’s network is on:

Get-NetConnectionProfile | Format-Table InterfaceAlias, NetworkCategory

A domain-joined server usually reads DomainAuthenticated, and a cloud VM or a workgroup server usually reads Public. The stock rule admits neither. For DomainAuthenticated:

Set-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -Profile Domain, Private

For Public:

Set-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -Profile Public, Private

Run one, not both: -Profile replaces the rule’s list rather than adding to it, so the second command would undo the first. A server with more than one network adapter can report more than one category; then name them all in one command, such as -Profile Domain, Public, Private.

Public applies the rule on any network the server joins, so on a public address let the network firewall in front of the server decide who reaches port 22.

Connect from a client

$ ssh Administrator@server-address

Accept the host key and enter the account’s Windows password. You arrive in cmd.exe; that is the default shell for Windows OpenSSH. To land in PowerShell instead:

New-ItemProperty -Path 'HKLM:\SOFTWARE\OpenSSH' -Name DefaultShell `
    -PropertyType String -Force `
    -Value 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe'

Expected result

Get-Service sshd reports Running, something is listening on port 22:

Get-NetTCPConnection -LocalPort 22 -State Listen

and a password login from a client succeeds for an administrator. Nobody else can sign in yet, and the next section is why.

Choose who can sign in

On Server 2025, the generated C:\ProgramData\ssh\sshd_config already limits SSH to two local groups:

AllowGroups administrators "openssh users"

This is the change from Server 2022, where the generated file has no such line and every account that can sign in to the server can sign in over SSH. On Server 2025, an account that isn’t an administrator gets in only once it’s a member of OpenSSH Users:

Add-LocalGroupMember -Group 'OpenSSH Users' -Member 'deploy'

There is no root account, so PermitRootLogin does nothing. To keep administrators off SSH entirely, deny their group, which leaves OpenSSH Users as the only way in:

DenyGroups administrators

AllowUsers narrows access further rather than widening it. An account has to pass AllowUsers and AllowGroups both, so a name listed in AllowUsers that isn’t in either group is still refused.

And once key-based login works for the accounts that need it, turn passwords off:

PasswordAuthentication no

Put each new line above the Match Group administrators block at the end of the file. A line added after it belongs to that block: it applies only to administrators, or, for a directive the block doesn’t allow, stops sshd from starting.

Restart the service after any change:

Restart-Service -Name sshd

Where an administrator’s public key has to go is the Windows-specific part; the related article scripts it.

Common failures

Administrator gets Permission denied (publickey)

Permission denied (publickey)

Windows OpenSSH doesn’t read ~\.ssh\authorized_keys for members of the Administrators group. The key belongs in C:\ProgramData\ssh\administrators_authorized_keys, with inheritance removed and only Administrators and SYSTEM granted access.

sshd stopped while the toggle says on

Refresh Server Manager. If they still disagree, the service failed to start, and the usual cause is a broken edit to sshd_config. Event Viewer won’t say so: a broken file leaves the OpenSSH Admin and Operational channels empty, and the System log records only that the service terminated unexpectedly. Check the file without starting anything:

sshd -t

It prints the line number and what is wrong with it, and nothing when the file is valid.

Only administrators can sign in

Even after adding an account to OpenSSH Users, on a non-English installation the group can carry a translated name, such as OpenSSH-Benutzer in German, while sshd_config still names openssh users. Find the local name, put it in the AllowGroups line in lower case, quoted if it contains a space, and restart sshd:

Get-LocalGroup | Where-Object Name -like '*SSH*'

Connection times out with the service running

The rule exists but is disabled, or doesn’t cover the network profile the server is on. The firewall drops the packets, so the client waits and times out rather than being refused:

Get-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' | Format-Table Name, Enabled, Profile

Enabled should read True, and Profile must include the profile the server is on; the firewall step earlier covers both.

TL;DR

For any account in the local Administrators group, the public key goes in one shared file, and that file must be accessible only by Administrators and SYSTEM. In an elevated PowerShell session on the server, with your public key in $publicKey:

$authorizedKeys = "$env:ProgramData\ssh\administrators_authorized_keys"

Add-Content -Path $authorizedKeys -Value $publicKey -Encoding ascii
icacls.exe $authorizedKeys /inheritance:r /grant 'Administrators:F' /grant 'SYSTEM:F'

Then from the client:

$ ssh -i ~/.ssh/id_ed25519 Administrator@server-address

No password prompt means it worked. A non-administrator account uses ~\.ssh\authorized_keys as on any other OpenSSH server and needs none of this.

The OpenSSH port for Windows makes one deliberate departure from the sshd_config defaults you know. Its stock configuration ends with:

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

So for an administrator, the per-user authorized_keys is never consulted, and ssh-copy-id — which doesn’t exist on Windows anyway — would put the key in a file sshd never reads. The key goes in the shared file, and sshd ignores that file without saying why if an ordinary user can write to it.

Generate a key pair on the client

If you do not already have one:

$ ssh-keygen -t ed25519

Take the defaults. Key formats, ssh-keygen and the rest of the client side are unmodified OpenSSH, so a key you already use elsewhere works here too. The public half is ~/.ssh/id_ed25519.pub, one line beginning ssh-ed25519. That line is what the server needs; the private half never leaves the client.

Get the public key onto the server

Pick whichever route reaches the server. In a password-authenticated SSH session, or an RDP session, paste the one line into a variable on the server:

# Paste the whole public key line between the quotes.
$publicKey = 'ssh-ed25519 AAAA... you@laptop'

Or, from the client, copy the line in one step, which avoids pasting a long line through a terminal:

$ scp ~/.ssh/id_ed25519.pub Administrator@server-address:id_ed25519.pub

and on the server:

$publicKey = Get-Content "$env:USERPROFILE\id_ed25519.pub"

Write the key and fix the permissions

$sshDir        = "$env:ProgramData\ssh"
$authorizedKeys = "$sshDir\administrators_authorized_keys"

if (-not (Test-Path $sshDir)) {
    New-Item -ItemType Directory -Path $sshDir | Out-Null
}

Add-Content -Path $authorizedKeys -Value $publicKey -Encoding ascii

icacls.exe $authorizedKeys /inheritance:r /grant 'Administrators:F' /grant 'SYSTEM:F'

Add-Content creates the file if it is missing and appends if it is not, so the same lines add a second administrator’s key later. -Encoding ascii is not decoration: see the first common failure.

/inheritance:r strips the inherited entries. The two /grant entries put back the only two principals Microsoft’s documentation allows on this file. sshd’s own permission check is looser, and rejects the file only when another account has write access. Confirm:

icacls.exe $authorizedKeys

The output should list exactly BUILTIN\Administrators:(F) and NT AUTHORITY\SYSTEM:(F).

Test from the client

sshd reads the keys file at every sign-in, so no restart is needed. From the client:

$ ssh -i ~/.ssh/id_ed25519 Administrator@server-address

Expected result

You’re signed in without a password prompt. Once that holds for every account that needs access, turn password authentication off in C:\ProgramData\ssh\sshd_config:

PasswordAuthentication no

and restart the service, which reads sshd_config only when it starts. Leave password authentication on until the key login is confirmed, or you’ll lock yourself out of the server you’re configuring.

Common failures

Login still asks for a password

The key is in the file and the ACL is right, but the file isn’t plain ASCII. In Windows PowerShell 5.1, > and Out-File write UTF-16 with a byte-order mark, and sshd can’t parse a key that starts with one. Delete the file and write it again with Add-Content -Encoding ascii or Set-Content -Encoding ascii. Inspect a suspect file: a good file starts 73 73 68 (ssh), a bad one starts FF FE.

Format-Hex -Path $authorizedKeys | Select-Object -First 1

ACL shows extra principals after icacls

Inheritance wasn’t removed before granting. Run the /inheritance:r form earlier, which does both steps in one call, and check again.

icacls reports no mapping for an account name

No mapping between account names and security IDs was done.

The Windows installation isn’t in English, and the Administrators group has a localized name. Grant it by SID instead, with /grant '*S-1-5-32-544:F' in place of /grant 'Administrators:F'.

Works for one account and not another

The second account isn’t an administrator. For it, the key belongs in that user’s own C:\Users\<name>\.ssh\authorized_keys, and the shared file is irrelevant.

Client output doesn’t explain the refusal

Ask the server. When the ACL is the cause, Server 2025 logs it under Applications and Services Logs > OpenSSH > Operational, naming the file and the account that can write to it. Server 2022’s OpenSSH 8.1 logs only “Authentication refused” there; the line naming the file goes to the OpenSSH > Debug channel, which is off by default. An encoding fault logs nothing there, so check the bytes as described earlier. ssh -v on the client shows only that the key was offered and declined.

TL;DR

In an elevated PowerShell session on the server:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Set-Service -Name sshd -StartupType Automatic
Start-Service -Name sshd
Get-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' |
    Format-Table Name, Enabled, Direction, Action

Then from any machine with an SSH client:

$ ssh Administrator@server-address

Sign in with the Windows account’s password. Key-based login for an administrator has one Windows-specific rule, covered under common failures.

Windows Server 2022 ships the OpenSSH server as an optional capability, not as an installed service. Adding it takes one command; the rest of the work is making sure it starts on boot and that the firewall lets the connection in. Everything below runs in a PowerShell session opened as Administrator.

Install the OpenSSH server capability

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

The four tildes are part of the name. The command downloads the capability from Windows Update, so the server needs a route to it, or a configured alternate source for features on demand.

Confirm it landed:

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*' |
    Format-Table Name, State

OpenSSH.Server should show Installed. If OpenSSH.Client shows NotPresent and you want it on the server too, add it the same way with OpenSSH.Client~~~~0.0.1.0.

The same install is available without a shell under Settings > Apps > Apps & features > Optional features > Add a feature, searching for “OpenSSH Server”. It is the same capability, so the commands that follow apply either way.

Start sshd and make it start at boot

The install registers the sshd service but doesn’t start it or set it to start at boot. Set the start type first, so a reboot before you finish does not leave the server unreachable:

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

Status should read Running. The first start generates the host keys under C:\ProgramData\ssh\, which is also where sshd_config lives from now on.

Confirm the firewall rule

Installing the capability with Add-WindowsCapability normally creates and enables an inbound rule named OpenSSH-Server-In-TCP for port 22. Check rather than assume:

Get-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -ErrorAction SilentlyContinue |
    Format-Table Name, Enabled, Direction, Action

If the rule is missing, create it:

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

Run it only when the check finds nothing. Rule names are unique, so New-NetFirewallRule fails if OpenSSH-Server-In-TCP already exists.

Connect from a client

From another machine, using its own OpenSSH client (macOS, Linux, and Windows 10 version 1809 or later all have one):

$ ssh Administrator@server-address

Accept the host key on first connection and enter the account’s Windows password. Windows OpenSSH is a port of the same OpenSSH that ships on Linux and macOS, so the client and its keys behave the way you already expect. Authentication is the difference: sshd hands it to Windows. The default sshd_config has no AllowUsers or AllowGroups line, so any local or domain account Windows accepts can sign in. SSH keeps no user list of its own until you add one.

Expected result

You land in a cmd.exe prompt on the server. That’s the default shell for Windows OpenSSH, not a sign that something went wrong. To get PowerShell instead, set the default shell once on the server:

New-ItemProperty -Path 'HKLM:\SOFTWARE\OpenSSH' -Name DefaultShell `
    -PropertyType String -Force `
    -Value 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe'

Point it at pwsh.exe instead if PowerShell 7 is installed and that’s what you want to arrive in.

Common failures

Administrator gets Permission denied (publickey)

Permission denied (publickey)

The key is in ~\.ssh\authorized_keys, and for any account in the local Administrators group Windows OpenSSH ignores that file entirely. The key has to be in C:\ProgramData\ssh\administrators_authorized_keys, and sshd refuses that file unless only SYSTEM and Administrators have access to it. The client is never told why; the reason goes to the server’s OpenSSH event log. The procedure, scripted, is in the article on key authentication for an administrator. Non-administrator accounts use ~\.ssh\authorized_keys as usual.

Connection refused or timing out

A stopped service usually gives a refusal. A missing firewall rule usually gives a timeout, because the firewall drops the packets. Get-Service sshd and the firewall check earlier tell you which. If both look right, confirm something is listening:

Get-NetTCPConnection -LocalPort 22 -State Listen

Add-WindowsCapability fails with 0x800f0954

The server can’t reach Windows Update, or can’t find the source. The usual cause is WSUS: Server 2022 can’t install OpenSSH from WSUS at all. One fix is the Group Policy setting Specify settings for optional component installation and component repair, under Computer Configuration > Administrative Templates

System. Enable it and select Download repair content and optional features directly from Windows Update instead of Windows Server Update Services. The other is to mount the Server 2022 Features on Demand ISO and pass its drive to -Source. The same fix applies to 0x800F0950 and the 0x8024xxxx connection errors.

ssh hangs after the password

Every command works, but the session never opens. Check Event Viewer under Applications and Services Logs > OpenSSH > Operational, which records each sign-in and refusal. Don’t wait for the Admin channel: it stays empty even when sshd can’t start. For that case, sshd -t names the broken line in sshd_config, and prints nothing when the file is valid.