SSH Windows 10 & compte Microsoft : pourquoi l’authentification échoue et les solutions sûres

Impossible d’ouvrir une session SSH sur un PC Windows 10 lié à un compte Microsoft ? Voici pourquoi cela échoue et comment mettre en place une connexion fiable, sûre et durable… sans perdre vos habitudes de connexion Windows.

Sommaire

Connexion SSH à un PC Windows 10 associé à un compte Microsoft

Pourquoi le mot de passe Microsoft est toujours refusé

Sur Windows 10, le serveur OpenSSH natif (sshd) s’appuie sur les mécanismes d’authentification du système, capables de valider :

des comptes locaux (SAM de la machine) ;
des comptes Active Directory classiques (ou Azure AD/Entra ID si l’ordinateur est correctement joint et que l’intégration SSH est active).

En revanche, les comptes Microsoft personnels (Outlook/Hotmail) utilisés pour la session Windows — typiquement affichés comme MicrosoftAccount\utilisateur@outlook.com — ne disposent pas d’un fournisseur d’authentification SSH pris en charge par le sshd natif. Résultat : l’authentification par mot de passe échoue systématiquement, même si le mot de passe est correct dans l’écran de connexion Windows.

À retenir : sur Windows 10, SSH authentifie les comptes locaux et AD, pas les comptes Microsoft « grand public ». C’est une limitation de conception, pas un bug de votre mot de passe.

Réponse et solutions

Étape	Détails
Constat	Le service OpenSSH natif de Windows 10 ne sait authentifier que : • comptes locaux ; • comptes Active Directory (ou Azure AD/Entra ID si la machine est jointe). Les comptes Microsoft personnels (`MicrosoftAccount\utilisateur@outlook.com`) n’ont pas de back‑end d’authentification dédié pour SSH : la connexion à mot de passe échoue donc de manière prévisible.
Contournement recommandé	1) Créer un compte local : Paramètres › Comptes › Famille et autres utilisateurs › Ajouter un utilisateur sans compte Microsoft. 2) Attribuer des droits Administrateur si nécessaire. 3) Activer OpenSSH‑Server : `Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 Start-Service sshd Set-Service sshd -StartupType Automatic New-NetFirewallRule -Name sshd -DisplayName "OpenSSH Server" -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22` 4) Connexion depuis un autre poste : `ssh compte_local@IP_du_PC`
Clé publique (optionnel mais recommandé)	Pour éviter la saisie du mot de passe et renforcer la sécurité, ajouter votre clé (`id_rsa.pub` ou `id_ed25519.pub`) dans `C:\Users\<compte_local>\.ssh\authorized_keys` puis désactiver l’authentification par mot de passe dans `sshd_config`.
Autres options	• RDP : l’authentification via compte Microsoft fonctionne nativement. • Azure AD/Entra ID & SSH : possible dans des scénarios entreprise et versions récentes (plutôt Windows 11/Server modernes) avec machine jointe et comptes pros/éducation, pas avec un compte Microsoft personnel. • Serveurs SSH tiers : certains produits implémentent leurs propres passerelles d’authentification et peuvent, sous conditions, déléguer l’identité. Cela reste une architecture spécifique à évaluer et maintenir.
Bonnes pratiques de sécurité	• Ne pas exposer le port 22 sur Internet sans filtrage IP ou VPN. • Si possible, désactiver l’authentification par mot de passe (`PasswordAuthentication no`) et imposer les clés publiques. • En entreprise, privilégier un compte AD/Azure AD avec politiques centralisées. • Éviter Windows 10 hors support : sécurité affaiblie depuis octobre 2025.

Tutoriel pas à pas pour une connexion SSH fiable

Créer un compte local dédié à SSH

Conserver votre compte Microsoft pour l’ouverture de session Windows et créer en parallèle un compte local uniquement pour SSH est souvent la solution la plus simple.

Méthode graphique : Paramètres › Comptes › Famille et autres utilisateurs › Ajouter un utilisateur sans compte Microsoft. Donnez un nom simple (ex. sshadmin). Facultatif : définissez‑le Administrateur si vous devez administrer la machine via SSH.

Méthode PowerShell :

# Exécuter PowerShell en Administrateur
$User = "sshadmin"
$Pass = Read-Host "Mot de passe du compte local $User" -AsSecureString
New-LocalUser -Name $User -Password $Pass -FullName "Compte SSH local" -Description "Accès SSH"
# Facultatif : ajout au groupe Administrateurs
Add-LocalGroupMember -Group "Administrateurs" -Member $User

Astuce identité : le compte Microsoft personnel apparaît dans la console comme MicrosoftAccount\mail@outlook.com. Ce préfixe n’est pas accepté par sshd natif. Un compte local, lui, sera vu comme NOMPC\sshadmin et fonctionnera.

Installer, démarrer et sécuriser OpenSSH‑Server

# Installer le serveur OpenSSH (si nécessaire)
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

# Démarrer et mettre en démarrage automatique

Start-Service sshd
Set-Service sshd -StartupType Automatic

# Ouvrir le port 22 en profil privé/domaine uniquement

New-NetFirewallRule -Name sshd `  -DisplayName "OpenSSH Server (sshd)"`
-Enabled True -Direction Inbound -Protocol TCP -Action Allow `
-LocalPort 22 -Profile Domain,Private

# Vérifier l'écoute

Get-NetTCPConnection -State Listen -LocalPort 22

Conseil : si votre box/routeur est exposé, préférez limiter l’accès à votre réseau (plage 192.168.1.0/24 par ex.) :

New-NetFirewallRule -Name "sshd-LAN" `
  -DisplayName "OpenSSH Server LAN only" -Enabled True `
  -Direction Inbound -Protocol TCP -Action Allow `
  -LocalPort 22 -RemoteAddress 192.168.1.0/24 -Profile Domain,Private

Configurer l’authentification par clé publique

La clé publique évite les mots de passe et durcit la sécurité.

1) Générer une clé sur le poste client

# Sous Linux/macOS
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519

# Sous Windows client (PowerShell)

ssh-keygen -t ed25519 -a 100 -f $env:USERPROFILE.ssh\id_ed25519

2) Créer le dossier .ssh sur le serveur et poser la clé

# Se connecter une première fois en mot de passe (réseau local)
ssh sshadmin@IP_du_PC

# Sur le serveur (ou en PSSession) :

$Home    = "C:\Users\sshadmin"
$SshDir  = Join-Path $Home ".ssh"
New-Item -ItemType Directory -Force -Path $SshDir | Out-Null

# Coller la clé publique dans authorized_keys (adapter le contenu)

$PubKey  = @"
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx client
"@
$Auth = Join-Path $SshDir "authorized_keys"
$PubKey | Out-File -FilePath $Auth -Encoding ascii -Force

# Durcir les permissions (équivalent de chmod 700/600)

icacls $SshDir /inheritance:r
icacls $SshDir /grant "sshadmin:(OI)(CI)F" "SYSTEM:(OI)(CI)F"
icacls $Auth   /inheritance:r
icacls $Auth   /grant "sshadmin:F" "SYSTEM:F"

3) Activer uniquement les clés dans sshd_config

Éditez C:\ProgramData\ssh\sshd_config (exécuteur Administrateur) :

# Emplacements par défaut
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
# Optionnel : port personnalisé
# Port 2222
# Restreindre à certains utilisateurs
# AllowUsers sshadmin

# Pour les administrateurs, Windows peut utiliser ce fichier partagé :

# AuthorizedKeysFile **PROGRAMDATA**/ssh/administrators_authorized_keys

Recharger le service :

Restart-Service sshd

4) Tester la connexion

ssh -i ~/.ssh/id_ed25519 sshadmin@IP_du_PC
# ou, si vous avez changé de port
ssh -i ~/.ssh/id_ed25519 -p 2222 sshadmin@IP_du_PC

Dépannage efficace

Journal OpenSSH : Observateur d’événements › Applications et services › OpenSSH › Operational. Analysez les erreurs Permission denied, no matching key, etc.
Test de configuration : "C:\Windows\System32\OpenSSH\sshd.exe" -T -f "C:\ProgramData\ssh\sshd_config"
Mode debug ponctuel (console Admin) : "C:\Windows\System32\OpenSSH\sshd.exe" -ddd -E C:\ProgramData\ssh\sshd_debug.log
Clés non lues : vérifier le format authorized_keys (une ligne par clé, pas d’extensions Win), encodage ASCII/UTF‑8, et permissions (pas d’héritage, droits sur l’utilisateur et SYSTEM uniquement).
Collision de port : si le port 22 est pris, définissez Port 2222 puis : Restart-Service sshd Test-NetConnection -ComputerName localhost -Port 2222

Et si je veux absolument utiliser mon compte Microsoft ?

Sur Windows 10, il n’existe pas de méthode native pour authentifier un compte Microsoft personnel via SSH. Voici les alternatives réalistes :

Rester en compte Microsoft pour Windows et créer un compte local dédié pour SSH (recommandé : simple, sûr, réversible).
Rejoindre un domaine AD/Azure AD avec un compte pro/éducation puis utiliser ce compte via SSH (environnement entreprise).
Solutions tierces (passerelles/RDP/SSO/serveurs SSH commerciaux) qui délèguent l’authentification. À évaluer selon vos contraintes de coût, de conformité et d’exploitation.

Note sécurité : Windows 10 Home/Pro est arrivé en fin de support en octobre 2025. Héberger un service SSH sur un système non supporté augmente la surface de risque. Si possible, migrez vers une version prise en charge.

Cas entreprise : utiliser un compte AD/Azure AD

Si la machine est jointe à un domaine Active Directory, sshd peut authentifier DOMAINE\utilisateur ou utilisateur@domaine.tld, en mot de passe ou (mieux) en clés publiques. Pour les environnements Azure AD/Entra ID modernes (Windows 11/Windows Server récents), il existe des options d’intégration SSH spécifiques qui exigent une jonction cloud correcte, des politiques d’accès conditionnel et des comptes professionnels/éducatifs. Ces scénarios ne s’appliquent pas aux comptes Microsoft personnels.

Alternative pratique : exécuter SSH dans WSL

Lorsque vous ne pouvez pas modifier les comptes Windows, une alternative consiste à exposer un serveur SSH à l’intérieur de WSL (Ubuntu/Debian, etc.). On se connecte alors au sous‑système Linux, pas au noyau Windows. Cela ne résout pas l’authentification Microsoft côté Windows, mais peut suffire pour du transfert de fichiers ou des tâches d’administration Linux.

# Dans WSL (ex. Ubuntu)
sudo apt update && sudo apt install openssh-server
sudo sed -i 's/^#Port.*/Port 2222/' /etc/ssh/sshd_config
sudo systemctl enable --now ssh

# Rediriger le port 2222 du Windows hôte (PowerShell admin côté Windows)

netsh interface portproxy add v4tov4 listenport=2222 listenaddress=0.0.0.0 connectport=2222 connectaddress=127.0.0.1

# Ajuster le firewall pour 2222 si besoin

Cette approche est utile pour isoler l’environnement, mais pensez à la sécurité réseau (VPN, filtrage IP).

FAQ

« Puis‑je écrire ssh "MicrosoftAccount\mail@outlook.com"@hôte ? »
Même en échappant le @ dans l’utilisateur, sshd n’a pas de fournisseur pour valider un compte Microsoft personnel : l’authentification échoue.

« Est‑ce que convertir mon compte Microsoft en compte local aidera ? »
Oui, un compte local est compatible SSH. Mais vous perdrez les avantages de la connexion Microsoft (synchronisation, Microsoft Store, etc.). Préférez créer un compte local séparé dédié à SSH.

« Comment restreindre l’accès SSH à un sous‑ensemble d’adresses IP ? »
Par le pare‑feu Windows : créez une règle Inbound avec -RemoteAddress ciblant votre sous‑réseau/VPN. Vous pouvez également placer le service derrière un VPN type WireGuard/OpenVPN.

« Comment limiter les commandes disponibles ? »
Dans sshd_config, utilisez ForceCommand, des Match User spécifiques, et des permissions NTFS minimales sur les répertoires ciblés. Pour le transfert de fichiers uniquement, configurez SFTP (Subsystem sftp sftp-server.exe) et limitez les ACL.

« Pourquoi ma clé publique n’est‑elle pas acceptée ? »
Vérifiez : emplacement (C:\Users\<compte>\.ssh\authorized_keys), format (une ligne par clé, pas de retours à la ligne intempestifs), et permissions NTFS (héritage désactivé, droits pour l’utilisateur et SYSTEM uniquement). Redémarrez sshd après modification.

Modèle commenté de configuration `sshd_config`

# Fichier : C:\ProgramData\ssh\sshd_config

# Port d'écoute (personnaliser si exposition derrière routeur/NAT)

Port 22

# Clés hôtes stockées par Windows OpenSSH

HostKey **PROGRAMDATA**/ssh/ssh_host_ed25519_key
HostKey **PROGRAMDATA**/ssh/ssh_host_rsa_key

# Durscissement de l'authentification

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

# Sur Windows, chemin par défaut pour les clés des administrateurs

# AuthorizedKeysFile **PROGRAMDATA**/ssh/administrators_authorized_keys

# Pour les comptes non admin, authorized_keys dans le profil utilisateur

# Bannières et logs

# Banner none

SyslogFacility AUTHPRIV
LogLevel VERBOSE

# Restriction par utilisateur/groupe (exemples)

# AllowUsers sshadmin

# Match Group Administrateurs

# AuthorizedKeysFile **PROGRAMDATA**/ssh/administrators_authorized_keys

# SFTP (transfert de fichiers)

Subsystem sftp sftp-server.exe

Checklist sécurité prête à l’emploi

Clés publiques uniquement (PasswordAuthentication no).
Port non standard si vous devez publier le service, plus filtrage IP/VPN.
Pare‑feu restrictif : profils Privé/Domaine ; éviter le profil Public.
Comptes dédiés aux usages SSH, droits minimaux.
Mises à jour du composant OpenSSH et du système — idéalement migrer vers une version Windows prise en charge.
Surveillance des logs OpenSSH/Operational et alertes de connexion.

Synthèse

À la date d’octobre 2025, aucune méthode native ne permet d’utiliser directement un compte Microsoft personnel pour se connecter en SSH à Windows 10. Ce n’est pas un problème de mot de passe : c’est une limitation de l’authentification côté serveur. La voie la plus simple, sûre et maintenable est de créer un compte local (ou d’utiliser un compte de domaine/Azure AD en contexte entreprise) et de configurer SSH en authentification par clé publique, derrière un filtrage réseau strict. Vous gagnez en sécurité, vous conservez votre confort d’ouverture de session Windows avec le compte Microsoft, et vous maîtrisez finement l’exposition du service.

Exemple de procédure condensée

# 1) Créer un compte local
New-LocalUser -Name sshadmin -Password (Read-Host "Pass" -AsSecureString)

# 2) Installer/activer OpenSSH-Server

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service sshd -StartupType Automatic

# 3) Poser une clé publique

$ssh = "C:\Users\sshadmin.ssh"
New-Item -ItemType Directory -Force $ssh | Out-Null
Set-Content -Path (Join-Path $ssh "authorized_keys") -Value "ssh-ed25519 AAAA... client" -Encoding ascii
icacls $ssh /inheritance:r > $null
icacls $ssh /grant "sshadmin:(OI)(CI)F" "SYSTEM:(OI)(CI)F" > $null
icacls (Join-Path $ssh "authorized_keys") /inheritance:r > $null
icacls (Join-Path $ssh "authorized_keys") /grant "sshadmin:F" "SYSTEM:F" > $null

# 4) Durcir sshd_config (désactiver mot de passe), puis :

Restart-Service sshd

# 5) Règle pare-feu (LAN)

New-NetFirewallRule -Name sshd-LAN -DisplayName "OpenSSH LAN" -Enabled True `
-Direction Inbound -Protocol TCP -Action Allow -LocalPort 22 -RemoteAddress 192.168.1.0/24

En quelques commandes, vous obtenez un accès distant prévisible, sécurisé et compatible avec les contraintes de Windows 10.