Granska fjärrkommunikationsfunktionen i Windows PowerShell
Fjärrkommunikation använder ett protokoll med öppen standard som kallas Web Services for Management (WS-Management eller WS-MAN). Som namnet antyder bygger det här protokollet på samma HTTP- eller HTTPS-protokoll som webbläsare använder för att kommunicera med webbservrar. Detta gör protokollet enklare att hantera och dirigera genom brandväggar. Windows-operativsystem implementerar protokollet med hjälp av WinRM-tjänsten (Windows Remote Management). PowerShell stöder fjärrkommunikation med WMI, WS-Management och Secure Shell (SSH). I PowerShell 6 stöds inte RPC-baserad kommunikation (Remote Procedure Calls). I PowerShell 7 och senare stöds RPC endast i Windows.
Du måste aktivera fjärrkommunikation på de datorer där du vill ta emot inkommande anslutningar, men ingen konfiguration krävs på datorer som initierar utgående anslutningar. PowerShell-fjärrkommunikation är aktiverat som standard för inkommande anslutningar på alla versioner av Windows Server som stöds för närvarande. Du kan också aktivera det på alla datorer som kör Windows PowerShell 3.0 eller senare.
Kommentar
Även om fjärrkommunikation är aktiverat som standard på Windows Server-operativsystem är det inte aktiverat som standard på klientoperativsystem, inklusive Windows 10 och Windows 11.
Windows PowerShell-fjärrkommunikation använder WinRM, som kan hantera kommunikation för andra program. Vid en standardinstallation av Windows Server 2016 eller senare hanterar WinRM till exempel kommunikation för 64-bitars Windows PowerShell, 32-bitars Windows PowerShell och två Serverhanteraren komponenter.
Fjärrkommunikationsarkitektur
Fjärrkommunikation börjar med WinRM-tjänsten. Den registrerar en eller flera lyssnare, där varje lyssnare accepterar inkommande trafik via antingen HTTP eller HTTPS. Varje lyssnare kan bindas till en enda lokal IP-adress eller till flera IP-adresser. Det finns inget beroende av Microsoft Internet Information Services (IIS), vilket innebär att IIS inte behöver installeras för att WinRM ska fungera.
Inkommande trafik innehåller ett pakethuvud som anger trafikens avsedda mål eller slutpunkt. I Windows PowerShell kallas dessa slutpunkter även sessionskonfigurationer. Varje slutpunkt är associerad med ett specifikt program. När trafiken dirigeras till en slutpunkt startar WinRM det associerade programmet, lämnar av inkommande trafik och väntar sedan på att programmet ska slutföra sin uppgift. Programmet kan skicka tillbaka data till WinRM och WinRM överför data tillbaka till den ursprungliga datorn.
I ett Windows PowerShell-scenario skulle du skicka kommandon till WinRM, som sedan kör kommandona. Processen visas som Wsmprovhost i fjärrdatorns processlista. Windows PowerShell skulle sedan köra dessa kommandon och konvertera de resulterande objekten (om det finns några) till XML. XML-textströmmen skickas sedan tillbaka till WinRM, som överför den till den ursprungliga datorn. Windows PowerShell på fjärrdatorn översätter XML tillbaka till statiska objekt. Detta gör att kommandoresultatet fungerar ungefär som andra objekt i Windows PowerShell-pipelinen.
Windows PowerShell kan registrera flera slutpunkter eller sessionskonfigurationer med WinRM. Faktum är att ett 64-bitars operativsystem registrerar en slutpunkt för både 64-bitars Windows PowerShell-värden och 32-bitarsvärden som standard. Du kan också skapa egna anpassade slutpunkter som har mycket exakta behörigheter och funktioner som tilldelats dem.
Windows PowerShell-fjärrkommunikation utan konfiguration
Många Windows PowerShell-cmdletar har parametern ComputerName som gör att du kan samla in data och ändra inställningar på en eller flera fjärrdatorer. Dessa cmdletar använder olika kommunikationsprotokoll och fungerar på alla Windows-operativsystem utan någon särskild konfiguration.
Dessa cmdletar omfattar:
- Starta om datorn
- Testanslutning
- Clear-EventLog
- Get-EventLog
- Get-HotFix
- Get-Process
- Get-Service
- Set-Service
- Get-WinEvent
- Get-WmiObject
Vanligtvis har cmdletar som stöder fjärrkommunikation utan särskild konfiguration parametern ComputerName och har inte parametern Session .
Om du vill hitta dessa cmdletar i sessionen anger du:
Get-Command | where { $_.parameters.keys -contains "ComputerName" -and $_.parameters.keys -notcontains "Session"}
PowerShell fjärrkommunikation via SSH
PowerShell-fjärrkommunikation använder normalt WinRM för anslutningsförhandling och datatransport. SSH är nu tillgängligt för Linux- och Windows-plattformar och tillåter äkta PowerShell-fjärrkommunikation med flera plattformar.
WinRM tillhandahåller en robust värdmodell för PowerShell-fjärrsessioner. SSH-baserad fjärrkommunikation stöder för närvarande inte fjärrslutpunktskonfiguration och JEA (Just Enough Administration).
SSH-fjärrkommunikation erbjuder grundläggande PowerShell-sessionskommunikation mellan Windows- och Linux-datorer. SSH-fjärrkommunikation skapar en PowerShell-värdprocess på måldatorn som ett SSH-undersystem. Microsoft planerar att så småningom implementera en allmän värdmodell som liknar WinRM för att stödja slutpunktskonfiguration och JEA.
Kommentar
Cmdletarna New-PSSession, Enter-PSSession och Invoke-Command har nu en ny parameter inställd för att stödja den nya fjärrkommunikationsanslutningen.
Om du vill använda PowerShell-fjärrkommunikation via SSH måste du installera PowerShell 6 eller senare och SSH på alla datorer. Sedan måste du installera körbara filer för både SSH-klienten (ssh.exe) och servern (sshd.exe) så att du kan fjärransluta till och från datorerna. OpenSSH för Windows är tillgängligt från och med Windows 10 build 1809 och Windows Server 2019. För Linux installerar du den version av SSH (inklusive sshd.exe-servern) som är lämplig för din plattform. Du måste också installera den aktuella versionen av PowerShell från GitHub för att säkerställa att SSH-fjärrkommunikationsfunktionen är tillgänglig. Du bör konfigurera SSH-servern för att skapa ett SSH-undersystem som är värd för en PowerShell-process på fjärrdatorn. Du måste också aktivera lösenord eller nyckelbaserad autentisering.