PowerShell-Remoting aktivieren und nutzen: WinRM, TrustedHosts und das Second-Hop-Limit

Ziel

PowerShell-Remoting auf einem Windows-Server-2019/2022/2025-Host aktivieren und aus einer Agent-Sitzung heraus nutzen – lokal über WinRM oder über SSH, wenn nur Port 22 offen ist –, ohne eine zu weit gefasste Vertrauenseinstellung zurückzulassen.

Voraussetzungen

Lokale Administratorrechte auf dem Zielsystem; der WinRM-Dienst darf starten. Bei einem Ziel ausserhalb der Domäne oder bei einer Verbindung über die IP-Adresse ist entweder ein HTTPS-Listener mit Zertifikat oder ein expliziter TrustedHosts-Eintrag nötig, der auf dem Rechner gesetzt wird, der die Verbindung aufbaut.

Schritte

1. Aktuellen Zustand prüfen: Get-Service WinRM; Test-WSMan SRV1.
2. Remoting nicht interaktiv aktivieren: Enable-PSRemoting -Force -SkipNetworkProfileCheck. Dies startet den WinRM-Dienst, stellt ihn auf automatischen Start und legt den Standard-Listener sowie die Firewallregel an; -Force unterdrückt die Bestätigungsabfragen der einzelnen Schritte, damit der Aufruf in einem unbeaufsichtigten Lauf nicht hängen bleibt.
3. Ist das Ziel nicht in eine Domäne eingebunden oder muss die Verbindung über die IP-Adresse statt über den Namen erfolgen, steht die gegenseitige Kerberos-Authentifizierung nicht zur Verfügung. Die Troubleshooting-Hinweise von Microsoft besagen: "If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting." Bevorzugt wird ein HTTPS-Listener mit Zertifikat; Set-Item WSMan:\localhost\Client\TrustedHosts -Value '10.0.0.5' -Force nur verwenden, wenn akzeptiert wird, dass TrustedHosts die Überprüfung der Serveridentität überspringt.
4. Nicht interaktive Aufgaben mit Invoke-Command -ComputerName SRV1 -Credential $cred -ScriptBlock { Get-Service } ausführen; Enter-PSSession -ComputerName SRV1 nur für die interaktive Fehlersuche einsetzen, nicht in unbeaufsichtigten Skripten, da es an einer Eingabeaufforderung blockiert.
5. Ist nur SSH offen oder sind mehrere Plattformen beteiligt, kann PowerShell 7 das Remoting über SSH statt über WinRM abwickeln, sobald im OpenSSH-Server das PowerShell-Subsystem konfiguriert ist: Invoke-Command -HostName SRV1 -UserName admin -SSHTransport -ScriptBlock { hostname }.

Erwartetes Ergebnis

Test-WSMan liefert ein Antwortobjekt, Invoke-Command gibt Ausgaben ohne Rückfrage zurück, und eine SSH-basierte Sitzung authentifiziert sich am konfigurierten Subsystem.

Grenzen und Prüfbasis

Die Anmeldedaten, mit denen eine Remotesitzung geöffnet wird, werden nicht an einen zweiten Remotecomputer weitergereicht, auf den aus dieser Sitzung heraus zugegriffen wird. Die Microsoft-Dokumentation nennt dies "the second hop"; der Grund ist, dass das Token standardmässig nicht delegiert wird. Als dokumentierte Umgehungen gelten CredSSP oder die ressourcenbasierte eingeschränkte Kerberos-Delegierung, jeweils mit eigenen Nachteilen. Rückgängig machen: Disable-PSRemoting -Force und Clear-Item WSMan:\localhost\Client\TrustedHosts entfernen, was in Schritt 2–3 hinzugefügt wurde; falls andere Automatisierungen davon abhängen, vorher den bestehenden TrustedHosts-Wert mit (Get-Item WSMan:\localhost\Client\TrustedHosts).Value sichern. Für keinen dieser Schritte ist ein Neustart nötig; damit Änderungen an $PSSessionConfigurationName wirksam werden, ist eine neue PowerShell-Sitzung erforderlich.