Install and Scope OpenSSH Server on Windows

Windows OpenSSH Server provides SSH-based remote administration alongside Windows’ other management options. This tutorial installs the optional capability, starts the sshd service, narrows its inbound firewall rule to an approved management subnet, and verifies access from an authorized client.

Run the setup in an elevated PowerShell session on a supported Windows client or Server release. Use a dedicated administrative account, prefer key-based authentication according to your organization’s policy, and avoid exposing SSH to the public Internet without a reviewed access design.

---

Step 1: Check and Install the OpenSSH Server Capability

01

Confirm the Capability State Before Installing

Installation

Check whether OpenSSH Server is already installed. If it is absent, install the server capability; do not install the client capability unless this computer also needs to initiate SSH sessions.

Get-WindowsCapability -Online |
  Where-Object Name -like 'OpenSSH.Server*' |
  Select-Object Name, State

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

❯ View Expected Console Output

Name  : OpenSSH.Server~~~~0.0.1.0
State : Installed

---

Step 2: Start sshd and Inspect Its Firewall Rule

02

Set the Service to Start Automatically

Service Setup

Start the SSH service and configure automatic startup if this host is intended to accept SSH after reboot. Windows setup may create a default inbound firewall rule; inspect it before enabling remote access.

Set-Service -Name sshd -StartupType Automatic
Start-Service sshd
Get-Service sshd
Get-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -ErrorAction SilentlyContinue |
  Select-Object Name, Enabled, Profile, Direction, Action

❯ View Expected Console Output

Status Name DisplayName
------ ---- -----------
Running sshd OpenSSH SSH Server

---

Step 3: Restrict Inbound SSH to the Management Range

03

Replace the Broad Rule Scope with an Approved Subnet

Firewall Scope

If the default rule exists, restrict its remote addresses to your trusted management subnet. The example uses 10.20.30.0/24; substitute the actual range and choose the profile that applies to this host’s management network. A workgroup server commonly uses Private rather than Domain. If there is no rule, create one with a scoped address filter instead of allowing any source.

$ManagementSubnet = '10.20.30.0/24'
# Use the profile that applies to the management interface.
# For a domain-connected interface use Domain; a workgroup may use Private.
$FirewallProfile = 'Domain'
$FirewallProfile

$SshRule = Get-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -ErrorAction SilentlyContinue

if ($SshRule) {
  $SshRule | Set-NetFirewallRule -Enabled True -Profile $FirewallProfile
  $SshRule | Get-NetFirewallAddressFilter |
    Set-NetFirewallAddressFilter -RemoteAddress $ManagementSubnet
} else {
  New-NetFirewallRule -Name 'OpenSSH-Server-In-TCP-Scoped' `
    -DisplayName 'OpenSSH Server - Management Subnet Only' `
    -Enabled True -Direction Inbound -Protocol TCP -LocalPort 22 `
    -RemoteAddress $ManagementSubnet -Profile $FirewallProfile -Action Allow
}

Get-NetFirewallRule -Name 'OpenSSH-Server-In-TCP*' |
  Get-NetFirewallAddressFilter

❯ View Expected Console Output

RemoteAddress : 10.20.30.0/24

---

Step 4: Test SSH from an Authorized Client

04

Verify the Listener and User Login

Verification

Confirm the service is listening on TCP port 22, then connect from a client in the permitted subnet. Check the server’s OpenSSH configuration under C:\ProgramData\ssh\sshd_config if authentication or the default shell does not behave as expected.

Get-NetTCPConnection -State Listen -LocalPort 22

ssh [email protected]

❯ View Expected Console Output

The SSH client prompts for the configured authentication method and opens a Windows shell after successful authentication.

Figure 1: The Windows SSH service is running, its firewall rule is scoped to the management subnet, and port 22 is listening.

Keep a Recovery Path

Changing the default OpenSSH firewall rule can affect existing remote access. Test from the intended management network before closing the current session, and retain another approved administrative path during rollout.

See Microsoft’s OpenSSH first-use guide and server configuration guide for supported settings.