Accès distant à PowerShell via SSH

Article
04/05/2024

Vue d’ensemble

L’accès distant PowerShell utilise normalement WinRM pour la négociation de la connexion et le transport des données. SSH est désormais disponible pour les plateformes Linux et Windows, et permet une réelle communication à distance PowerShell multiplateforme.

WinRM fournit un modèle d’hébergement robuste pour les sessions distantes PowerShell. La communication à distance SSH ne prend actuellement en charge ni la configuration de points de terminaison distants ni l’administration JEA (Just Enough Administration).

La communication à distance SSH vous permet d’établir la communication à distance pour une session PowerShell de base entre des ordinateurs Windows et Linux. La communication à distance SSH crée un processus hôte PowerShell sur l’ordinateur cible en tant que sous-système SSH. Nous implémenterons prochainement un modèle d’hébergement général, similaire à WinRM, pour prendre en charge la configuration de point de terminaison et JEA.

Les cmdlets New-PSSessionEnter-PSSession et Invoke-Command ont maintenant un nouvel ensemble de paramètres pour prendre en charge cette nouvelle connexion de communication à distance.

[-HostName <string>]  [-UserName <string>]  [-KeyFilePath <string>]

Pour créer une session distante, vous devez spécifier l’ordinateur cible avec le paramètre HostName, et indiquer le nom d’utilisateur avec UserName. Lors de l’exécution des cmdlets de manière interactive, vous êtes invité à entrer un mot de passe. Vous pouvez également utiliser l’authentification par clé SSH à l’aide d’un fichier de clé privée avec le paramètre KeyFilePath. La création de clés pour l’authentification SSH varie selon la plateforme.

Informations générales sur l’installation

PowerShell 6 ou version ultérieure et SSH doivent être installés sur tous les ordinateurs. Installez le client SSH (ssh.exe) et le serveur (sshd.exe) pour pouvoir communiquer à distance vers et à partir des ordinateurs. OpenSSH pour Windows est désormais disponible dans Windows 10 build 1809 et Windows Server 2019. Pour plus d’informations, consultez Gérer Windows avec OpenSSH. Pour Linux, installez la version de SSH (avec le serveur sshd) qui correspond à votre plateforme. Vous devez aussi installer PowerShell à partir de GitHub pour obtenir la fonctionnalité de communication à distance SSH. Le serveur SSH doit être configuré pour créer un sous-système SSH destiné à héberger un processus PowerShell sur l’ordinateur distant. Par ailleurs, vous devez activer l’authentification par mot de passe ou clé.

Installer le service SSH sur un ordinateur Windows

Installer la dernière version de PowerShell. Pour plus d’informations, consultez Installation de PowerShell sur Windows.

Vous pouvez vérifier que PowerShell prend bien en charge la communication à distance SSH en listant les jeux de paramètres New-PSSession. Vous noterez la présence de noms de jeux de paramètres commençant par SSH. Ces jeux de paramètres comportent des paramètres SSH.
```
(Get-Command New-PSSession).ParameterSets.Name
```
```
Name
----
SSHHost
SSHHostHashParam
```
Installez la dernière version d’OpenSSH Win32. Pour obtenir des instructions d’installation, consultez Bien démarrer avec OpenSSH.

Remarque

Si vous voulez définir PowerShell en tant qu’interpréteur de commandes par défaut pour OpenSSH, consultez Configuration de Windows pour OpenSSH.
Modifiez le fichier sshd_config situé dans $env:ProgramData\ssh.

Vérifiez que l’authentification par mot de passe est activée :
```
PasswordAuthentication yes
```
Créez le sous-système SSH destiné à héberger un processus PowerShell sur l’ordinateur distant :
```
Subsystem powershell c:/progra~1/powershell/7/pwsh.exe -sshs -nologo
```
Remarque

À compter de PowerShell 7.4, vous n’avez plus besoin d’utiliser le paramètre -nologo lors de l’exécution de PowerShell en mode serveur SSH.
Remarque

L’emplacement par défaut de l’exécutable PowerShell est c:/progra~1/powershell/7/pwsh.exe. L’emplacement peut varier en fonction de la façon dont vous avez installé PowerShell.

Vous devez utiliser le nom abrégé 8.3 pour les chemins de fichiers qui contiennent des espaces. OpenSSH pour Windows présente un bogue qui empêche les espaces de fonctionner dans les chemins exécutables du sous-système. Pour plus d’informations, consultez ce problème GitHub.

Le nom abrégé 8.3 du dossier Program Files dans Windows est généralement Progra~1. Cependant, vous pouvez utiliser la commande suivante pour vous en assurer :
```
Get-CimInstance Win32_Directory -Filter 'Name="C:\\Program Files"' |
  Select-Object EightDotThreeFileName
```
```
EightDotThreeFileName
---------------------
c:\progra~1
```
Vous pouvez éventuellement activer l’authentification par clé :
```
PubkeyAuthentication yes
```
Pour plus d’informations, consultez Gestion des clés OpenSSH.
Redémarrez le service sshd.
```
Restart-Service sshd
```
Ajoutez le chemin où OpenSSH est installé à votre variable d’environnement Path. Par exemple : C:\Program Files\OpenSSH\. Cette entrée permet au système de trouver ssh.exe.

Installer le service SSH sur un ordinateur Ubuntu Linux

Pour installer la dernière version de PowerShell, consultez Installation de PowerShell sur Ubuntu.

Installez Ubuntu OpenSSH Server.

sudo apt install openssh-client
sudo apt install openssh-server

Modifiez le fichier sshd_config à l’emplacement /etc/ssh.

Vérifiez que l’authentification par mot de passe est activée :
```
PasswordAuthentication yes
```
Vous pouvez éventuellement activer l’authentification par clé :
```
PubkeyAuthentication yes
```
Pour plus d’informations sur la création de clés SSH sur Ubuntu, consultez la Manpage concernant ssh-keygen.

Ajoutez une entrée de sous-système PowerShell :
```
Subsystem powershell /usr/bin/pwsh -sshs -nologo
```
Remarque

L’emplacement par défaut de l’exécutable PowerShell est /usr/bin/pwsh. L’emplacement peut varier en fonction de la façon dont vous avez installé PowerShell.

Remarque

À compter de PowerShell 7.4, vous n’avez plus besoin d’utiliser le paramètre -nologo lors de l’exécution de PowerShell en mode serveur SSH.
Redémarrez le servicessh.
```
sudo systemctl restart sshd.service
```

Installer le service SSH sur un ordinateur macOS

Installer la dernière version de PowerShell. Pour plus d’informations, consultez Installation de PowerShell sur macOS.

Vérifiez que l’accès distant SSH est activé en suivant ces étapes :
1. Ouvrez System Settings.
2. Cliquez sur General
3. Cliquez sur Sharing.
4. Vérifiez Remote Login pour définir Remote Login: On.
5. Autorisez l’accès aux utilisateurs appropriés.
Modifiez le fichier sshd_config à l’emplacement /private/etc/ssh/sshd_config.

Utilisez un éditeur de texte tel que nano :
```
sudo nano /private/etc/ssh/sshd_config
```
Vérifiez que l’authentification par mot de passe est activée :
```
PasswordAuthentication yes
```
Ajoutez une entrée de sous-système PowerShell :
```
Subsystem powershell /usr/local/bin/pwsh -sshs -nologo
```
Remarque

L’emplacement par défaut de l’exécutable PowerShell est /usr/local/bin/pwsh. L’emplacement peut varier en fonction de la façon dont vous avez installé PowerShell.

Remarque

À compter de PowerShell 7.4, vous n’avez plus besoin d’utiliser le paramètre -nologo lors de l’exécution de PowerShell en mode serveur SSH.

Vous pouvez éventuellement activer l’authentification par clé :
```
PubkeyAuthentication yes
```

Redémarrez le service sshd.

sudo launchctl stop com.openssh.sshd
sudo launchctl start com.openssh.sshd

Remarque

Lorsque vous mettez à niveau votre système d’exploitation, le fichier config SSH peut être remplacé. Assurez-vous de vérifier le fichier config après une mise à niveau.

Authentification

L’accès distant PowerShell via SSH repose sur l’échange d’authentification entre le client SSH et le service SSH et n’implémente aucun schéma d’authentification par lui-même. Résultat : les schémas d’authentification éventuellement configurés, comme l’authentification multifacteur, sont gérés par SSH et sont indépendants de PowerShell. Par exemple, vous pouvez configurer le service SSH pour exiger une authentification par clé publique et un mot de passe à usage unique pour une sécurité renforcée. La configuration de l’authentification multifacteur sort du cadre de cette documentation. Reportez-vous à la documentation SSH pour savoir comment configurer correctement l’authentification multifacteur et vérifier qu’elle fonctionne en dehors de PowerShell avant d’essayer de l’utiliser avec l’accès distant PowerShell.

Remarque

Les utilisateurs conservent les mêmes privilèges dans les sessions à distance. Cela signifie que les administrateurs ont accès à un interpréteur de commandes avec élévation de privilèges, contrairement aux utilisateurs normaux.

Exemple d’accès distant PowerShell

Le moyen le plus simple de tester l’accès distant est de l’essayer sur un seul ordinateur. Dans cet exemple, nous créons une session distante avec le même ordinateur Linux. Comme nous utilisons des applets de commande PowerShell de manière interactive, des invites SSH s’affichent pour demander de vérifier l’ordinateur hôte et de fournir un mot de passe. Vous pouvez faire la même chose sur un ordinateur Windows pour vérifier que l’accès distant fonctionne. Ensuite, établissez une communication à distance entre les ordinateurs en changeant le nom d’hôte.

De Linux vers Linux

$session = New-PSSession -HostName UbuntuVM1 -UserName TestUser

The authenticity of host 'UbuntuVM1 (9.129.17.107)' can't be established.
ECDSA key fingerprint is SHA256:2kCbnhT2dUE6WCGgVJ8Hyfu1z2wE4lifaJXLO7QJy0Y.
Are you sure you want to continue connecting (yes/no)?
TestUser@UbuntuVM1s password:

$session

 Id Name   ComputerName    ComputerType    State    ConfigurationName     Availability
 -- ----   ------------    ------------    -----    -----------------     ------------
  1 SSH1   UbuntuVM1       RemoteMachine   Opened   DefaultShell             Available

Enter-PSSession $session

[UbuntuVM1]: PS /home/TestUser> uname -a
Linux TestUser-UbuntuVM1 4.2.0-42-generic 49~16.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[UbuntuVM1]: PS /home/TestUser> Exit-PSSession

Invoke-Command $session -ScriptBlock { Get-Process pwsh }

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName    PSComputerName
-------  ------    -----      -----     ------     --  -- -----------    --------------
      0       0        0         19       3.23  10635 635 pwsh           UbuntuVM1
      0       0        0         21       4.92  11033 017 pwsh           UbuntuVM1
      0       0        0         20       3.07  11076 076 pwsh           UbuntuVM1

De Linux vers Windows

Enter-PSSession -HostName WinVM1 -UserName PTestName

PTestName@WinVM1s password:

[WinVM1]: PS C:\Users\PTestName\Documents> cmd /c ver

Microsoft Windows [Version 10.0.10586]

De Windows vers Windows

C:\Users\PSUser\Documents>pwsh.exe

PowerShell
Copyright (c) Microsoft Corporation. All rights reserved.

$session = New-PSSession -HostName WinVM2 -UserName PSRemoteUser

The authenticity of host 'WinVM2 (10.13.37.3)' can't be established.
ECDSA key fingerprint is SHA256:kSU6slAROyQVMEynVIXAdxSiZpwDBigpAF/TXjjWjmw.
Are you sure you want to continue connecting (yes/no)?
Warning: Permanently added 'WinVM2,10.13.37.3' (ECDSA) to the list of known hosts.
PSRemoteUser@WinVM2's password:

$session

 Id Name            ComputerName    ComputerType    State         ConfigurationName     Availability
 -- ----            ------------    ------------    -----         -----------------     ------------
  1 SSH1            WinVM2          RemoteMachine   Opened        DefaultShell             Available

Enter-PSSession -Session $session

[WinVM2]: PS C:\Users\PSRemoteUser\Documents> $PSVersionTable

Name                           Value
----                           -----
PSEdition                      Core
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
SerializationVersion           1.1.0.1
BuildVersion                   3.0.0.0
CLRVersion
PSVersion                      6.0.0-alpha
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
GitCommitId                    v6.0.0-alpha.17


[WinVM2]: PS C:\Users\PSRemoteUser\Documents>

Limites

La commande sudo ne fonctionne pas dans une session distante sur un ordinateur Linux.
PSRemoting par SSH ne prend pas en charge les profils et n’a pas accès à $PROFILE. Une fois que vous avez ouvert une session, vous pouvez charger un profil en le « dot sourçant » avec le chemin de fichier complet. Cela n’a aucun lien avec les profils SSH. Vous pouvez configurer le serveur SSH pour utiliser PowerShell comme interpréteur de commandes par défaut et charger un profil par le biais du SSH. Pour plus d’informations, consultez la documentation SSH.
Avant PowerShell 7.1, la communication à distance par SSH ne prenait pas en charge les sessions à distance de deuxième tronçon. Cette fonctionnalité était limitée aux sessions qui utilisaient WinRM. PowerShell 7.1 permet à Enter-PSSession et Enter-PSHostProcess de fonctionner dans n’importe quelle session à distance interactive.