OpenSSH Troubleshooting on Windows: Proven Fix for Common sshd Errors

OpenSSH Troubleshooting on Windows Server and Windows 11

OpenSSH on Windows platforms like Windows Server and Windows 11 sometimes encounters issues related to configuration, permissions, updates, and service failures. These problems can disrupt secure remote shell connectivity. Below are real time scenario users face with OpenSSH on Windows environments and how to troubleshoot them to solve the error effectively.

This article aims to be clear and helpful for managing OpenSSH. It addresses common real-time Openssh issues in Windows Server and Windows 11 environments.

1. OpenSSH Service Fails to Start (Error 1067)

Scenario:

The OpenSSH SSH Server service fails to start, showing “error 1067” message or stops unexpectedly on Windows Server or Windows 11 .

Cause:

This is often caused by bad user permission in ssh folder or incorrect file permissions on SSH host key files or configuration files, or by misconfigured service account permissions.

Troubleshooting Steps:

• Verify OpenSSH installation with PowerShell command:

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*

• If missing, reinstall using PowerShell

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

• Verify user permission in C:\ProgramData\ssh directory, logs file, sshd_config file – only administrator and system account should have full permission .
• Remove extra users and domain account or they should have only read permission.
• Verify permissions via PowerShell or GUI.

Get-Acl C:\Programdata\ssh\logs | Select-Object -Property accesstostring | fl *

• Fix file permissions on C:\ProgramData\ssh directory:

icacls "C:\ProgramData\ssh" /grant "NT SERVICE\SSHD:(OI)(CI)F" /T

• Configure service to run as LocalService:

sc.exe config sshd obj="NT AUTHORITY\LocalService" type= own

• Regenerate SSH host keys:

cd C:\Windows\System32\OpenSSH
ssh-keygen -A

• Check logs in Event Viewer under Windows Logs → Application or at C:\ProgramData\ssh\logs\sshd.log.
• Start the sshd service via services.msc or PowerShell Command

net start sshd

• Use PowerShell scripts provided with OpenSSH MSI installer like FixHostFilePermissions.ps1 and FixUserFilePermissions.ps1 to fix permissions automatically.

• If problem persists, uninstall and reinstall OpenSSH Server feature.

2. Permission Denied and Host Key File Access Errors

Scenario:

Host key files like ssh_host_rsa_key fail to load with errors like “Permission denied” or error 5/13 when the SSH service tries to read key files.

Cause:

Windows security settings or external users/groups added to the permissions can cause access issues to the C:\ProgramData\sshdirectory and host key files.

Troubleshooting Steps:

• Ensure only built-in users like Administrators and SYSTEM have access to host key files.
• Remove any extra users or domain accounts from permissions.
• Run the scripts FixHostFilePermissions.ps1 to reset correct permissions.
• Restart sshd service after fixing permissions.
• Check the ownership and access control using:

icacls C:\ProgramData\ssh\ssh_host_rsa_key

• Remove unwanted permissions or grant full access only to system accounts.

3. SSH Connection Issues: Public Key Authentication Fails

Scenario:

Users report that public key authentication does not work on the Windows OpenSSH server, even though the keys and authorized_keys files are present.

Cause:

Problems with the structure and permissions of the .ssh folder or authorized_keys file in user home directories may be causing this issue. Alternatively, there could be a misconfiguration in sshd_config.

Troubleshooting Steps:

• Ensure the ssh directory in the user’s home directory exists and has the right permissions, so only the user can access it.
• Make sure the authorized_keys file has the right ownership and permissions, which is usually 600.
• Check the sshd config file (C:\ProgramData\ssh\sshd_config) for the correct setting of AuthorizedKeysFile.

AuthorizedKeysFile .ssh/authorized_keys

• Restart the sshd service after making changes.
• Check that the user’s home directory is correctly set and accessible.
• Test the login using a verbose SSH client:

ssh -vvv user@windows-server

Check logs on the server side for errors.

4. OpenSSH Service Not Running After Windows Updates

Scenario:

After Windows security updates or feature updates, OpenSSH service stops working or fails to start.

Cause:

Windows updates sometimes change permissions on SSH directories or introduce bugs that cause the sshd service to fail.

Troubleshooting Steps:

• Check for recent Windows updates related to OpenSSH issues (e.g., KB5044380, KB5044285).
• Reset ACL permissions on C:\ProgramData\ssh and logs folder, removing any unintended user accounts added by updates.
• Temporarily fix permissions by running:

icacls c:\programdata\ssh\logs /remove:g domain\user

• Check Microsoft’s Windows Insider releases or support for patches that fix OpenSSH-related bugs.
• Consider uninstalling and reinstalling the OpenSSH server feature after updates.

5. SSH Connection Refused or Timeout

Scenario:

When you try to SSH to a Windows server, you see a “Connection refused” error or it times out.

Cause:

This could happen if the firewall is blocking port 22, the sshd service is not running, or if there are network security group (NSG) rules on the cloud VMs.

Troubleshooting Steps:

Verify sshd service is running:

Get-Service sshd

• Check that port 22 is open in Windows Firewall and network devices.
• For cloud VMs, verify NSG rules allow inbound TCP traffic on port 22.

Restart service:

Restart-Service sshd

• Check sshd logs for connection attempts.
• Test SSH from localhost to confirm sshd is listening locally:

ssh localhost

Use tools like netstat to confirm port 22 listening:

netstat -an | find "22"

6. Error 1053 while starting the Openssh Server services.

Error 1053 (“The service did not respond to the start or control request in a timely fashion”) when starting the OpenSSH service on Windows Server means the service took too long to start. This often relates to problems such as corrupt files, missing dependencies, incorrect permissions, or a problematic network stack.

Proven Fixes for Error 1053

1. Increase Service Timeout in Registry
Sometimes OpenSSH or its dependencies take longer than Windows allows. To extend the timeout:

• Run regedit.
• Go to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
• Right-click “Control,” select New, then DWORD (32-bit) Value.
• Name it: ServicesPipeTimeout
• Set Value data to: 180000 (decimal) – which equals 180 seconds.
• Restart the server and try again.

2. Update Windows to Latest Build

• Error 1053 can occur because of outdated system files. Check for and install any pending updates.

3. Reset Permissions and Ownership

• Ensure C:\ProgramData\ssh and all files inside are owned only by SYSTEM or Administrators.
• Right-click the folder, select Properties, then Security, and go to Advanced to set the owner to SYSTEM, removing all other users.

4. Check Service Log On Account

• Open Services (services.msc) and find your OpenSSH service.
• Right-click, select Properties, and then the Log On tab.
• Make sure “Local System account” is selected.
• If it isn’t, set it and click “Apply.”

5. Repair Installation
If none of the above work:

• Uninstall OpenSSH using PowerShell: Remove-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0.
• Reinstall it with PowerShell: Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0.
• Ensure that all dependencies, including Visual C++ Redistributables, .NET Framework, and system libraries, are present and up-to-date.

Additional Checks

• Check Event Viewer’s Application and Services Logs for the OpenSSH log. Look for any error messages or hints about missing DLLs or system files.
• Make sure that dependent services, such as “Windows Event Log” and “Remote Procedure Call (RPC),” are running.

Review Windows Event Viewer for sshd errors

Here’s how to review and interpret Event Viewer errors for OpenSSH (sshd) on Windows Server and what common log messages mean.

How to Find OpenSSH Logs in Event Viewer

1. Open Event Viewer (eventvwr.msc).
2. Navigate to Applications and Services Logs → OpenSSH.
3. Admin log: Shows errors and warnings.
4. Operational log: Shows Informational messages and session activity.

Common Error Messages and Causes

Error 1297: Privilege Required Not Held

• This occurs if the service ‘Log On As’ is set to a user account that does not have the necessary system privileges.
• Solution: Change ‘Log On As’ back to Local System in the service properties.

‘Connection reset by peer’ in the Admin log usually indicates authentication issues or network/firewall problems.

Increasing Log Detail

For deeper debugging, set in C:\ProgramData\ssh\sshd_config:

SyslogFacility LOCAL0
LogLevel DEBUG3

Restart sshd , now detailed logs will appear in C:\ProgramData\ssh\logs\sshd.log.

By using these steps, you will able to fix Openssh common issues effectively on windows.

Explore more details insides in Microsoft Official Community Q&A .