OpenSSH adds encrypted remote shell access, secure file transfer, and command-line administration capabilities to Windows Server 2016. Although newer Windows Server releases include OpenSSH as an optional feature, Windows Server 2016 typically requires installing the Microsoft-supported OpenSSH package manually, then configuring the related services and firewall rules.
Setting it up correctly involves more than copying files into place. You need to confirm prerequisites, install the client or server components as needed, register and start the SSH services, open TCP port 22 in Windows Firewall, and verify that authentication works from a remote system.
As an Amazon Associate I earn from qualifying purchases.
A careful installation also helps avoid common issues such as missing services, blocked firewall traffic, incorrect permissions, or failed logins. With the right checks in place, Windows Server 2016 can provide reliable and secure SSH access for administration and automation tasks.
Prerequisites for Installing OpenSSH on Windows Server 2016
Before installing OpenSSH on Windows Server 2016, confirm the server is fully patched and that you have administrative access. Windows Server 2016 does not include the OpenSSH Server and Client features in the same built-in, easy-to-enable form found in newer Windows Server releases, so installation usually relies on the Microsoft-supported OpenSSH for Windows package from the Win32-OpenSSH project. Use an elevated PowerShell session for all installation and service configuration steps.
#1 Best Overall
Start by checking the operating system version and update level. Open PowerShell as Administrator and run winver or use Get-ComputerInfo to confirm you are working on Windows Server 2016. Then install pending Windows Updates and reboot if required. This reduces issues with service registration, firewall rules, cryptographic components, and PowerShell execution behavior during setup.
Access and permission requirements
- Local administrator rights: Required to copy files into protected directories, install services, create firewall rules, and start or stop the SSH service.
- Elevated PowerShell: Run PowerShell with Run as administrator before executing installation commands.
- Console, RDP, or remote management access: Keep an existing management method available until SSH access has been tested successfully.
- Change control approval: If the server is in production, schedule the installation during an approved maintenance window.
You should also decide where OpenSSH will be installed. A common location is C:\Program Files\OpenSSH, although some older installation examples use C:\OpenSSH. Use a directory with restrictive permissions and avoid placing the binaries in user profile folders or temporary locations. The OpenSSH service account and host key files should be protected from modification by non-administrative users.
Network and firewall prerequisites
By default, SSH listens on TCP port 22. Confirm that this port is not already used by another application and that your network allows traffic from the systems that need to connect. On a domain-joined server, also consider Group Policy firewall settings, endpoint protection rules, and upstream firewalls between client machines and the server.
| Requirement | What to verify |
|---|---|
| TCP port | Port 22 is available, or an alternate SSH port has been selected. |
| Firewall path | Windows Firewall and network firewalls allow inbound SSH from trusted sources. |
| Name resolution | DNS name or IP address of the server is reachable from client systems. |
| Time synchronization | Server time is accurate, especially when using domain accounts or key-based authentication. |
Finally, prepare an account for connection testing. For initial validation, use a known local or domain account that is allowed to sign in to the server. If you plan to use SSH keys, generate or identify the client public key in advance and confirm where authorized keys will be stored. Password-based testing can be useful at first, but for long-term access, key-based authentication with limited administrative membership is a safer configuration.
Installing the OpenSSH Client
On Windows Server 2016, the OpenSSH Client is not typically available as a simple Optional Feature in the same way it is on newer Windows Server releases. The most reliable approach is to install the Microsoft Win32-OpenSSH package manually, then add its binaries to the system path so commands such as ssh, scp, and sftp can be run from PowerShell or Command Prompt. Perform the installation from an elevated PowerShell session to avoid permission issues when copying files into system locations.
Download the latest stable Win32-OpenSSH release from Microsoft’s official GitHub repository. For most Windows Server 2016 installations, use the 64-bit package named similar to OpenSSH-Win64.zip. After downloading it, extract the archive to a permanent directory such as C:\Program Files\OpenSSH. Avoid extracting it to a user profile, Downloads folder, or temporary location because the client tools and, later, server components should remain in a stable path.
- Open PowerShell as Administrator.
- Create the installation directory if it does not already exist, for example C:\Program Files\OpenSSH.
- Extract the contents of the OpenSSH ZIP file into that directory.
- Confirm that files such as ssh.exe, scp.exe, sftp.exe, and ssh-keygen.exe are present.
- Add C:\Program Files\OpenSSH to the system Path environment variable.
After updating the system path, close and reopen PowerShell so the new environment variable is loaded. You can then verify the client installation by checking the SSH version. Run ssh -V from a new administrative or standard PowerShell window. A successful result displays the installed OpenSSH version and the linked OpenSSL or LibreSSL library version. If PowerShell returns that ssh is not recognized, the path was not applied correctly, the shell was not reopened, or the files were extracted into a different folder than expected.
For a first connection test, use the client to connect to a known SSH server on the network or internet. The basic syntax is ssh username@hostname, where username is the remote account and hostname is a DNS name or IP address. On first connection, the client asks whether to trust the remote host key. Confirm only if the fingerprint matches the expected server identity. Windows stores accepted host keys in the user profile under .ssh\known_hosts, which helps detect future host key changes.
Client installation checks
- ssh -V confirms that the SSH client binary runs correctly.
- where ssh shows which executable Windows is using when multiple SSH clients are installed.
- ssh username@server verifies outbound SSH connectivity and authentication.
- scp test.txt username@server:/path/ can be used later to confirm secure copy support.
If the connection attempt times out, the client may be working correctly but the remote server, firewall, routing, or port configuration may be blocking access. If authentication fails, verify the username, password, domain format, or SSH key being used. For key-based authentication from the client side, private keys are commonly stored in the user’s %USERPROFILE%\.ssh directory, and overly broad permissions on key files can cause OpenSSH to reject them. Once the client is installed and verified, the server component can be installed and configured on Windows Server 2016 to accept inbound SSH sessions.
Installing the OpenSSH Server
On Windows Server 2016, the OpenSSH Server component is usually installed from the Microsoft Win32-OpenSSH package rather than through the newer Optional Features interface found in later Windows Server releases. The server component provides sshd.exe, which listens for inbound SSH connections and allows administrators or approved users to connect securely to the server over TCP port 22.
Before installing, sign in with a local administrator account or open PowerShell as Administrator. Download the latest stable Win32-OpenSSH release from Microsoft’s GitHub repository, choosing the OpenSSH-Win64.zip package for a typical 64-bit Windows Server 2016 installation. After downloading, extract the archive to a permanent folder such as C:\Program Files\OpenSSH. Avoid installing it from a temporary downloads folder, because the Windows service will depend on files in this location.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Rank #2
- Windows Server 2016 Security, Certificates, and Remote Access Cookbook: Recipe based guide for security, networking and PKI in Windows Server 2016
- Packt Publishing
- ABIS_BOOK
Install the OpenSSH server binaries
Once the files are extracted, open an elevated PowerShell window and move into the OpenSSH installation directory. If the archive was extracted to C:\Program Files\OpenSSH, use the following command:
cd "C:\Program Files\OpenSSH"
Run the installation script included with the package:
powershell.exe -ExecutionPolicy Bypass -File install-sshd.ps1
This script registers the OpenSSH Server service in Windows as sshd. It may also register the authentication agent service, ssh-agent, depending on the package version. If PowerShell blocks the script because of execution policy restrictions, the -ExecutionPolicy Bypass parameter applies only to that command session and does not permanently lower the system-wide policy.
Recommended Free Tools
Verify the service was created
After the script finishes, confirm that the SSH server service exists. In PowerShell, run:
Get-Service sshd
A successful installation should return a service named sshd. At this stage, the service may be stopped and may not yet be configured to start automatically. That is expected immediately after installation. You can also check the Services console by running services.msc and looking for OpenSSH SSH Server.
- Service name:
sshd - Display name: OpenSSH SSH Server
- Default executable:
C:\Program Files\OpenSSH\sshd.exe - Main configuration file:
C:\ProgramData\ssh\sshd_config
The first time the service starts, OpenSSH creates host keys under C:\ProgramData\ssh if they do not already exist. These host keys identify the server to SSH clients. If this directory is missing before the first start, that does not necessarily mean installation failed; it is commonly created during service initialization.
Confirm OpenSSH files and configuration paths
Check that the installation directory contains files such as sshd.exe, ssh.exe, scp.exe, sftp.exe, and install-sshd.ps1. The server configuration is not normally edited in the extracted program folder. Instead, after initial service startup, use C:\ProgramData\ssh\sshd_config for server-side settings such as authentication methods, allowed users, default shell behavior, and subsystem configuration.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsIf the install-sshd.ps1 script reports an access denied error, confirm that PowerShell was launched with administrative privileges. If Windows reports that the file is blocked because it came from the internet, right-click the ZIP file before extracting it, open Properties, select Unblock if available, and extract the package again. Once the sshd service is registered successfully, the next step is to configure its startup behavior and start the SSH server service.
Configuring and Starting the SSH Server Service
After the OpenSSH Server files are installed on Windows Server 2016, the next step is to configure the sshd service so it can accept incoming SSH sessions. On many Windows Server 2016 installations, especially when OpenSSH was installed from the Win32-OpenSSH package, the service must be installed or registered before it can be started. Open an elevated PowerShell window and confirm that the OpenSSH folder is present, commonly at C:\Program Files\OpenSSH or C:\OpenSSH, depending on how the package was extracted.
If the service is not already registered, change to the OpenSSH installation directory and run the included installation script. For example, from an elevated PowerShell session, run the install script from the OpenSSH folder. This creates the Windows services used by OpenSSH, including sshd for incoming SSH connections and, in some builds, ssh-agent for managing private keys. After registration, verify that the service exists by checking it in the Services console or with PowerShell.
Rank #3
- sshd: the OpenSSH SSH Server service that listens for incoming connections.
- ssh-agent: an optional service used to store and provide private keys for authentication.
- sshd_config: the main server configuration file, usually located in the OpenSSH installation directory or under C:\ProgramData\ssh.
Before starting the service, review the SSH server configuration file. At minimum, confirm the server is listening on the expected port, usually 22, and that authentication settings match your environment. For initial testing, password authentication may be enabled if your security policy allows it. In production environments, key-based authentication is often preferred. If the configuration file includes directives such as Port, PasswordAuthentication, PubkeyAuthentication, or AllowUsers, make sure they are set intentionally and do not conflict with your access plan.
Starting and enabling the sshd service
Once the configuration is in place, start the SSH server service from an elevated PowerShell session. Then set the service startup type to automatic so SSH remains available after a reboot. This is especially useful for remote administration, maintenance windows, and recovery tasks where console access may not be convenient. After starting the service, check that its status is Running. If it immediately stops, inspect the OpenSSH logs and Windows Event Viewer for configuration errors, missing host keys, or permission problems.
- Start the sshd service after installation and configuration.
- Set sshd to start automatically with Windows.
- Confirm the service status shows Running.
- Restart the service after editing sshd_config so changes take effect.
During first-time setup, OpenSSH may need host keys for the server identity. Some installers generate these automatically, while others require a separate key generation step. If the service fails to start and the logs mention missing host key files, generate the required server keys using the OpenSSH utilities included with the package, then start the service again. The generated host keys should be stored securely, and file permissions should allow the SSH service account to read them while preventing unnecessary access by standard users.
To verify that the server is actually listening, check for a listener on TCP port 22 after the service starts. You can also confirm the process in Task Manager or by reviewing active services. At this stage, the SSH service should be running locally, but remote connections may still fail until Windows Firewall allows inbound SSH traffic. That firewall rule is handled in the next step, after the service itself is confirmed to be installed, configured, and stable.
Allowing SSH Through Windows Firewall
After the OpenSSH Server service is installed and running, Windows Firewall must allow inbound TCP traffic on port 22. Without this rule, the SSH service can listen locally, but remote computers will fail to connect. On Windows Server 2016, you can create the firewall rule with PowerShell or through the Windows Defender Firewall management console.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
First, confirm that sshd is listening on the expected port. Run the following command in an elevated PowerShell window:
netstat -ano | findstr :22
If the service is listening, you should see an entry similar to 0.0.0.0:22 or [::]:22 with the state set to LISTENING. If nothing appears, return to the SSH service configuration and verify that the sshd service is started before adjusting firewall settings.
Create the Firewall Rule with PowerShell
The fastest method is to add an inbound firewall rule for TCP port 22. Open PowerShell as Administrator and run:
New-NetFirewallRule `
-Name "OpenSSH-Server-In-TCP" `
-DisplayName "OpenSSH Server (sshd)" `
-Enabled True `
-Direction Inbound `
-Protocol TCP `
-Action Allow `
-LocalPort 22
This creates an enabled inbound allow rule named OpenSSH-Server-In-TCP. To verify that the rule exists, run:
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteGet-NetFirewallRule -Name "OpenSSH-Server-In-TCP"
You can also confirm the port filter attached to the rule:
Get-NetFirewallRule -Name "OpenSSH-Server-In-TCP" | Get-NetFirewallPortFilter
Create the Rule in Windows Firewall GUI
If you prefer the graphical interface, open Windows Defender Firewall with Advanced Security. Select Inbound Rules, then choose New Rule. Select Port, choose TCP, and enter 22 as the specific local port. Select Allow the connection, choose the required profiles, then name the rule OpenSSH Server (sshd).
- Domain: Use this when the server is joined to an Active Directory domain and accessed from trusted domain networks.
- Private: Use this for trusted internal networks.
- Public: Avoid enabling SSH on public profiles unless remote administration from that network is explicitly required.
For better security, limit inbound SSH access to known management IP addresses instead of allowing every remote host. In the firewall rule properties, open the Scope tab and add trusted IP addresses or subnets under Remote IP address. With PowerShell, you can create a restricted rule like this:
New-NetFirewallRule `
-Name "OpenSSH-Restricted-In-TCP" `
-DisplayName "OpenSSH Server Restricted" `
-Enabled True `
-Direction Inbound `
-Protocol TCP `
-Action Allow `
-LocalPort 22 `
-RemoteAddress 192.168.1.0/24
If SSH still does not connect after the rule is added, check that the server network profile matches the enabled firewall profile. Run:
Free tools Windows power users keep installed
One-click scans. No signup required.
Get-NetConnectionProfile
Then inspect the firewall rule profiles:
Get-NetFirewallRule -Name "OpenSSH-Server-In-TCP" | Select-Object DisplayName, Enabled, Profile
Finally, test port reachability from another machine on the network:
Test-NetConnection -ComputerName SERVERNAME -Port 22
A successful result shows TcpTestSucceeded : True. If the test fails, verify the server IP address, routing, network profile, firewall rule scope, and whether another network firewall between the client and server is blocking TCP port 22.
Testing SSH Connections
After the OpenSSH Server service is running and TCP port 22 is allowed through Windows Firewall, test the connection from another machine on the same network. Use a Windows, Linux, or macOS client that has an SSH client installed. On Windows Server 2016, the target account can be a local user, such as ServerName\UserName, or a domain account, such as DOMAIN\UserName, depending on how the server is joined and how authentication is configured.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →From the client computer, open PowerShell, Command Prompt, Terminal, or another SSH-capable shell and run a connection test using the server IP address or DNS name. For example, connect to a local administrator or standard user account with ssh username@server-ip-address. If the account is domain-based, use a format such as ssh domain\\username@server-ip-address. The first time you connect, the client should display the server host key fingerprint and ask whether to trust it. Confirm only if you are connecting to the expected server.
Basic connection checks
- Confirm name resolution: If using a hostname, verify it resolves to the correct IP address with ping server-name or nslookup server-name.
- Test the port: From a Windows client, run Test-NetConnection server-ip-address -Port 22. A successful result should show TcpTestSucceeded : True.
- Check authentication: Enter the correct password for the Windows account when prompted. If login succeeds, you should receive a command shell on the Windows Server 2016 system.
- Verify the remote session: Run hostname or whoami after login to confirm you are connected to the intended server and account.
If password authentication works, test common administrative commands carefully from the SSH session. For example, ipconfig can confirm network details, while powershell can start a PowerShell session if the default shell opens as Command Prompt. If your environment requires PowerShell as the default SSH shell, confirm that the related registry configuration has been applied and then open a new SSH session to validate the change.
For key-based authentication, place the user’s public key in the appropriate authorized_keys file and confirm file permissions are not overly broad. For standard users, this is typically under the user profile in .ssh\authorized_keys. For members of the local Administrators group, OpenSSH on Windows commonly uses %ProgramData%\ssh\administrators_authorized_keys. After adding the key, connect with ssh -i path-to-private-key username@server-ip-address and verify that the server accepts the key without prompting for the account password.
Expected results
| Test | Successful result |
|---|---|
| Port check | TCP port 22 responds from the client network |
| Password login | User receives a Windows command shell after authentication |
| Key login | Private key authenticates the user successfully |
| Identity check | whoami shows the expected local or domain account |
If the connection fails, the exact error message before making changes. Connection timed out usually points to routing, firewall, or port exposure problems. Connection refused often means the SSH service is not listening on the target port. Permission denied indicates an authentication, username format, password, key, or account access issue. These results will guide the next troubleshooting steps without unnecessary configuration changes.
Basic Troubleshooting and Security Checks
If the OpenSSH client or server does not behave as expected on Windows Server 2016, start with simple verification checks before changing configuration files. Confirm that the binaries are available, the SSH server service exists, the firewall rule is active, and the server is listening on TCP port 22. Running these checks in an elevated PowerShell session helps avoid permission-related confusion.
Best Value
Verify the OpenSSH installation and service state
Check that the OpenSSH commands are available from PowerShell. The client should respond to ssh -V, while the server files are commonly installed under C:\Program Files\OpenSSH. If Windows cannot find the command, confirm that the installation path is included in the system Path environment variable or run the executable directly from its installation folder.
- Run Get-Service sshd to confirm that the OpenSSH SSH Server service exists.
- Run Get-Service ssh-agent if you plan to use key-based authentication with the local agent.
- Use Start-Service sshd to start the server if it is stopped.
- Use Set-Service -Name sshd -StartupType Automatic so SSH starts after a reboot.
If the service fails to start, inspect the configuration file at C:\ProgramData\ssh\sshd_config. A malformed directive, incorrect path, or unsupported option can prevent startup. After making changes, restart the service with Restart-Service sshd. You can also check the Windows Event Viewer under Applications and Services Logs for OpenSSH-related entries, or review logs written to C:\ProgramData\ssh\logs if file logging is enabled.
Confirm port listening and firewall access
Use netstat -ano | findstr :22 or Get-NetTCPConnection -LocalPort 22 to confirm that the server is listening on the expected port. If nothing is listening, the SSH service is not running correctly or the configuration uses a different port. If the service is listening locally but remote clients cannot connect, review the Windows Firewall rule that allows inbound TCP traffic on port 22.
- Confirm that the firewall rule is enabled for the correct network profile, such as Domain or Private.
- Make sure no upstream firewall, router ACL, or cloud security group is blocking TCP 22.
- If you changed the SSH port, update both sshd_config and the inbound firewall rule.
- Test from another host with ssh username@server-ip rather than only testing from the server itself.
Check authentication and permissions
For password authentication, verify that the Windows account is enabled, not locked out, and allowed to log on to the server. Domain accounts may require the format DOMAIN\username or [email protected], depending on the environment. If login fails immediately, confirm the account password and review local or domain security policies that might restrict logon access.
For key-based authentication, file permissions are a common source of failure. User public keys are usually placed in %USERPROFILE%\.ssh\authorized_keys. Administrator accounts may instead use C:\ProgramData\ssh\administrators_authorized_keys, depending on the default configuration. The private key stays on the client, while the public key is copied to the server. Restrict access so that only the intended user, Administrators, and SYSTEM have permissions where appropriate; overly broad permissions can cause OpenSSH to reject the key.
Review basic security settings
After SSH works, reduce exposure by reviewing the active configuration. Disable accounts that do not need remote shell access, prefer key-based authentication for administrative use, and keep Windows Server patched. If the server is reachable from untrusted networks, consider limiting inbound SSH access to known management IP addresses instead of allowing connections from anywhere.
- Use strong passwords if password authentication remains enabled.
- Consider setting PasswordAuthentication no after key-based access is confirmed.
- Restrict administrative SSH access to trusted users and groups.
- Monitor failed logon attempts in Windows security logs.
- Back up sshd_config before making future changes.
Frequently Asked Questions
Does Windows Server 2016 include OpenSSH by default?
Windows Server 2016 does not include OpenSSH as a built-in optional feature in the same way newer Windows Server versions do. You typically need to install Microsoft’s OpenSSH release manually, often from the official GitHub package. After installation, confirm that the OpenSSH binaries are in the expected folder and that the SSH services are registered correctly.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How can I check if the OpenSSH client is installed correctly?
Open a Command Prompt or PowerShell window and run ssh -V. If the client is installed and available in the system path, Windows will display the OpenSSH version. If the command is not recognized, check the installation directory and add it to the system PATH if needed.
What service needs to be running for SSH logins to work?
The server component depends on the sshd service. You can check it with Get-Service sshd in PowerShell or by opening the Services console. Set it to start automatically and start the service before testing remote SSH access.
Which firewall rule is required for OpenSSH Server on Windows Server 2016?
You need to allow inbound TCP traffic on port 22, unless you changed the SSH listening port in the server configuration. This can be done through Windows Defender Firewall with Advanced Security or with PowerShell. After creating the rule, test from another machine on the network using ssh username@server-ip.
What should I check if SSH connects but rejects my password?
First, confirm that you are using a valid Windows account and the correct username format, especially if the server is joined to a domain. Check the OpenSSH server configuration file for password authentication settings and restart the sshd service after changes. Also review the Windows Event Viewer and OpenSSH logs for authentication errors or permission-related messages.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesBottom Line
Installing OpenSSH on Windows Server 2016 gives you a secure, script-friendly way to manage the server remotely, but it works best when the prerequisites, services, firewall rules, and user permissions are verified step by step. After installation, confirm the SSH server service is running, port 22 is reachable, and both password or key-based authentication behave as expected.
Your next step is to test from a trusted client, review the SSH configuration for your security needs, and keep access limited to approved users and networks. If a connection fails, check the service status, Windows Firewall, OpenSSH logs, and account permissions before making broader changes.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
