PowerShell Remoting (PSRemoting) ist eine der meistverwendeten Funktionen in PowerShell. Warum? Weil es so verdammt nützlich ist! Mit einem einzigen Befehl können Sie nahtlos eine Verbindung zu einem oder Tausenden von Remote-Computern herstellen und Befehle ausführen.
In diesem ultimativen Leitfaden werden Sie tief in PSRemoting eintauchen. Sie erfahren, was es ist, wie es funktioniert und alle verschiedenen Technologien, die PSRemoting zum Laufen bringen. Dieser Leitfaden wird nicht erklären, wie man PSRemoting verwendet. Sie werden jedoch viele Verweise auf unsere Anleitungen finden.
Wie PSRemoting funktioniert
Kurz gesagt ermöglicht Ihnen PSRemoting, Befehle auf Remote-Computern auszuführen, als ob Sie direkt davor sitzen würden. PSRemoting bietet Funktionen zum Herstellen einer Verbindung und Authentifizierung eines Benutzers, zum Ausführen von Remote-Befehlen und zum Zurückgeben aller Ausgaben dieses Befehls an den lokalen Computer.
Stellen Sie sich PSRemoting wie Telnet oder SSH oder sogar psexec vor. Es ist einfach eine Möglichkeit, Befehle auf Computern innerhalb von PowerShell auszuführen.
PSRemoting basiert stark auf einem Konzept namens Sitzung. Eine Sitzung ist ein Begriff, der eine Remote-Shell beschreibt, in der Befehle ausgeführt werden. Der Prozess zur Erstellung einer solchen Sitzung durchläuft viele Schritte im Hintergrund.
Wenn Sie eine PSRemoting-Sitzung initiieren, werden grob gesagt die folgenden Schritte ausgeführt:
- Der Client versucht, eine Verbindung zum Zielserver über einen WinRM-Listener herzustellen (mehr zu WinRM-Listenern weiter unten). Ein WinRM-Listener ist ein kleiner Webdienst, der auf dem Zielserver ausgeführt wird. WinRM ist Microsofts Implementierung eines Standards namens WSMan. WSMan ist ein offener Standard, der damals zusammen mit vielen anderen großen Technologieunternehmen wie Dell, Intel und Sun Microsystems entwickelt wurde.
- Wenn der Client über das HTTP- oder HTTPS-Protokoll eine Verbindung zum Listener herstellt, beginnt der Authentifizierungsprozess. Alle Einzelheiten zu den einzelnen Authentifizierungsmethoden werden später behandelt, aber vorerst solltest du wissen, dass der Client dem Server auf irgendeine Weise Anmeldeinformationen übermitteln muss.
- Nachdem der Client eine Verbindung hergestellt und sich beim Server authentifiziert hat, erstellt PSRemoting eine Sitzung.
- Sobald die PSRemoting-Sitzung erstellt wurde, ist sie bereit. Zu diesem Zeitpunkt kann der Client Informationen an den Server senden und der Server kann alle erforderlichen Ausgaben, die als Serialisierung bezeichnet werden, zurückgeben. Diese Kommunikation erfolgt in der Regel verschlüsselt.
WinRM-Listener: Verbindungsmöglichkeiten
A client needs somewhere to connect to when coming in from over the network. The client needs to “talk” to something that’s “listening” on the other side; that “listening” is the role of the WinRM listener.
Mit dem unten stehenden Befehl winrm können Sie alle WinRM-Listener auf einem beliebigen Windows-Computer entdecken.
WinRM-Listener haben einige wichtige Komponenten. Sie enthalten:
- A listening address – The listening address is the IP address that they bind to. This is the IP address that a client connects to.
- Der Typ des Transports – Jeder WinRM-Listener benötigt eine Möglichkeit zur Kommunikation mit dem Client. Dies geschieht über einen Transport mittels HTTP oder HTTPS.
- Ein optionaler Zertifikat-Thumbprint – Wenn ein WinRM-Listener HTTPS für den Transport verwendet, muss er wissen, welchen privaten Schlüssel er zur Authentifizierung des Clients verwenden soll. Dieser Schlüssel wird über einen Zertifikat-Thumbprint gefunden.
Verwenden Sie einen HTTPS-Listener, wenn möglich. Die Einrichtung des HTTPS-Transports erhöht die Sicherheit, indem die Gültigkeit des Servers sichergestellt und sowohl die Authentifizierung als auch der Transportverkehr verschlüsselt werden. Bei der Ausstellung eines Zertifikats verwenden Sie nach Möglichkeit ein vertrauenswürdiges Zertifikat einer Zertifizierungsstelle anstelle eines selbstsignierten Zertifikats.
Vertrauenswürdige Hosts: Überprüfung eines Servers
Wie die PSRemoting-Authentifizierung über WinRM funktioniert
Wie oben erwähnt, ist Authentifizierung einer der ersten Schritte, die PSRemoting durchläuft. Die Authentifizierung ist einer der kompliziertesten, aber auch wichtigsten Teile von PSRemoting.
Als PSRemoting eingeführt wurde, hatte es zunächst nur einen Authentifizierungsmechanismus, nämlich Windows Remote Management (WinRM). Heutzutage können Sie jedoch auch mit SSH authentifizieren, wie Sie später sehen werden.
WinRM unterstützt zwei verschiedene Arten der Authentifizierung: Benutzername und Passwort oder ein Zertifikat mit verschiedenen Arten der Authentifizierung für eine Benutzername/Passwort-Kombination.
Basische Authentifizierung
Beginnend mit der einfachsten, aber unsichersten Art der Authentifizierung handelt es sich um die Basic-Authentifizierung. Diese Art der Authentifizierung ist in das HTTP-Protokoll integriert. Die Basic-Authentifizierung sendet eine base64-kodierte Kopie des Benutzernamens und des Passworts im HTTP-Header vom Client an den Listener.
Da die Basic-Authentifizierung nur den Benutzernamen und das Passwort kodiert und nicht verschlüsselt, ist es einfach, die Anmeldeinformationen im Netzwerk abzufangen.
Verwenden Sie die Basic-Authentifizierung nur, wenn es unbedingt erforderlich ist. Es gibt viele andere sicherere Methoden, mit denen WinRM sich authentifizieren kann!
Kerberos-Authentifizierung
Befinden sich Ihr Client und Ihr Server in einer Active Directory-Umgebung? Wenn ja, verwenden Sie bereits für viele Ihrer Netzwerkdienste die Kerberos-Authentifizierung.
Wenn der WinRM-Client versucht, eine Verbindung mit einem WinRM-Listener über Kerberos herzustellen:
- Versucht der Server zunächst, einen Sitzungsschlüssel oder ein Ticket-Granting-Ticket für den Client von einem Domänencontroller abzurufen.
- Der Domänencontroller sucht den Client und den Server, und wenn beide gültig und vertrauenswürdig sind, stellt er das Token aus.
- Der Server validiert dann die Verbindung des Clients mithilfe des vertrauenswürdigen Tokens anstelle von Benutzername und Passwort.
Während der Kerberos-Authentifizierung validiert der Domänencontroller sowohl den Client als auch den Server während der Schritte zum Abrufen des Tickets, um zu verhindern, dass jemand Böswilliges den Server imitiert.
Kerberos ist eine ausgereifte und sichere Authentifizierungsmethode und ist der Standardauthentifizierungstyp, wenn ein Client und ein Server beide Mitglieder einer Active Directory-Domäne sind. Es erfordert jedoch, dass sowohl der Client als auch der Server der gleichen Active Directory-Forest angehören oder dass eine Vertrauensstellung zwischen den Forests eingerichtet ist.
Negotiate Authentication
WinRm kann auch versuchen, Kerberos zu verwenden und bei Nichtverfügbarkeit auf ein Authentifizierungsprotokoll namens NT Lan Manager (NTLM) zurückgreifen.
Bei Verwendung von NTLM:
- Der Server sendet dem Client eine Zeichenkette.
- Der Client verschlüsselt dann die Zeichenkette mit einem Hash des Benutzerpassworts.
- Die verschlüsselte Zeichenkette wird dann an den Server zurückgesendet, der den Benutzernamen, die ursprüngliche Zeichenkette und die verschlüsselte Zeichenkette an einen Domänencontroller sendet.
- Der Domänencontroller sucht dann den Passworthash für diesen Benutzer und wiederholt den gleichen Verschlüsselungsprozess mit der Zeichenkette, um sicherzustellen, dass er übereinstimmt.
NTLM ist gut zur Validierung des Clients, aber im Gegensatz zu Kerberos validiert es nicht den Server. Dies öffnet mehrere Angriffsmöglichkeiten, bei denen der Server von einem Angreifer imitiert werden könnte.
Sie können die Sicherheit von NTLM verbessern, indem Sie den Server auch mit einem Server-Authentifizierungszertifikat validieren und es einem HTTPS WinRM-Listener zuweisen. In dieser Konfiguration wird der Client mit NTLM gegen den Domänencontroller authentifiziert und der Server mit einem vertrauenswürdigen Zertifikat authentifiziert. Obwohl diese Konfiguration sowohl die Client- als auch die Serverauthentifizierung ermöglicht, verwendet das NLTM-Protokoll eine ältere Verschlüsselungsmethode mit einer veralteten Schlüsselgröße.
Aus diesen Gründen ist NTLM nur verwendbar, wenn Sie den Server zur Liste der vertrauenswürdigen Hosts hinzufügen oder einen HTTPS-Listener verwenden.
Digest-Authentifizierung
Eine der ungewöhnlichsten Authentifizierungsmethoden für WinRM ist die Digest-Authentifizierung. NTLM und Digest sind ähnliche Authentifizierungsmethoden. Ähnlich wie NTLM erzeugt Digest eine eindeutige Zeichenfolge, die mit dem Hash des Benutzerpassworts verschlüsselt wird. Das Passwort muss dann nicht an den Server gesendet werden.
Digest verwendet den MD5-Hashing-Algorithmus zur Verschlüsselung des Passworts. Aufgrund dieser Algorithmuswahl wird Digest im Allgemeinen als veraltet angesehen und sollte nicht verwendet werden. MD5 weist verschiedene bekannte Schwachstellen auf, die es für kryptografische Zwecke ungeeignet machen.
Credential Security Support Provider (CredSSP)
Obwohl wir uns mit den Einzelheiten von CredSSP beschäftigen könnten, ist es nicht notwendig. Warum? Weil es bei PSRemoting und WinRM in der Regel nur aus einem Grund implementiert wird: dem „Zweiten-Hop-Problem“, das Sie unten kennenlernen werden.
Wenn die CredSSP-Authentifizierung konfiguriert ist, verwenden sowohl der WinRM-Client als auch der Server die Verhandlungsauthentifizierung, um sowohl den Benutzer als auch den Client zu authentifizieren. Sobald dies abgeschlossen ist, wird das Benutzerpasswort an den Server gesendet.
Da das Passwort nach Abschluss des Authentifizierungsprozesses gesendet wird, ist es nun verschlüsselt. CredSSP verschlüsselt das Passwort auch mit den TLS-Sitzungsschlüsseln , so dass der verschlüsselte String zwischen Sitzungen eindeutig ist.
CredSSP ist nützlich, weil der Server nach der Authentifizierung dann in der Lage ist, sich für Sie mit allem anderen zu verbinden. Wenn dies jedoch geschieht, vertrauen Sie dem Server, mit dem Sie sich mit dem Benutzerpasswort verbunden haben, vollständig.
Zertifikatbasierte Authentifizierung
Die sicherste Methode zur Authentifizierung bei PSRemoting ist möglicherweise die zertifikatbasierte Authentifizierung. Bei dieser Methode findet ein typischer Schlüsselaustausch mit einem privaten und öffentlichen Schlüssel auf dem Client und einem Server zur Validierung des Zertifikats statt.
WinRM authentifiziert den Benutzer, indem es einen Benutzer auf dem Server in WinRM abbildet. Während des Authentifizierungsprozesses wird nur der öffentliche Schlüssel übermittelt, daher handelt es sich um eine sehr sichere Authentifizierungsmethode.
Obwohl die zertifikatbasierte Authentifizierung die sicherste Methode ist, ist sie nicht allzu verbreitet. Warum? Einfach aufgrund des Aufwands, der für die Einrichtung erforderlich ist. Sie müssen folgende Schritte durchführen:
- Eine Zertifizierungsstelle erstellen
- Ein Benutzerauthentifizierungszertifikat erstellen
- Den öffentlichen Schlüssel teilen
- Einen lokalen Benutzeraccount mit entsprechenden Berechtigungen verwenden (wahrscheinlich Administratorengruppe)
- Einen HTTPS-Listener einrichten
- …und andere Schritte durchführen.
Sie können keinen Domänenbenutzer zur Authentifizierung mit Zertifikaten verwenden, auch wenn der Client und der Server beide Teil von Active Directory sind.
Standardauthentifizierungseinstellungen für Windows-Betriebssysteme
Nun, da Sie gesehen haben, dass es viele verschiedene Authentifizierungsoptionen gibt, die standardmäßig verfügbar sind, wie wissen Sie, welche verfügbar sind? In der folgenden Tabelle sehen Sie zwei Spalten, die anzeigen, ob der WinRM-Client standardmäßig aktiviert ist und ob dieser bestimmte Authentifizierungstyp standardmäßig aktiviert ist.
All diese genannten Authentifizierungstypen sind konfigurierbar, aber die Verwendung der folgenden Tabelle gibt Ihnen eine gute Vorstellung davon, was Sie selbst konfigurieren müssen.
| Method | Client | Service |
| Basic | Enabled | Disabled |
| Kerberos | Enabled | Enabled |
| Negotiate | Enabled | Enabled |
| CredSSP | Disabled | Disabled |
| Digest | Enabled | Disabled |
| Certificate | Enabled | Disabled |
Das Problem des zweiten Sprungs oder des Doppelhops
Ein großes Problem bei PSRemoting ist das sogenannte „Problem des zweiten Sprungs“ oder „Doppelhops“. Diese Situation tritt auf, wenn Sie eine Verbindung zu einem entfernten System über PSRemoting herstellen und dann eine Verbindung zu einem anderen entfernten Computer herstellen müssen.
Dies ist problematisch, weil der WinRm-Client beim Authentifizieren am ersten entfernten Computer nur die Identität des ursprünglichen Clients überprüft, ohne das Passwort an den Server zu senden. Wenn Sie versuchen, vom Server der ersten Verbindung aus eine Verbindung zum zweiten Computer herzustellen, hat der endgültige Server keine Möglichkeit, die Identität des Benutzers zu überprüfen.
Sie können das Doppelhop-Problem auf verschiedene Arten lösen, entweder durch Verwendung von CredSSP oder Kerberos-Delegation.
Verwendung von CredSSP
Die häufigste Methode, um das Doppelhop-Problem zu umgehen, besteht darin, CredSSP zu verwenden. Die CredSSP-Authentifizierung umgeht diese Situation, indem sie eine Benutzeranmeldeinformation auf dem ersten entfernten Server speichert, die vom Server als Client an den zweiten entfernten Server weitergegeben werden kann.
Es gibt jedoch einen Haken bei der Verwendung von CredSSP. Die Benutzeranmeldeinformationen, die auf dem ersten entfernten Server gespeichert sind, können im Klartext gespeichert werden, was offensichtlich ein Sicherheitsrisiko darstellt. In neueren Betriebssystemen wird ein Hash des Passworts und des Kerberos-Ticket Granting Ticket (TGT) verwendet. Diese können zusammen verwendet werden, um sich überall im Netzwerk als Benutzer zu authentifizieren, ähnlich wie ein Klartext-Passwort, aber das Risiko wird dadurch etwas verringert.
Mit der Verhandlungsfunktion tauschen der Client und der Server Informationen aus, um ihre Identität zu bestätigen, aber das Benutzerpasswort ist niemals zugänglich. Aufgrund dieses Sicherheitsmerkmals kann der erste Server Sie nicht authentifizieren, wenn Sie sich mit dem zweiten Server verbinden.
Verwendung von Kerberos-Delegation
Wie bereits erwähnt, ist Kerberos eine gängige Methode zur Einrichtung von PSRemoting. Da es Teil des allgegenwärtigen Active Directory ist und standardmäßig eingerichtet ist, ist es äußerst verbreitet. Obwohl Kerberos an sich eine gute Möglichkeit ist, WinRM zu authentifizieren, umgeht es nicht das Problem des doppelten Hops.
Um das Problem des doppelten Hops zu umgehen, können Sie eine zweite Art der Authentifizierung namens Kerberos-Delegation verwenden. Obwohl es viele Arten von Kerberos-Delegation gibt, ist die einzige Variante, die in der Lage ist (und sicher genug ist), als Alternative zu CredSSP zu dienen, Kerberos Constrained Delegation, genauer gesagt die ressourcenbasierte eingeschränkte Kerberos-Delegation.
Die ressourcenbasierte eingeschränkte Kerberos-Delegation ist eine Form der Delegierung von Kerberos-Authentifizierungstokens, die auf Domänenressourcen wie Computern basiert und in diesem Fall auf eine spezifische Liste von Kerberos (Active Directory)-Objekten beschränkt ist.
Um diese Kerberos-Delegation zu konfigurieren, müssen Sie das ADComputer-Objekt des dritten Computers in der Kette bearbeiten. Wenn Sie zum Beispiel von ClientA zu ServerB zu ServerC fernsteuern möchten, müssen Sie das ADComputer-Objekt für ServerC bearbeiten, aber Sie müssen auch wissen, was ServerB sein wird. Führen Sie für dieses Beispiel den folgenden Befehl in PowerShell aus:
Die Verwendung der auf Ressourcen basierenden Kerberos-Delegation funktioniert für Remote-Verbindungen wie … oder …, aber sie funktioniert nicht mit PSRemoting. Sie können keine Verbindung zu einem dritten Computer herstellen, wenn Sie über WinRM mit PSRemoting mit einem Computer verbunden sind.
Die Einrichtung der auf Ressourcen basierenden eingeschränkten Kerberos-Delegation ist ein PowerShell-Befehl in einer Zeile mit dem Befehl Set-ADComputer. Wenn Sie zum Beispiel über PSRemoting von ServerB von ClientA verbunden sind und eine Verbindung zu ServerC mit … herstellen möchten, können Sie dies durch Ausführen des folgenden PowerShell-Befehls tun.
WinRm speichert fehlgeschlagene Verbindungen für 15 Minuten. Aufgrund dieses Features können Sie möglicherweise auch nach Einrichtung der auf Ressourcen basierenden eingeschränkten Kerberos-Delegation keine Verbindung zum dritten Computer herstellen. Um dies zu beheben, warten Sie entweder oder führen Sie den Befehl
klist purge -LI 0x3e7auf dem dritten Computer aus, um die fehlgeschlagenen Kerberos-Token zu löschen.
Wie die PSRemoting-Authentifizierung über SSH funktioniert
Obwohl die WinRm-Authentifizierung die häufigste Methode zur Authentifizierung für PSRemoting ist, haben Sie ab PowerShell v6 eine weitere Möglichkeit: SSH. Die Verwendung von SSH als Authentifizierungsmethode ermöglicht die Verwendung von PSRemoting mit Linux.
Im Gegensatz zu WinRm erfordert SSH einige zusätzliche Konfigurationen sowohl auf dem Client als auch auf dem Server, wie z.B. die Einrichtung eines SSH-Clients auf dem Windows-Client und …
Die Verwendung von SSH zur Authentifizierung bedeutet, dass Sie auf die von SSH unterstützten Authentifizierungstypen beschränkt sind. Dies schränkt die Liste auf die beiden Haupttypen Passwort-basiert und Public-Key-basiert ein.
Es gibt weitere von SSH unterstützte Authentifizierungstypen, aber sie gelten in der Regel als weniger sicher als die Passwort- und Public-Key-basierten Optionen, daher werden wir uns nur auf diese beiden konzentrieren.
Passwort-Authentifizierung
Der einfachste Weg, die SSH-Authentifizierung mit PSRemoting einzurichten, ist die passwortbasierte Authentifizierung. Die passwortbasierte Authentifizierung ermöglicht es Ihnen, ein Passwort zur Validierung anzugeben.
Im SSH-Authentifizierungsprozess wird das Passwort nach Herstellung der SSH-Verbindung ausgetauscht und das Passwort während der Übertragung verschlüsselt. Im Gegensatz zu einigen von WinRM verwendeten Authentifizierungsmethoden wie Kerberos wird das gesamte Passwort bei dieser Authentifizierungsmethode an den Server gesendet.
Man könnte die SSH-Passwortauthentifizierung mit der WinRM-Authentifizierungsmethode Basic über einen HTTPS-Listener vergleichen. Das Passwort selbst ist nicht auf sinnvolle Weise geschützt, jedoch wird die gesamte Verbindung, einschließlich des Passworts, verschlüsselt und der Server anhand eines Zertifikats validiert.
Zertifikatsbasierte Authentifizierung
Obwohl die passwortbasierte Authentifizierung einfach einzurichten und einfach zu verwenden ist, hat sie zwei Probleme.
- Erstens gibt es keine Möglichkeit, sich in einem unbeaufsichtigten Modus sicher zu authentifizieren.
- Die Passwortauthentifizierung sendet immer noch ein Passwort über das Netzwerk. Obwohl das Passwort innerhalb der SSH-Verbindung verschlüsselt ist, erhält der Server das gesamte Passwort. Wenn der Server auf irgendeine Weise kompromittiert ist, könnte dies zu einem Sicherheitsproblem führen.
Die zertifikatsbasierte Authentifizierung sendet hingegen keine sensiblen Daten wie das Passwort über das Netzwerk. Stattdessen hat der Server eine Kopie eines öffentlichen Schlüssels, der Client hat eine Kopie des privaten Schlüssels und die Verhandlungen finden auf dem Server statt.
A rough workflow goes as follows:
- Wenn der Client versucht, sich zu authentifizieren, sendet er die ID oder den Fingerabdruck des öffentlichen Schlüssels an den Server.
- Wenn der Server den öffentlichen Schlüssel als autorisiert führt, antwortet er mit einer mit dem öffentlichen Schlüssel verschlüsselten Zeichenkette.
- Der Client entschlüsselt die Zeichenkette dann mit dem privaten Schlüssel.
- Der private Schlüssel wird dann mit einer Sitzungs-ID gehasht.
- Die Sitzungs-ID wird an den Server zurückgesendet, der sie dann mit dem Hash vergleicht, der mit dem ursprünglichen String und der Sitzungs-ID generiert wurde.
- Wenn der Sitzungs-ID-Hash des Clients und die Sitzungs-ID auf dem Server übereinstimmen, authentifiziert sich der Client und darf eine Verbindung herstellen.
Alles, was mit dem öffentlichen Schlüssel verschlüsselt wird, kann nur mit einem zugehörigen privaten Schlüssel entschlüsselt werden. Alles, was mit dem privaten Schlüssel verschlüsselt wird, kann nur mit dem öffentlichen Schlüssel entschlüsselt werden. Die Sitzungs-ID wird ebenfalls verwendet, um das zu bieten, was als Perfect Forward Secrecy (PFS) bezeichnet wird.
PFS bietet Sicherheit, wenn der private Schlüssel kompromittiert ist. Der Angreifer wäre nicht in der Lage, alle Nachrichten zu entschlüsseln, die hin und her gegangen sind. Eine eindeutige Sitzungs-ID bedeutet, dass das gemeinsame Geheimnis, das zur Verschlüsselung der Kommunikation verwendet wird, für jede Sitzung unterschiedlich ist.
Zertifikatsbasierte Authentifizierung mit SSH erfordert zusätzlichen Aufwand bei der Einrichtung, wie das Generieren des privaten/öffentlichen Schlüsselpaars und die Autorisierung des öffentlichen Schlüssels auf dem Remote-Server.
Berechtigungen des Benutzers, um eine Verbindung herzustellen
Standardmäßig können zwei lokale Benutzergruppen über PSRemoting eine Verbindung zu einem Server herstellen: Administratoren und Remote Management-Benutzer.
Während Sie Benutzerkonten einfach zur lokalen Administratorengruppe auf einem Remote-Server hinzufügen können, sollten Sie immer den geringstmöglichen Zugriff gewähren. Wenn ein Benutzer lediglich eine Verbindung mit PSRemoting zu einem Remote-Computer herstellen muss, kann das Benutzerkonto zur Remote Management-Benutzer-Gruppe hinzugefügt werden, nicht zur Administratoren-Gruppe.
Um den Zugriff auf PSRemoting weiter zu steuern, können Sie auch eine Funktion namens Just Enough Administration (JEA) verwenden. JEA ermöglicht Nicht-Administrator-Benutzern, nur bestimmte Befehle als Administratoren im eingeschränkten Sprachmodus von PowerShell auszuführen.
Implizites vs. „Explizites“ Remoting
Wenn Sie zuvor PSRemoting verwendet haben, sind Ihnen wahrscheinlich Befehle wie Invoke-Command, New-PSSession, Enter-PSSession usw. bekannt. Wenn Sie diese Befehle ausführen, ist deutlich erkennbar, dass Sie auf irgendeine Weise eine Verbindung zu einem Remote-Computer herstellen. Sie verwenden PSRemoting explizit.
Wenn Sie PSRemoting-spezifische Befehle ausführen, führen Sie diese Befehle explizit aus. Wussten Sie jedoch, dass es noch eine andere Möglichkeit gibt? Anstatt Invoke-Command und andere Cmdlets direkt aufzurufen, können Sie PSRemoting nutzen, indem Sie implizites PSRemoting verwenden.
Implizites PSRemoting bedeutet, dass die Befehle scheinbar lokal in deiner PowerShell-Sitzung ausgeführt werden, sie werden aber tatsächlich auf einer entfernten Maschine ausgeführt. Ein gutes Beispiel hierfür ist die Verwendung eines Moduls, das nicht auf deinem System installiert ist. Anstatt es lokal zu installieren, kannst du Befehle aus einer PSSession exportieren, um sie so auszuführen, als wären sie lokal installiert.
Auf dem folgenden Screenshot ist zu sehen, dass ich den Befehl Test-PendingReboot nicht habe. Dann habe ich mich mit einer entfernten Maschine verbunden und diesen Befehl exportiert.
Wenn das Modul dann importiert ist, kann ich den Befehl Test-PendingReboot ausführen. Dies wird unten gezeigt, allerdings wirst du bemerken, dass der Computernamen in der Ausgabe nicht der Name des Geräts ist, von dem PowerShell ausgeführt wird, sondern das Gerät, von dem der Befehl importiert wurde.
