PowerShell-Remoting

Allgemeine Infos

PowerShell-Remoting führt Befehle und Skripte auf entfernten Computern aus. Invoke-Command verteilt einen Befehl an einen oder viele Rechner, Enter-PSSession öffnet eine interaktive Sitzung auf einem einzelnen System, New-PSSession baut eine dauerhafte Sitzung auf, die Du mehrfach nutzt.

Unter Windows läuft Remoting über WinRM (WS-Management). Windows Server ab 2012 hat Remoting standardmäßig aktiviert. Windows-Clients können ohne Konfiguration Verbindungen aufbauen, nehmen aber erst nach Enable-PSRemoting selbst Verbindungen an. Standardmäßig dürfen nur Mitglieder der lokalen Administratoren die Standard-Endpunkte nutzen.

Seit PowerShell 6 gibt es zusätzlich SSH-Remoting, das auch Linux und macOS einbindet. Es unterstützt allerdings keine Endpunktkonfiguration und kein Just Enough Administration (JEA). Abgrenzung: Cmdlets mit eigenem -ComputerName-Parameter wie Get-Service nutzen andere Protokolle und sind kein PowerShell-Remoting, Remotedesktop ist ein grafischer Zugang.

Funktionsweise & Details

WinRM nutzt TCP-Port 5985 (HTTP) und 5986 (HTTPS). Der Ablauf:

  1. Enable-PSRemoting richtet den WinRM-Listener, die Sitzungskonfigurationen und die Firewallregel ein. In öffentlichen Netzwerken lässt die Regel nur Verbindungen aus dem lokalen Subnetz zu.
  2. Der Client verbindet sich per Invoke-Command -ComputerName, Enter-PSSession oder New-PSSession.
  3. In der Domäne authentifiziert Kerberos Benutzer und Server, ohne wiederverwendbare Anmeldedaten zu senden. Bei IP-Adressen oder Arbeitsgruppen fällt PowerShell auf NTLM zurück, das nur mit HTTPS-Listener oder TrustedHosts-Eintrag erlaubt ist.
  4. Nach der Authentifizierung verschlüsselt WinRM die Kommunikation immer, auch über HTTP.
  5. Der Befehl läuft im Kontext des angemeldeten Benutzers. Ergebnisse kommen serialisiert zurück, also als Datenobjekte ohne Methoden.

SSH-Remoting setzt PowerShell 6 oder neuer und OpenSSH auf beiden Seiten voraus. In der sshd_config wird pwsh als Subsystem eingetragen, die Verbindung erfolgt mit -HostName, -UserName und optional -KeyFilePath.

Vorteile & Nutzen

  • Fan-out: Invoke-Command bearbeitet Dutzende Server parallel, statt dass Du Dich nacheinander per RDP anmeldest
  • Sichere Standardkonfiguration: Kerberos-Authentifizierung und Verschlüsselung sind in der Domäne ohne Zertifikat aktiv
  • Persistente Sitzungen: Variablen und geladene Module bleiben in New-PSSession erhalten, Folgebefehle sparen Aufbauzeit
  • Plattformübergreifend über SSH: Linux-Server lassen sich mit denselben Cmdlets verwalten

Praxisbeispiel

Ein Lebensmittelhersteller mit 40 Windows-Servern prüft nach jedem Patchday, ob Neustarts ausstehen und kritische Dienste laufen. Statt sich auf jedem Server anzumelden, startet der Admin ein Invoke-Command gegen die Serverliste aus dem AD und sammelt die Ergebnisse zentral in einer CSV-Datei. Die Firewallregel für WinRM ist auf das Admin-Subnetz beschränkt. Die Prüfung dauert so wenige Minuten statt eines halben Vormittags.

Worauf sollte man achten?

  • TrustedHosts ist keine Vertrauensaussage: NTLM prüft die Identität des Zielservers nicht, besser ein HTTPS-Listener mit Zertifikat einer vertrauenswürdigen CA
  • Für delegierte Zugriffe auf weitere Systeme (Second Hop) CredSSP nur nach Abwägung einsetzen, weil dabei Anmeldedaten auf dem Zielsystem landen
  • Mit JEA eingeschränkte Endpunkte für Helpdesk-Aufgaben bauen, statt Admin-Rechte zu vergeben
  • WinRM-Ports in der Firewall auf Admin-Netze oder Jump-Hosts begrenzen
  • Rückgabeobjekte sind deserialisiert: Methoden wie .Stop() stehen auf dem Client nicht zur Verfügung, Aktionen gehören in den Remote-Skriptblock

Lizenz & Verfügbarkeit

WinRM-basiertes Remoting ist in Windows und Windows Server enthalten, SSH-Remoting ist mit PowerShell 7 und OpenSSH ohne Zusatzkosten nutzbar. Stand: Oktober 2026.

Fazit

PowerShell-Remoting ist der Standardweg, viele Windows-Server gleichzeitig zu verwalten. Setze auf Kerberos oder HTTPS, begrenze die Firewall und nutze JEA für delegierte Aufgaben.