PowerShell Remoting über HTTPS mit einem selbstsignierten SSL-Zertifikat

Um zu überprüfen, wie Ihre Maschinen konfiguriert sind, können Sie diesen Befehl ausführen:

winrm get winrm/config

Alternativ liefert PowerShell das gleiche Ergebnis:

dir WSMan:\localhost\Service | ? Name -eq AllowUnencrypted

bzw. für den Client mit

dir WSMan:\localhost\Client | ? Name -eq AllowUnencrypted

Zusätzlicher Schutz für Workgroup-Umgebungen

Das zweite und meiner Meinung nach größere Problem ist, dass Sie keine Vertrauens­beziehung zu den entfernten Computern haben, wenn Sie mit Maschinen arbeiten, die sich nicht in einer Active Directory-Domäne befinden.

Es greift dann nur noch die symmetrische Ver­schlüsselung von WSMan, so dass Man-in-the-Middle-Angriffe theoretisch möglich sind, da zuerst der Schlüssel übertragen werden muss.

An dieser Stelle kommt PowerShell Remoting via SSL ins Spiel. Zum einen ist der HTTPS-Verkehr immer verschlüsselt, und da SSL eine asymmetrische Ver­schlüsselung und Zertifikate verwendet, können Sie sicher sein, dass Sie mit Ihrem Remote-Computer verbunden sind und nicht mit dem eines Angreifers.

Auf der anderen Seite ist die Konfiguration von PowerShell Remoting für die Verwendung mit SSL etwas schwieriger, weil man dafür mehr tun muss als bloß Enable-PSRemoting auszuführen. Das Hauptproblem ist, dass Sie ein SSL-Zertifikat benötigen.

Wenn Sie nur einige eigen­ständige Server oder Work­stations verwalten möchten, werden Sie wahr­scheinlich kein öffentlich signiertes Zertifikat erwerben und stattdessen mit einem selbst­signierten Zertifikat arbeiten.

HTTPS auf dem Remote-Computer aktivieren

Das erste, was wir tun müssen, ist, ein SSL-Zertifikat zu erstellen. Diese Anleitung konzentriert sich auf die Verwendung eines selbstsignierten Zertifikats. Wenn Sie ein öffentlich signiertes Zertifikat haben, ist die Sache einfacher und Sie können dafür

Set-WSManQuickConfig -UseSSL

verwenden.

Seit PowerShell 4 brauchen wir für das Ausstellen eines selbstsignierten Zertifikats keine Tools von Drittanbietern mehr, das Cmdlet New-SelfSignedCertificate übernimmt seitdem diese Aufgabe.

$Cert = New-SelfSignedCertificate -CertstoreLocation Cert:\LocalMachine\My -DnsName "myHost"

Es ist wichtig, den Namen des Computers, den Sie remote verwalten möchten, an den Parameter DnsName zu übergeben. Wenn der Computer einen DNS-Namen hat, sollten Sie den voll qualifizierten Domänennamen (FQDN) verwenden.

Falls Sie möchten, können Sie mit der überprüfen, ob das Zertifikat korrekt gespeichert wurde. Fügen Sie dort das Snap-In Zertifikate für ein Computerkonto und dann den lokalen Computer hinzu. Das Zertifikat sollte sich im Ordner Eigene Zertifikate\Zertifikate befinden.

Wir müssen das Zertifikat nun in eine Datei exportieren, damit wir es später auf unserem lokalen Rechner importieren können. Das lässt sich auch mit dem MMC-Snap-In erledigen, aber wir werden dazu PowerShell verwenden:

Export-Certificate -Cert $Cert -FilePath C:\temp\cert

Wir benötigen das Zertifikat, um den HTTPS Listener von WS-Management zu starten. Aber zuerst sollten wir PowerShell Remoting auf dem Host aktivieren:

Enable-PSRemoting -SkipNetworkProfileCheck -Force

SkipNetworkProfileCheck stellt sicher, dass PowerShell sich nicht beschwert, wenn Ihr Netz­werk­verbindungs­typ auf Öffentlich gesetzt ist.

Enable-PSRemoting startet auch einen WS-Management-Listener, allerdings nur für HTTP. Wenn Sie möchten, können Sie dies überprüfen, indem Sie den Inhalt des WSMan-Laufwerks lesen:

dir wsman:\localhost\listener

Um sicherzustellen, dass niemand HTTP zur Verbindung mit dem Computer verwendet, können Sie den HTTP-Listener auf diese Weise entfernen:

dir WSMan:\Localhost\listener | where Keys -eq "Transport=HTTP" |`
Remove-Item -Recurse

Als nächstes fügen wir unseren HTTPS-Listener hinzu:

New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * `
-CertificateThumbPrint $Cert.Thumbprint -Force

Wir verwenden die Variable $Cert, die wir zuvor definiert haben, um den Thumbprint zu lesen. Er ermöglicht dem Cmdlet New-Item, das Zertifikat in unserem Speicher zu finden.

Das Letzte, was wir tun müssen, ist, die Firewall auf dem Host zu konfigurieren, da das Cmdlet Enable-PSRemoting nur Regeln für HTTP hinzugefügt hat:

New-NetFirewallRule -DisplayName "Windows Remote Management (HTTPS-In)" -Name "Windows Remote Management (HTTPS-In)" -Profile Any -LocalPort 5986 -Protocol TCP

Beachten Sie hier, dass wir eingehenden Datenverkehr auf Port 5986 erlauben. WinRM 1.1 (aktuell ist 3.0) verwendet noch den allgemeinen HTTPS-Port 443. Sie können diesen weiterhin nutzen, wenn sich der Host hinter einer Gateway-Firewall befindet, die den Port 5986 blockiert:

Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpsListener -Value true

Natürlich müssen Sie dann den Port 443 in der Windows Firewall öffnen. Beachten Sie, dass dieser Befehl nicht funktioniert, wenn der Netzwerk­verbindungs­typ auf Öffentlich eingestellt ist. In diesem Fall müssen Sie den Verbindungstyp auf privat ändern:

Set-NetConnectionProfile -NetworkCategory Private

Aus Sicherheits­gründen sollten Sie die Firewall-Regel für HTTP deaktivieren, die von Enable-PSRemoting hinzugefügt wurde:

Disable-NetFirewallRule -DisplayName "Windows Remote Management (HTTP-In)"

Unser entfernter Rechner ist nun bereit für PowerShell Remoting über HTTPS, und wir können den lokalen Computer konfigurieren.

HTTPS auf dem lokalen Computer aktivieren

Die Dinge sind hier etwas einfacher. Zuerst müssen Sie die zuvor erstellte Zertifikats­datei auf den lokalen PC kopieren. Mit diesem Befehl können Sie dann das Zertifikat importieren:

Import-Certificate -Filepath "C:\temp\cert" -CertStoreLocation "Cert:\LocalMachine\Root"

Beachten Sie, dass wir das Zertifikat hier im Ordner Vertrauens­würdige Stamm­zertifizierungs­stellen speichern müssen und nicht im Ordner Eigene Zertifikate, wie wir es auf dem Remote-Computer getan haben.

Ihr Computer vertraut allen Maschinen, die ihre Authentizität mit Hilfe ihrer privaten Schlüssel (die auf dem Host gespeichert sind) und der hier gespeicherten Zertifikate nachweisen können.

Wir müssen den entfernten Rechner nun nicht zur Liste der TrustedHosts hinzufügen. Im Gegensatz zu PowerShell Remoting über HTTP können wir sicher sein, dass der Remote-Computer derjenige ist, der er vorgibt zu sein. Das ist der Hauptgrund dafür, HTTPS anstelle von HTTP zu verwenden.

Sitzung über HTTPS starten

Wir sind nun bereit, eine PowerShell-Sitzung auf dem Remote-Computer über HTTPS zu öffnen:

Enter-PSSession -ComputerName myHost -UseSSL -Credential (Get-Credential)

Der entscheidende Parameter hier ist UseSSL. Natürlich müssen wir uns noch auf dem entfernten Rechner mit einem Administrator­konto authentifizieren.

Auch das Cmdlet Invoke-Command unterstützt den Parameter UseSSL:

Invoke-Command -ComputerName myHost -UseSSL -ScriptBlock {Get-Process} -Credential (Get-Credential)

Fazit

Zugegeben, der Beitrag wurde etwas länger als geplant. Sobald Sie jedoch wissen, wie es funktioniert, können Sie den gesamten Vorgang zur Konfiguration von PowerShell Remoting über HTTPS in wenigen Minuten abschließen.

Sie erstellen einfach ein selbst­signiertes SSL-Zertifikat auf dem Host und starten mit diesem Zertifikat einen HTTPS-Listener. Anschließend erstellen Sie die entsprechende Firewall-Regel und exportieren das Zertifikat. Auf dem lokalen Computer müssen Sie nur das Zertifikat importieren.

HTTPS fügt nicht nur eine weitere Ver­schlüsselungs­ebene hinzu, sondern dient vor allem dazu, die Authentizität des entfernten Rechners zu überprüfen und so Man-in-the-Middle-Angriffe zu verhindern.

Daher benötigen Sie HTTPS nur, wenn Sie PowerShell Remoting über ein unsicheres Netzwerk durch­führen. Innerhalb Ihres lokalen Netzwerks, mit Vertrauens­beziehungen zwischen Mit­gliedern einer Active Directory-Domäne, ist WSMan über HTTP sicher genug.