Windows 11 includes OpenSSH as an optional feature: the client (the ssh command) to connect to another machine, and the server (the sshd service) to accept incoming connections. When the connection fails, the cause is almost always one of four things: a missing component, a stopped service, a closed firewall, or a public key placed in the wrong file.
Problem
- ssh is not recognized in PowerShell or Command Prompt.
- "Connection refused", "Connection reset" or "Connection timed out" when connecting to a Windows PC.
- Password sign-in works, but key-based sign-in is refused ("Permission denied (publickey)") or the password is asked again.
- The key is refused only for an administrator account.
- ssh-add reports an error about the SSH agent.
Observe before acting
Start by running the connection in verbose mode from the client PC (replace the user and server name):
ssh -v utilisateur@nom-du-serveur
The -v option shows each step of the connection (documented in the OpenSSH manual). The last lines show where it stops. Then check that port 22 answers:
Test-NetConnection -ComputerName nom-du-serveur -Port 22
| What you see | Most likely cause | Step |
|---|---|---|
| ssh is not recognized | OpenSSH client not installed | Step 1 |
| Refused, reset or timed out; TcpTestSucceeded : False | Server missing, sshd stopped or firewall closed | Steps 2 and 3 |
| Port open, but key refused for a standard account | Public key missing or in the wrong place | Step 4 |
| Key refused for an administrator account | administrators_authorized_keys file missing or wrong permissions | Step 5 |
| ssh-add fails | ssh-agent service disabled | Step 6 |
Step 1: install the OpenSSH client and server
When to use it: ssh is not recognized on the client, or sshd cannot be found on the PC you want to connect to.
Microsoft lists these prerequisites: Windows 10 version 1809 or later, PowerShell 5.1 or later, and an account that is a member of the Administrators group.
Suggested solution
- Open PowerShell as administrator and check the state of both components:
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'
- State : NotPresent means the component is not installed. Install what is missing: the client on the PC that connects, the server on the PC that receives the connection.
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
- Without PowerShell: Settings > System > Optional features, then Add a feature and search for OpenSSH.
- Close and reopen the terminal.
Expected result: ssh -V shows a version, and the check command shows State : Installed.
Rollback: Remove-WindowsCapability -Online -Name OpenSSH.Client0.0.1.0 (or OpenSSH.Server0.0.1.0), or Remove in Optional features.
Step 2: start the sshd service
When to use it: the server is installed, but the connection is refused.
Microsoft states that the sshd service has to be started manually after installation: it does not start on its own.
Suggested solution
On the server PC, in an administrator PowerShell:
Get-Service sshd
Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'
The third line, optional but recommended by Microsoft, makes the service start every time Windows starts. The server's host keys are stored in C:\ProgramData\ssh.
Expected result: Get-Service sshd shows Running.
Rollback: Stop-Service sshd then Set-Service -Name sshd -StartupType 'Manual'.
Step 3: open port 22 in Windows Firewall
When to use it: sshd is running, but Test-NetConnection fails from another PC.
Installing the server normally creates the OpenSSH-Server-In-TCP firewall rule. According to Microsoft, if this rule is not enabled and port 22 is not open, connections are refused or reset.
Suggested solution
On the server PC, in an administrator PowerShell, this Microsoft script creates the rule only if it does not exist:
if (!(Get-NetFirewallRule -Name "OpenSSH-Server-In-TCP" -ErrorAction SilentlyContinue)) {
Write-Output "Firewall Rule 'OpenSSH-Server-In-TCP' does not exist, creating it..."
New-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22
} else {
Write-Output "Firewall rule 'OpenSSH-Server-In-TCP' has been created and exists."
}
If the rule already exists, check that it is enabled: Get-NetFirewallRule -Name OpenSSH-Server-In-TCP must show Enabled : True. A third-party firewall or a router between the two machines can also block the port: in that case, open it in that tool.
Expected result: Test-NetConnection from the client shows TcpTestSucceeded : True.
Rollback: Remove-NetFirewallRule -Name 'OpenSSH-Server-In-TCP'.
Do not expose port 22 directly to the Internet through a router port forward without weighing the risk.
Step 4: place the public key for a standard account
When to use it: password sign-in works, but the key is refused, for an account that is not an administrator on the server.
Suggested solution
- On the client, create a key pair if you do not have one (with no option, OpenSSH creates an Ed25519 key; Microsoft's example uses ECDSA):
ssh-keygen -t ecdsa
- The public key is the file ending in .pub (for example C:\Users\nom\.ssh\id_ecdsa.pub). Never copy the private key (the file without an extension).
- On the server, add the content of the .pub file as one line in the C:\Users\nom\.ssh\authorized_keys file of the account used to connect.
- Reconnect with ssh -v and check that the key is offered and then accepted.
Expected result: the connection opens without asking for the account password (a passphrase is asked if you set one on the key).
Rollback: delete the line you added in authorized_keys.
Microsoft notes that Microsoft Entra ID accounts do not support key-based authentication with OpenSSH on Windows.
Step 5: key refused for an administrator account
When to use it: the same key works for a standard account, but not for an account that is a member of the server's Administrators group.
This is the most common trap. For administrators, OpenSSH on Windows does not read the authorized_keys file in the profile: Microsoft states that you must use the C:\ProgramData\ssh\administrators_authorized_keys file instead, accessible only to Administrators and SYSTEM.
Suggested solution
- On the server, in an administrator PowerShell, add the public key (paste the full content of your .pub file between the single quotes):
Add-Content -Force -Path $env:ProgramData\ssh\administrators_authorized_keys -Value 'contenu-de-votre-cle-publique'
- Restrict the file permissions. On a non-English Windows (in French, the group is called "Administrateurs"), Microsoft advises using the group's identifier S-1-5-32-544, preceded by an asterisk, instead of its name:
icacls.exe "$env:ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "*S-1-5-32-544:F" /grant "SYSTEM:F"
- To check the group identifier on your PC: Get-LocalGroup | Select-Object Name, SID.
Expected result: icacls.exe "$env:ProgramData\ssh\administrators_authorized_keys" only lists the Administrators group and SYSTEM, and key-based sign-in works for the administrator account.
Rollback: delete the line you added, or the file if it did not exist before.
Step 6: get ssh-agent working
When to use it: ssh-add fails, or you want to avoid typing the key passphrase again and again.
Microsoft states that the ssh-agent service is disabled by default.
Suggested solution
In an administrator PowerShell:
Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
Then, in a normal PowerShell:
ssh-add $env:USERPROFILE\.ssh\id_ecdsa
Expected result: ssh-add -l lists your key.
Rollback: Stop-Service ssh-agent then Set-Service -Name ssh-agent -StartupType Disabled.
Final check
- ☐ ssh -V answers on the client.
- ☐ Get-Service sshd shows Running on the server.
- ☐ Test-NetConnection to port 22 succeeds.
- ☐ On the first connection, the host fingerprint is shown: compare it if possible before answering yes.
- ☐ The key is in authorized_keys (standard account) or administrators_authorized_keys (administrator).
Sources
- Microsoft Learn: Get started with OpenSSH for Windows
- Microsoft Learn: Key-based authentication in OpenSSH for Windows
- Microsoft Learn: Test-NetConnection
- OpenSSH manual: ssh(1)
Still having the problem?
Reply to this topic with your Windows version (winver), whether you are on the client or server side, the account type (standard, administrator, Microsoft Entra ID), the result of Test-NetConnection and the last lines of ssh -v. Replace user names, machine names and IP addresses with dummy values, and never post your private key.