Confirm a working provider console or another management route. Choose the accounts, authentication method and source addresses that should be permitted. SSH access follows the Windows account's granted permissions, so do not make every operator a local administrator.

1. Open an elevated PowerShell session and inspect the available component with Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Server*'.
2. If the server component is absent, install the supported feature with Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0. Review the result and any required restart. A restricted update source may require your administrator's approved Features on Demand procedure.
3. Start the intended service with Start-Service sshd. If persistent SSH access is required, use Set-Service -Name sshd -StartupType Automatic.
4. Inspect the OpenSSH-Server-In-TCP Windows Firewall rule. Installation can create an inbound allowance for TCP port 22, so restrict the source scope to the intended management network.
5. Check the provider firewall and route separately. Test from the approved management source and verify the server's SSH host-key fingerprint through a trusted channel.

The server normally reads %ProgramData%\ssh\sshd_config. Preserve a copy before editing it and use Windows-supported user and group rules. On Server 2025, review its documented OpenSSH Users group controls as part of the effective policy; do not assume every earlier release has the same interface.

For public-key authentication, install the user's public key in the applicable authorised-keys file and protect its permissions. The default location differs for administrators: they normally use %ProgramData%\ssh\administrators_authorized_keys, whose access must be restricted as Microsoft documents. Keep private keys on the authorised client, not in the server's authorised-keys file.

After a configuration change, validate it with the installed OpenSSH tools, restart the service at an appropriate time and open a fresh test connection. Keep the recovery route available. If moving to key-only access, prove the intended key login before disabling the previous authentication method.

Check the resulting username, permissions and access to the required path. Review the OpenSSH event or configured file logs if authentication fails. A successful connection should not expose unrelated customer directories.

On the Windows Server, use elevated PowerShell after installing OpenSSH through the supported Windows feature workflow. This reads the sshd service state and TCP listener. Replace port 22 if the reviewed configuration specifies another port.

Get-Service -Name sshd
Get-NetTCPConnection -State Listen -LocalPort 22 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Read the result: A running service and visible listener establish two local prerequisites. They do not prove the intended user is authorised, the correct public key is installed or the external firewall permits access. If no listener appears, inspect the service log and installed configuration before changing network policy.

Verify the host fingerprint from a trusted source before the first remote login. Follow Windows OpenSSH's documented key-file locations and permissions, including administrator-account behaviour. Do not apply Linux file-ownership commands or copy a private key into an authorised-key file on Windows.

• Creating a narrowly scoped Windows Firewall rule
• Securing RDP access to a self-managed Windows Server
• Investigating a Windows service failure with Event Viewer
• Applying Windows Server updates with a maintenance plan

• Microsoft: get started with OpenSSH Server for Windows
• Microsoft: OpenSSH server configuration for Windows
• Microsoft: configure Windows Firewall rules

• Microsoft: OpenSSH on Windows Server