Windows 11 intègre OpenSSH comme fonctionnalité facultative : le client (commande ssh) pour vous connecter à une autre machine, et le serveur (service sshd) pour accepter des connexions entrantes. Quand la connexion échoue, la cause se trouve presque toujours dans l'un de ces quatre points : composant absent, service arrêté, pare-feu fermé, ou clé publique placée au mauvais endroit.
Problème
- ssh n'est pas reconnu dans PowerShell ou l'Invite de commandes.
- « Connection refused », « Connection reset » ou « Connection timed out » en vous connectant à un PC Windows.
- Le mot de passe fonctionne, mais la connexion par clé est refusée (« Permission denied (publickey) ») ou redemande le mot de passe.
- La clé est refusée uniquement pour un compte administrateur.
- ssh-add affiche une erreur sur l'agent SSH.
Observer avant d'agir
Commencez par lancer la connexion en mode détaillé depuis le PC client (remplacez l'utilisateur et le nom du serveur) :
ssh -v utilisateur@nom-du-serveur
L'option -v affiche chaque étape de la connexion (documentée dans le manuel d'OpenSSH). Les dernières lignes indiquent où ça bloque. Vérifiez ensuite que le port 22 répond :
Test-NetConnection -ComputerName nom-du-serveur -Port 22
| Ce que vous constatez | Cause la plus probable | Étape |
|---|---|---|
| ssh n'est pas reconnu | Client OpenSSH non installé | Étape 1 |
| Refusée, réinitialisée ou expirée ; TcpTestSucceeded : False | Serveur absent, sshd arrêté ou pare-feu fermé | Étapes 2 et 3 |
| Port ouvert, mais clé refusée pour un compte standard | Clé publique absente ou au mauvais endroit | Étape 4 |
| Clé refusée pour un compte administrateur | Fichier administrators_authorized_keys absent ou mauvaises autorisations | Étape 5 |
| ssh-add échoue | Service ssh-agent désactivé | Étape 6 |
Étape 1 : installer le client et le serveur OpenSSH
Quand l'utiliser : ssh n'est pas reconnu sur le client, ou sshd est introuvable sur le PC auquel vous voulez vous connecter.
Microsoft indique comme prérequis Windows 10 version 1809 ou plus récent, PowerShell 5.1 ou plus récent, et un compte membre du groupe Administrateurs.
Solution proposée
- Ouvrez PowerShell en tant qu'administrateur et vérifiez l'état des deux composants :
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'
- State : NotPresent signifie que le composant n'est pas installé. Installez ce qui manque : le client sur le PC qui se connecte, le serveur sur le PC qui reçoit la connexion.
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
- Sans PowerShell : Paramètres > Système > Fonctionnalités facultatives, puis Ajouter une fonctionnalité et cherchez OpenSSH.
- Fermez et rouvrez le terminal.
Résultat attendu : ssh -V affiche une version, et la commande de vérification indique State : Installed.
Retour arrière : Remove-WindowsCapability -Online -Name OpenSSH.Client0.0.1.0 (ou OpenSSH.Server0.0.1.0), ou Supprimer dans les Fonctionnalités facultatives.
Étape 2 : démarrer le service sshd
Quand l'utiliser : le serveur est installé, mais la connexion est refusée.
Microsoft précise que le service sshd doit être démarré manuellement après l'installation : il ne démarre pas tout seul.
Solution proposée
Sur le PC serveur, dans PowerShell administrateur :
Get-Service sshd
Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'
La troisième ligne, facultative mais recommandée par Microsoft, fait démarrer le service à chaque démarrage de Windows. Les clés d'hôte du serveur sont stockées dans C:\ProgramData\ssh.
Résultat attendu : Get-Service sshd affiche Running.
Retour arrière : Stop-Service sshd puis Set-Service -Name sshd -StartupType 'Manual'.
Étape 3 : ouvrir le port 22 dans le pare-feu Windows
Quand l'utiliser : sshd tourne, mais Test-NetConnection échoue depuis un autre PC.
L'installation du serveur crée normalement la règle de pare-feu OpenSSH-Server-In-TCP. Selon Microsoft, si cette règle n'est pas active et le port 22 n'est pas ouvert, les connexions sont refusées ou réinitialisées.
Solution proposée
Sur le PC serveur, dans PowerShell administrateur, ce script de Microsoft crée la règle seulement si elle n'existe pas :
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."
}
Si la règle existe déjà, vérifiez qu'elle est active : Get-NetFirewallRule -Name OpenSSH-Server-In-TCP doit afficher Enabled : True. Un pare-feu tiers ou un routeur entre les deux machines peut aussi bloquer le port : il faut alors l'ouvrir dans cet outil.
Résultat attendu : Test-NetConnection depuis le client affiche TcpTestSucceeded : True.
Retour arrière : Remove-NetFirewallRule -Name 'OpenSSH-Server-In-TCP'.
N'exposez pas le port 22 directement sur Internet par une redirection de port du routeur sans en mesurer le risque.
Étape 4 : placer la clé publique pour un compte standard
Quand l'utiliser : la connexion par mot de passe fonctionne, mais la clé est refusée, pour un compte qui n'est pas administrateur du serveur.
Solution proposée
- Sur le client, créez une paire de clés si vous n'en avez pas (sans option, OpenSSH crée une clé Ed25519 ; l'exemple de Microsoft utilise ECDSA) :
ssh-keygen -t ecdsa
- La clé publique est le fichier qui finit par .pub (par exemple C:\Users\nom\.ssh\id_ecdsa.pub). Ne copiez jamais la clé privée (le fichier sans extension).
- Sur le serveur, ajoutez le contenu du fichier .pub sur une ligne du fichier C:\Users\nom\.ssh\authorized_keys du compte utilisé pour se connecter.
- Reconnectez-vous avec ssh -v et vérifiez que la clé est proposée puis acceptée.
Résultat attendu : la connexion s'ouvre sans demander le mot de passe du compte (une phrase secrète est demandée si vous en avez mis une sur la clé).
Retour arrière : supprimez la ligne ajoutée dans authorized_keys.
Microsoft signale que les comptes Microsoft Entra ID ne prennent pas en charge l'authentification par clé avec OpenSSH sur Windows.
Étape 5 : clé refusée pour un compte administrateur
Quand l'utiliser : la même clé fonctionne pour un compte standard, mais pas pour un compte membre du groupe Administrateurs du serveur.
C'est le piège le plus fréquent. Pour les administrateurs, OpenSSH sur Windows ne lit pas le fichier authorized_keys du profil : Microsoft indique qu'il faut utiliser à la place le fichier C:\ProgramData\ssh\administrators_authorized_keys, accessible uniquement aux Administrateurs et à SYSTEM.
Solution proposée
- Sur le serveur, dans PowerShell administrateur, ajoutez la clé publique (collez le contenu complet de votre fichier .pub entre les guillemets simples) :
Add-Content -Force -Path $env:ProgramData\ssh\administrators_authorized_keys -Value 'contenu-de-votre-cle-publique'
- Limitez les autorisations du fichier. Sur un Windows en français, le groupe s'appelle « Administrateurs » : Microsoft conseille alors d'utiliser son identifiant S-1-5-32-544, précédé d'un astérisque, au lieu du nom :
icacls.exe "$env:ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "*S-1-5-32-544:F" /grant "SYSTEM:F"
- Pour vérifier l'identifiant du groupe sur votre PC : Get-LocalGroup | Select-Object Name, SID.
Résultat attendu : icacls.exe "$env:ProgramData\ssh\administrators_authorized_keys" n'affiche plus que le groupe Administrateurs et SYSTEM, et la connexion par clé fonctionne pour le compte administrateur.
Retour arrière : supprimez la ligne ajoutée, ou le fichier s'il n'existait pas avant.
Étape 6 : faire fonctionner ssh-agent
Quand l'utiliser : ssh-add échoue, ou vous voulez éviter de retaper la phrase secrète de la clé.
Microsoft précise que le service ssh-agent est désactivé par défaut.
Solution proposée
Dans PowerShell administrateur :
Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
Puis, dans un PowerShell normal :
ssh-add $env:USERPROFILE\.ssh\id_ecdsa
Résultat attendu : ssh-add -l liste votre clé.
Retour arrière : Stop-Service ssh-agent puis Set-Service -Name ssh-agent -StartupType Disabled.
Vérification finale
- ☐ ssh -V répond sur le client.
- ☐ Get-Service sshd affiche Running sur le serveur.
- ☐ Test-NetConnection vers le port 22 réussit.
- ☐ À la première connexion, l'empreinte de l'hôte est demandée : comparez-la si possible avant de répondre yes.
- ☐ La clé est dans authorized_keys (compte standard) ou administrators_authorized_keys (administrateur).
Sources
- Microsoft Learn : Prise en main d'OpenSSH pour Windows (version anglaise : Get started with OpenSSH for Windows)
- Microsoft Learn : Gestion des clés pour OpenSSH sous Windows (version anglaise : Key-based authentication in OpenSSH for Windows)
- Microsoft Learn : Test-NetConnection
- Manuel OpenSSH : ssh(1)
Le problème continue ?
Répondez à ce sujet en indiquant votre version de Windows (winver), si vous êtes côté client ou serveur, le type de compte (standard, administrateur, Microsoft Entra ID), le résultat de Test-NetConnection et les dernières lignes de ssh -v. Remplacez les noms d'utilisateur, noms de machines et adresses IP par des valeurs fictives, et ne publiez jamais votre clé privée.