PowerShell Remoting est l’une des fonctionnalités les plus puissantes de la boîte à outils d’administration Windows. Il vous permet d’exécuter des commandes, de lancer des scripts et de gérer des configurations sur des machines distantes — une à la fois ou sur des centaines simultanément. Au cœur de son fonctionnement, PowerShell Remoting s’appuie sur Windows Remote Management (WinRM), l’implémentation par Microsoft du protocole WS-Management. Dans ce guide, vous apprendrez comment activer et configurer WinRM, utiliser les principaux cmdlets de remoting, gérer les identifiants de manière sécurisée, gérer les scénarios inter-domaines et exploiter le remoting basé sur SSH pour la gestion multiplateforme.

Prérequis

Avant de commencer la configuration de PowerShell Remoting, assurez-vous d’avoir les éléments suivants :

  • Windows Server 2016 ou ultérieur (ou Windows 10/11 Pro/Enterprise pour les machines clientes)
  • PowerShell 5.1 ou ultérieur installé (PowerShell 7+ recommandé pour le remoting basé sur SSH)
  • Privilèges administratifs sur les machines client et distantes
  • Connectivité réseau sur le port 5985 (HTTP) ou 5986 (HTTPS) entre le client et le serveur
  • Domaine Active Directory (recommandé mais pas obligatoire — les configurations de groupe de travail sont couvertes ci-dessous)
  • Familiarité de base avec les cmdlets PowerShell et la configuration du pare-feu Windows

Activation et Configuration de WinRM

WinRM est installé par défaut sur les systèmes Windows modernes, mais le service n’est généralement pas en cours d’exécution et les règles de pare-feu ne sont pas activées sur les systèmes d’exploitation clients. Sur les éditions Windows Server à partir de 2012, WinRM est activé par défaut, mais vous devriez quand même vérifier la configuration.

Activer PSRemoting

La façon la plus rapide de tout activer en une seule fois est le cmdlet Enable-PSRemoting :

# Exécuter dans une session PowerShell élevée sur la machine distante
Enable-PSRemoting -Force

Cette commande unique effectue plusieurs actions : elle démarre le service WinRM, le configure pour un démarrage automatique, crée un écouteur HTTP sur le port 5985, ajoute des exceptions au Pare-feu Windows et enregistre les configurations de session PowerShell par défaut.

Vérifier que WinRM Est à l’Écoute

Après l’activation, confirmez que le service fonctionne et que les écouteurs sont actifs :

# Vérifier l'état du service
Get-Service WinRM

# Lister les écouteurs actifs
Get-WSManInstance -ResourceURI winrm/config/listener -Enumerate

# Test rapide de connectivité depuis le client
Test-WSMan -ComputerName SERVEUR01

Configurer TrustedHosts

Dans un environnement de domaine, Kerberos gère l’authentification de manière transparente. Dans les scénarios de groupe de travail ou inter-domaines, vous devez configurer TrustedHosts sur la machine cliente :

# Ajouter un seul hôte
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "SERVEUR01"

# Ajouter plusieurs hôtes (séparés par des virgules)
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "SERVEUR01,SERVEUR02,192.168.1.50"

# Faire confiance à tous les hôtes (NON recommandé pour la production)
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*"

# Voir les TrustedHosts actuels
Get-Item WSMan:\localhost\Client\TrustedHosts

Configurer le Transport HTTPS

Pour les environnements de production, en particulier à travers des réseaux non fiables, le transport HTTPS chiffre l’intégralité de la session WinRM :

# Sur le serveur distant : créer un certificat auto-signé
$cert = New-SelfSignedCertificate -DnsName "SERVEUR01.contoso.com" `
    -CertStoreLocation Cert:\LocalMachine\My -NotAfter (Get-Date).AddYears(5)

# Créer un écouteur HTTPS en utilisant l'empreinte du certificat
New-WSManInstance -ResourceURI winrm/config/listener `
    -SelectorSet @{Address="*"; Transport="HTTPS"} `
    -ValueSet @{CertificateThumbprint=$cert.Thumbprint}

# Ajouter une règle de pare-feu pour HTTPS
New-NetFirewallRule -DisplayName "WinRM HTTPS" -Direction Inbound `
    -LocalPort 5986 -Protocol TCP -Action Allow

Configurer via la Stratégie de Groupe

Pour un déploiement à l’échelle du domaine, utilisez la Stratégie de Groupe pour activer WinRM à grande échelle :

  1. Naviguez vers Configuration ordinateur → Modèles d’administration → Composants Windows → Gestion à distance de Windows → Service WinRM
  2. Activez Autoriser la gestion à distance du serveur via WinRM
  3. Définissez le filtre IPv4/IPv6 sur * ou des sous-réseaux spécifiques
  4. Configurez Shell distant Windows → Autoriser l’accès au Shell distant sur Activé

Utilisation d’Invoke-Command et Enter-PSSession

PowerShell fournit deux cmdlets principaux pour l’exécution distante, chacun adapté à des flux de travail différents.

Invoke-Command — Exécution par Lots en Parallèle

Invoke-Command envoie un bloc de script à un ou plusieurs ordinateurs et les exécute en parallèle par défaut (jusqu’à 32 connexions simultanées) :

# Exécuter une commande sur un seul hôte distant
Invoke-Command -ComputerName SERVEUR01 -ScriptBlock {
    Get-Process | Sort-Object CPU -Descending | Select-Object -First 10
}

# Exécuter sur plusieurs serveurs simultanément
$serveurs = @("SERVEUR01", "SERVEUR02", "SERVEUR03", "SERVEUR04")
Invoke-Command -ComputerName $serveurs -ScriptBlock {
    Get-Service -Name "W3SVC" | Select-Object Status, MachineName
}

# Limiter la concurrence pour les grands environnements
Invoke-Command -ComputerName $serveurs -ScriptBlock {
    Restart-Service -Name "Spooler" -Force
} -ThrottleLimit 10

# Exécuter un fichier de script local sur des machines distantes
Invoke-Command -ComputerName $serveurs -FilePath "C:\Scripts\Audit-Security.ps1"

Enter-PSSession — Remoting Interactif

Enter-PSSession est idéal pour le dépannage ad-hoc où vous avez besoin d’un shell interactif :

# Démarrer une session interactive
Enter-PSSession -ComputerName SERVEUR01 -Credential (Get-Credential)

# Vous êtes maintenant sur SERVEUR01 — exécutez des commandes comme en local
[SERVEUR01]: PS C:\> Get-EventLog -LogName System -Newest 20
[SERVEUR01]: PS C:\> Get-Disk | Format-Table
[SERVEUR01]: PS C:\> Exit-PSSession

Sessions Persistantes (PSSessions)

Pour les connexions répétées, créez une session persistante pour éviter la surcharge de l’établissement d’une nouvelle connexion à chaque fois :

# Créer des sessions persistantes
$sessions = New-PSSession -ComputerName SERVEUR01, SERVEUR02, SERVEUR03

# Réutiliser la session pour plusieurs commandes
Invoke-Command -Session $sessions -ScriptBlock { Get-HotFix | Select-Object -Last 5 }
Invoke-Command -Session $sessions -ScriptBlock { Get-WindowsFeature | Where-Object Installed }

# Copier des fichiers via une session
Copy-Item -Path "C:\Deploy\app.zip" -Destination "C:\Install\" -ToSession $sessions[0]

# Nettoyer quand c'est terminé
Remove-PSSession $sessions

Gestion des Identifiants et Sécurité

La gestion appropriée des identifiants est cruciale pour un remoting sécurisé à grande échelle.

Utilisation de Get-Credential et PSCredential

# Invite interactive
$cred = Get-Credential -UserName "CONTOSO\admin" -Message "Entrez le mot de passe administrateur distant"

# Identifiant programmatique (pour l'automatisation — protégez la source du mot de passe)
$securePass = ConvertTo-SecureString "P@ssw0rd!" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential("CONTOSO\admin", $securePass)

Stockage Sécurisé des Identifiants

Ne codez jamais les mots de passe en dur dans les scripts. Utilisez l’une de ces approches :

# Exporter un identifiant chiffré vers un fichier (spécifique utilisateur+machine)
Get-Credential | Export-Clixml -Path "$HOME\cred.xml"

# Importer dans une autre session (même utilisateur, même machine uniquement)
$cred = Import-Clixml -Path "$HOME\cred.xml"

# Utiliser le Gestionnaire d'identifiants Windows via le module CredentialManager
Install-Module -Name CredentialManager -Force
New-StoredCredential -Target "WinRM-Admin" -UserName "CONTOSO\admin" `
    -Password "P@ssw0rd!" -Persist LocalMachine
$cred = Get-StoredCredential -Target "WinRM-Admin"

CredSSP pour les Scénarios de Double Saut

Lorsqu’une commande distante doit accéder à une deuxième ressource (le problème du “double saut”), configurez la délégation CredSSP :

# Sur le client : activer le rôle client CredSSP
Enable-WSManCredSSP -Role Client -DelegateComputer "SERVEUR01.contoso.com"

# Sur le serveur : activer le rôle serveur CredSSP
Enable-WSManCredSSP -Role Server

# Se connecter en utilisant l'authentification CredSSP
Invoke-Command -ComputerName SERVEUR01 -Credential $cred `
    -Authentication CredSSP -ScriptBlock {
    # Peut maintenant accéder aux ressources réseau comme les partages
    Get-ChildItem "\\FILESERVER\Share$"
}

Avertissement : CredSSP envoie les identifiants au serveur distant. Utilisez-le uniquement avec des machines de confiance et de préférence via HTTPS.

Just Enough Administration (JEA)

Pour un remoting à moindres privilèges, configurez des endpoints JEA qui limitent ce que les utilisateurs peuvent faire :

# Créer un fichier de capacité de rôle
New-PSRoleCapabilityFile -Path "C:\JEA\HelpDeskRole.psrc" `
    -VisibleCmdlets @("Restart-Service", "Get-Service", "Get-Process") `
    -VisibleFunctions @("Get-HotFix")

# Créer la configuration de session
New-PSSessionConfigurationFile -Path "C:\JEA\HelpDesk.pssc" `
    -SessionType RestrictedRemoteServer `
    -RunAsVirtualAccount `
    -RoleDefinitions @{ "CONTOSO\HelpDesk" = @{ RoleCapabilities = "HelpDeskRole" } }

# Enregistrer l'endpoint
Register-PSSessionConfiguration -Name "HelpDesk" -Path "C:\JEA\HelpDesk.pssc"

Remoting Basé sur SSH pour le Multiplateforme

À partir de PowerShell 7, vous pouvez utiliser SSH comme couche de transport au lieu de WinRM. C’est particulièrement utile pour gérer des machines Linux et macOS aux côtés des serveurs Windows.

Installer et Configurer OpenSSH

# Sur Windows : installer le serveur OpenSSH
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service sshd -StartupType Automatic

# Configurer le sous-système SSH pour PowerShell dans sshd_config
# Ajoutez cette ligne à C:\ProgramData\ssh\sshd_config :
# Subsystem powershell c:/progra~1/powershell/7/pwsh.exe -sshs -NoLogo -NoProfile
Restart-Service sshd

Sur Linux, ajoutez le sous-système PowerShell à /etc/ssh/sshd_config :

# Installer PowerShell sur Ubuntu
sudo apt-get update && sudo apt-get install -y powershell

# Ajouter le sous-système à sshd_config
echo "Subsystem powershell /usr/bin/pwsh -sshs -NoLogo -NoProfile" | sudo tee -a /etc/ssh/sshd_config
sudo systemctl restart sshd

Utilisation du Remoting Basé sur SSH

# Session interactive via SSH
Enter-PSSession -HostName serveur-linux01 -UserName admin -SSHTransport

# Exécuter des commandes sur Linux depuis Windows
Invoke-Command -HostName serveur-linux01 -UserName admin -ScriptBlock {
    uname -a
    df -h
    systemctl status nginx
}

# Cibler des systèmes d'exploitation mixtes
$sessionWindows = New-PSSession -ComputerName WIN-SRV01 -Credential $cred
$sessionLinux = New-PSSession -HostName LINUX-SRV01 -UserName admin -SSHTransport

Invoke-Command -Session $sessionWindows, $sessionLinux -ScriptBlock {
    if ($IsLinux) { cat /etc/os-release } else { Get-ComputerInfo | Select-Object OsName }
}

Comparaison : WinRM vs Remoting Basé sur SSH vs OpenSSH sur Windows

FonctionnalitéWinRM (HTTP/HTTPS)Remoting Basé sur SSH (PS7)OpenSSH sur Windows
ProtocoleWS-ManagementSSHSSH
Ports par défaut5985 / 59862222
AuthentificationKerberos, NTLM, CredSSPClés SSH, mot de passeClés SSH, mot de passe
MultiplateformeWindows uniquementWindows, Linux, macOSWindows uniquement (serveur)
Version PowerShell5.1+7.0+ requisToute (shell SSH uniquement)
ChiffrementHTTPS ou niveau messageToujours chiffréToujours chiffré
Double sautCredSSP ou délégation KerberosTransfert d’agent SSHTransfert d’agent SSH
Intégration domaineAD/Kerberos natifGestion manuelle des clésGestion manuelle des clés
Gestion par GPOSupport completLimitéLimité
Idéal pourEnvironnements Windows uniquementEnvironnements OS mixtesAdmins Linux gérant Windows

Scénario Réel

Imaginez que vous êtes un administrateur système gérant plus de 50 serveurs Windows répartis sur trois environnements — Développement, Staging et Production — plus quelques machines Linux exécutant des proxies inverses Nginx. Voici comment vous structureriez votre flux de travail avec PowerShell Remoting :

# Définir les groupes de serveurs
$serveursDev = Get-Content "C:\ListesServeurs\dev.txt"
$serveursStaging = Get-Content "C:\ListesServeurs\staging.txt"
$serveursProd = Get-Content "C:\ListesServeurs\prod.txt"

# Créer des sessions persistantes avec des identifiants stockés
$cred = Import-Clixml "$HOME\admin-cred.xml"
$sessionsDev = New-PSSession -ComputerName $serveursDev -Credential $cred
$sessionsStaging = New-PSSession -ComputerName $serveursStaging -Credential $cred

# Vérification de santé matinale sur tous les serveurs de développement
$rapportSante = Invoke-Command -Session $sessionsDev -ScriptBlock {
    [PSCustomObject]@{
        Serveur      = $env:COMPUTERNAME
        Uptime       = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
        CPUPourcent  = (Get-CimInstance Win32_Processor).LoadPercentage
        LibreGB      = [math]::Round((Get-CimInstance Win32_LogicalDisk -Filter "DeviceID='C:'").FreeSpace / 1GB, 2)
        Services     = (Get-Service | Where-Object { $_.StartType -eq "Automatic" -and $_.Status -ne "Running" }).Count
    }
}

$rapportSante | Format-Table Serveur, Uptime, CPUPourcent, LibreGB, Services -AutoSize

# Déployer un correctif vers staging avec concurrence limitée
Invoke-Command -Session $sessionsStaging -ThrottleLimit 5 -ScriptBlock {
    Start-Process msiexec.exe -ArgumentList "/i C:\Deploy\hotfix-kb123.msi /quiet" -Wait
    Write-Output "$env:COMPUTERNAME — Correctif installé"
}

# Vérifier les proxies Linux via SSH
$sessionsLinux = New-PSSession -HostName "proxy01","proxy02" -UserName admin -SSHTransport
Invoke-Command -Session $sessionsLinux -ScriptBlock {
    systemctl is-active nginx
    curl -s -o /dev/null -w "%{http_code}" http://localhost
}

Ce modèle maintient les sessions ouvertes pendant la durée de votre travail, minimise la surcharge d’authentification et vous permet de cibler des groupes d’environnements spécifiques avec une exécution contrôlée.

Pièges et Cas Particuliers

  • Blocage par le pare-feu : WinRM utilise le port 5985 (HTTP) et 5986 (HTTPS). Si le remoting échoue silencieusement, vérifiez à la fois le Pare-feu Windows et tout pare-feu réseau entre le client et le serveur.
  • Réinitialisation de TrustedHosts : Définir TrustedHosts avec Set-Item remplace toute la liste. Utilisez -Concatenate pour ajouter : Set-Item WSMan:\localhost\Client\TrustedHosts -Value "NOUVEAUSERVEUR" -Concatenate.
  • MaxMemoryPerShellMB : La limite par défaut (1024 Mo) peut provoquer la chute des sessions lors d’opérations intensives en mémoire. Augmentez avec Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 2048.
  • Échec du double saut : L’accès aux ressources réseau depuis une session distante échoue par défaut. Utilisez CredSSP, la délégation contrainte Kerberos ou la délégation contrainte basée sur les ressources pour résoudre ce problème.
  • Limites de session : WinRM a une limite par défaut de 25 shells concurrents par utilisateur. Dans les grands environnements, augmentez MaxShellsPerUser dans la configuration WinRM.
  • Décalage de fuseau horaire : Les horodatages retournés depuis les sessions distantes utilisent le fuseau horaire du serveur distant. Utilisez [DateTime]::UtcNow pour la cohérence dans les environnements multi-régions.
  • Chemin du sous-système SSH : Sous Windows, le chemin du sous-système dans sshd_config doit utiliser le format de nom court 8.3 (progra~1) ou le chemin complet sans espaces.
  • Limites de sérialisation : Les objets retournés depuis les sessions distantes sont désérialisés — ils perdent leurs méthodes. Ce qui revient est un instantané, pas un objet vivant. Planifiez vos blocs de script pour extraire les données nécessaires côté distant.
  • Incompatibilité de version PowerShell : Si la machine distante exécute PowerShell 5.1 et le client PowerShell 7, tous les cmdlets ne seront pas disponibles. Testez avec -ConfigurationName PowerShell.7 pour les endpoints PS7.

Résumé

  • Enable-PSRemoting est la commande tout-en-un pour configurer WinRM sur n’importe quelle machine Windows.
  • TrustedHosts doit être configuré sur le client pour les connexions de groupe de travail ou inter-domaines.
  • Le transport HTTPS doit être utilisé en production pour chiffrer le trafic de remoting de bout en bout.
  • Invoke-Command est l’outil principal pour l’exécution parallèle sur plusieurs serveurs ; Enter-PSSession est idéal pour le dépannage interactif.
  • La gestion des identifiants doit utiliser Export-Clixml, le Gestionnaire d’identifiants ou un coffre-fort de secrets — jamais de mots de passe codés en dur.
  • CredSSP ou la délégation contrainte Kerberos résout le problème du double saut.
  • Le remoting basé sur SSH dans PowerShell 7+ permet la gestion multiplateforme de Linux et macOS depuis les mêmes scripts.
  • Les endpoints JEA fournissent un remoting à moindres privilèges pour l’administration déléguée.
  • Surveillez les limites de session, le comportement de sérialisation et les règles de pare-feu à mesure que votre environnement évolue.

Articles Connexes