Sicherheitsfeatures von Live Share

Zusammenarbeitssitzungen in Visual Studio Live Share sind leistungsfähig, da sie eine beliebige Anzahl von Personen ermöglichen, an einer Sitzung teilzunehmen und gemeinsam zu bearbeiten, zu debuggen und mehr. Angesichts dieser Zugriffsebene interessieren Sie sich jedoch zweifellos für die Sicherheitsfeatures Live Share. In diesem Artikel werden einige Empfehlungen und Optionen für die Sicherung Ihrer Umgebung bei Bedarf bereitgestellt.

Denken Sie wie bei jedem Tool für die Zusammenarbeit daran, dass Sie Ihren Code, Ihre Inhalte und Anwendungen nur für Personen freigeben sollten, denen Sie vertrauen.

Konnektivität

Beim Initiieren einer Sitzung zwischen Peers versucht Live Share, eine Peer-zu-Peer-Verbindung herzustellen, und nur, wenn dies nicht möglich ist (z. B. aufgrund von Firewalls/NATs), fällt sie auf die Verwendung eines Cloudrelays zurück. In beiden Verbindungstypen (P2P oder Relay) werden jedoch alle zwischen Peers übertragenen Daten mit dem SSH-Protokoll end-to-End verschlüsselt. Im Falle einer Relayverbindung wird die SSH-Verschlüsselung über TLS-verschlüsselten WebSockets überlagert. Dies bedeutet, dass Live Share nicht vom Cloudrelaydienst für die Sicherheit abhängt. Selbst wenn das Relay kompromittiert wurde, konnte es keine der Live-Freigabe-Kommunikation entschlüsseln.

Die Rolle des Live-Freigabediensts ist auf die Benutzerauthentifizierung und sitzungsermittlung beschränkt. Der Dienst selbst speichert oder hat keinen Zugriff auf den Inhalt einer Sitzung. Alle Benutzerinhalte in Live Share werden über die SSH-Sitzung übertragen. Dazu gehören Code, Terminals, gemeinsam genutzte Server und alle anderen Features für die Zusammenarbeit, die von Live Share oder Erweiterungen bereitgestellt werden, die darauf aufbauen.

Weitere Informationen zum Ändern dieser Verhaltensweisen und der Konnektivitätsanforderungen von Live Share finden Sie unter Konnektivitätsanforderungen für Live Share.

Drahtverschlüsselung

Das SSH-Protokoll verwendet einen Diffie-Hellman-Schlüsselaustausch, um einen freigegebenen Geheimschlüssel für die Sitzung herzustellen und leitet von diesem schlüssel für die AES symmetrische Verschlüsselung ab. Der Verschlüsselungsschlüssel wird in regelmäßigen Abständen während der Dauer der Sitzung gedreht. Der freigegebene Sitzungsschlüssel und alle Verschlüsselungsschlüssel werden nur von beiden Seiten im Arbeitsspeicher verwaltet und sind nur für die Dauer der Sitzung gültig. Sie werden niemals auf den Datenträger geschrieben oder an einen Beliebigen Dienst (einschließlich Live-Freigabe) gesendet.

Peerauthentifizierung

Die SSH-Sitzung ist auch bidirektionale Authentifizierung. Der Host (SSH-Serverrolle) verwendet die öffentliche/private Schlüsselauthentifizierung wie für das SSH-Protokoll standard. Wenn ein Host eine Live-Freigabesitzung freigibt, generiert er ein eindeutiges öffentliches/privates RSA-Schlüsselpaar für die Sitzung. Der private Hostschlüssel wird nur im Speicher des Hostprozesses gespeichert. sie wird niemals auf den Datenträger geschrieben oder an einen Beliebigen Dienst gesendet, einschließlich des Live-Freigabediensts. Der öffentliche Hostschlüssel wird zusammen mit den Sitzungsverbindungsinformationen (IP-Adresse und/oder Relayendpunkt) im Live Share-Dienst veröffentlicht, auf den Gäste über den Einladungslink darauf zugreifen können. Wenn ein Gast eine Verbindung mit der SSH-Sitzung des Hosts herstellt, verwendet der Gast das SSH-Hostauthentifizierungsprotokoll, um zu überprüfen, ob der Host den privaten Schlüssel enthält, der dem veröffentlichten öffentlichen Schlüssel entspricht (ohne dass der Gast tatsächlich zum Anzeigen des privaten Schlüssels gelangt).

Der Gast verwendet ein Live-Freigabetoken, um sich beim Host zu authentifizieren. Das Token ist ein signiertes JWT, das vom Live Share-Dienst ausgestellt wurde, der Ansprüche über die Benutzeridentität enthält (abgerufen über MSA, AAD oder GitHub-Anmeldung). Das Token verfügt auch über Ansprüche, die angeben, dass der Gast auf diese bestimmte Live-Freigabesitzung zugreifen darf (da sie den Einladungslink hatten und/oder sie speziell vom Host eingeladen wurden). Der Host überprüft dieses Token und überprüft die Ansprüche (und abhängig von den Optionen kann den Hostbenutzer auffordern), bevor der Gast an der Sitzung teilnehmen kann.

Einladungen und Teilnehmen am Zugriff

Jedes Mal, wenn Sie eine neue Zusammenarbeitssitzung starten, generiert Live Share einen neuen eindeutigen Bezeichner , der im Einladungslink platziert wird. Diese Links bieten eine solide, sichere Grundlage, um diese einzuladen, die Sie als vertrauenswürdig einstufen, da der Bezeichner im Link "nicht erraten" ist und nur für die Dauer einer einzelnen Zusammenarbeitssitzung gültig ist.

Entfernen eines unerwarteten Gasts

Als Host werden Sie automatisch benachrichtigt, wenn ein Gast der Zusammenarbeitssitzung beitritt.

In Visual Studio Code:

In Visual Studio:

Besser noch, die Benachrichtigung bietet Ihnen die Möglichkeit, einen Gast zu entfernen, der beigetreten ist, wenn Sie sie aus irgendeinem Grund nicht kennen. (Wenn Sie ihren Link beispielsweise versehentlich auf einem unternehmensweiten Chatsystem und einem zufälligen Mitarbeiter gepostet haben.) Klicken Sie einfach in der angezeigten Benachrichtigung auf die Schaltfläche "Entfernen", und sie werden aus der Zusammenarbeitssitzung ausgeworfen.

Auch wenn Sie eine Teilnahmebenachrichtigung geschlossen haben, haben Sie in VS Code auch die Möglichkeit, einen Teilnehmer danach zu entfernen. Durch Öffnen der Livefreigabeansicht im Explorer oder der benutzerdefinierten Registerkarte in der VS Code-Aktivitätsleiste können Sie mit der Maus auf den Namen eines Teilnehmers zeigen oder mit der rechten Maustaste auf den Namen eines Teilnehmers klicken und das Symbol oder die Option "Teilnehmer entfernen" auswählen.

Anfordern der Gastgenehmigung

In der Regel werden Teilnehmer, die einer Zusammenarbeitssitzung beitreten, mit einem Microsoft-Geschäfts-, Schul- oder Unikonto (AAD), persönlichem Microsoft-Konto oder GitHub-Konto bei Live Share angemeldet. Während die Standardeinstellung "Benachrichtigung + Entfernen" für angemeldete Benutzer eine gute Mischung aus Geschwindigkeit und Kontrolle für diese Gäste bietet, sollten Sie dinge etwas mehr sperren, wenn Sie etwas sensibler machen.

Außerdem kann es problematisch sein, unter bestimmten Umständen zu erzwingen, dass sich alle Gäste anmelden, um an einer Zusammenarbeitssitzung teilzunehmen. Beispiele hierfür sind die Aufforderung, jemanden mit Live Share als Gast, Kursraum-/Lernszenarien oder bei der Zusammenarbeit mit jemandem zu bitten, der nicht über einen der unterstützten Kontotypen verfügt. Aus diesen Gründen kann Live Share Benutzern erlauben, die nicht angemeldet sind, an Zusammenarbeitssitzungen als schreibgeschützte Gäste teilzunehmen. Während der Gastgeber diese Gäste genehmigen muss, bevor sie standardmäßig beitreten können, möchten Sie diese "anonymen" Gäste möglicherweise nicht zulassen oder stattdessen immer genehmigen.

Anfordern der Gastgenehmigung für angemeldete Benutzer

Wenn Sie verhindern möchten, dass angemeldete Gäste an Ihren Zusammenarbeitssitzungen teilnehmen, bis Sie sie genehmigt haben, ändern Sie die folgende Einstellung:

• Fügen Sie in VS Code folgendes zu settings.json hinzu (Dateieinstellungen >> ):

  "liveshare.guestApprovalRequired": true
  

• Legen Sie in Visual Studio "Extras > Options > Live Share > " "Require guest approval" auf True fest.

  

Ab diesem Zeitpunkt werden Sie aufgefordert, jeden Gast zu genehmigen, der beitritt.

In Visual Studio Code:

In Visual Studio:

Wenn Sie als Gast an einer Sitzung teilnehmen, in der der Host diese Einstellung aktiviert hat, werden Sie in der Statusleiste oder im Dialogfeld "Teilnehmen" benachrichtigt, dass Live-Freigabe auf dem Host auf die Genehmigung wartet.

Automatisches Ablehnen oder Akzeptieren von Benutzern, die nicht angemeldet sind (anonym)

Wie oben beschrieben, kann Live-Freigabe so konfiguriert werden, dass Benutzer, die nicht angemeldet sind, als schreibgeschützte Gäste an einer Zusammenarbeitssitzung teilnehmen können. Während diese "anonymen" Gäste beim Beitritt einen Namen eingeben müssen, bietet ein einfacher Name nicht die gleiche Zuverlässigkeitsebene wie eine echte Anmeldung. Daher wird der Host standardmäßig aufgefordert, anonyme Gäste unabhängig von der oben beschriebenen Einstellung "Gastgenehmigung erforderlich" zu genehmigen.

Sie können anonyme Gäste jederzeit ablehnen (deaktivieren) oder anonyme Benutzer stattdessen wie folgt akzeptieren:

• Legen Sie liveshare.anonymousGuestApproval in VS Code nach Bedarf in "settings.json" (Dateieinstellungen >>) auf accept, rejectoder prompt (standard) fest.

• Legen Sie in Visual Studio die Tools-Optionen >> "LiveFreigabe > "Anonyme Gastgenehmigung" auf "Annehmen", "Ablehnen" oder "Eingabeaufforderung" (Standardeinstellung) fest.

Denken Sie unabhängig davon daran, dass Sie nur Livefreigabe-Einladungslinks an Personen senden sollten, denen Sie vertrauen.

Zulassen des Gastbefehlssteuerelements

Um Gästen das Ausführen beliebiger Befehle über Codeaktionen ("Quick Fixes") zu ermöglichen, und CodeLens legen Sie die folgende Einstellung fest:

• Legen Sie liveshare.languages.allowGuestCommandControl in VS Code in settings.json (Dateieinstellungen >>) auf true oder false (Standardeinstellung) fest.

Steuern des Dateizugriffs und der Sichtbarkeit

Als Gast bietet Ihnen das Remotemodell von Live Share schnellen Lese-/Schreibzugriff auf Dateien und Ordner, die der Host für Sie freigegeben hat, ohne den gesamten Inhalt eines Projekts synchronisieren zu müssen. Sie können daher unabhängig voneinander in der gesamten freigegebenen Dateistruktur navigieren und Dateien bearbeiten. Diese Freiheit birgt jedoch einige Risiken für den Host. Im Konzept könnte sich ein Entwickler dafür entscheiden, Quellcode ohne Ihr Wissen einzugeben und zu ändern oder vertrauliche Quellcode oder geheime Schlüssel an einer beliebigen Stelle in der freigegebenen Dateistruktur anzuzeigen. Daher möchten Sie als Host möglicherweise nicht immer, dass der Gast Zugriff auf die gesamte Anzahl eines Projekts hat, das Sie freigeben. Glücklicherweise ist ein zusätzlicher Vorteil dieses Remotemodells, dass Sie sich für "ausschließen" Dateien entscheiden können, die Sie nicht für alle freigeben möchten, ohne auf Funktionalität verzichten zu müssen. Ihre Gäste können weiterhin an Dingen wie Debuggingsitzungen teilnehmen, die normalerweise Zugriff auf diese Dateien erfordern, wenn sie dies selbst tun möchten.

Sie können dies erreichen, indem Sie dem Ordner oder Projekt, den Sie freigeben, eine VSLS.JSON-Datei hinzufügen. Alle Einstellungen, die Sie zu dieser json-formatierten Datei hinzufügen, ändert die Art und Weise, wie Live Share Dateien verarbeitet. Zusätzlich zur direkten Kontrolle können diese Dateien auch zur Quellcodeverwaltung verpflichtet werden, sodass jeder, der ein Projekt klont, diese Regeln ohne zusätzlichen Aufwand nutzen kann.

Hier ist eine Beispieldatei ".vsls.json":

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"none",
    "excludeFiles":[
        "*.p12",
        "*.cer",
        "token",
        ".gitignore"
    ],
    "hideFiles": [
        "bin",
        "obj"
    ]
}

Hinweis

Sie können auch alle Dateien/Ordner erstellen, die Sie schreibgeschützt freigeben, wenn Sie eine Zusammenarbeitssitzung starten. Einzelheiten dazu finden Sie weiter unten.

Sehen wir uns an, wie diese Eigenschaften ändern, was Gäste tun können.

Eigenschaften

Mit der excludeFiles-Eigenschaft können Sie eine Liste von Glob-Dateimustern (sehr ähnlich wie die gefundenen GITIGNORE-Dateien) angeben, die verhindern, dass Live Share bestimmte Dateien oder Ordner für Gäste öffnet. Beachten Sie, dass dies szenarien wie ein Gast folgt oder zu Ihrem Bearbeitungsspeicherort springt, während des gemeinsamen Debuggens zu einer Datei wechselt, alle Codenavigationsfeatures wie Definition und vieles mehr. Sie ist für Dateien vorgesehen, die Sie niemals unter beliebigen Umständen freigeben möchten, wie z. B. geheime Schlüssel, Zertifikate oder Kennwörter. Da sie beispielsweise die Sicherheit steuern, werden .vsls.json-Dateien immer ausgeschlossen.

Die hideFiles-Eigenschaft ist ähnlich, aber nicht ganz so streng. Diese Dateien werden einfach aus der Dateistruktur ausgeblendet. Wenn Sie beispielsweise beim Debuggen zu einer dieser Dateien gelangen, wird sie weiterhin im Editor geöffnet. Diese Eigenschaft ist in erster Linie nützlich, wenn Sie nicht über ein GITIGnore-Dateisetup verfügen (wie es der Fall wäre, wenn Sie ein anderes Quellcodeverwaltungssystem verwenden) oder wenn Sie einfach erweitern möchten, was bereits vorhanden ist, um Unübersichtlichkeit oder Verwirrung zu vermeiden.

Die Gitignore-Einstellung legt fest, wie Live Share den Inhalt von GITIGnore-Dateien in freigegebenen Ordnern verarbeiten soll. Standardmäßig werden alle In gitignore-Dateien gefundenen Globs so behandelt, als würden sie in der Eigenschaft "hideFiles" angegeben. Sie können jedoch ein anderes Verhalten auswählen, indem Sie einen der folgenden Werte verwenden:

Option	Ergebnis
none	Gitignore-Inhalte sind für Gäste in der Dateistruktur sichtbar (vorausgesetzt, sie werden nicht nach einer Gast-Editor-Einstellung gefiltert).
hide	Der Standardwert. Globs innerhalb von gitignore werden so verarbeitet, als wären sie in der Eigenschaft "hideFiles" enthalten.
exclude	Globs in gitignore werden so verarbeitet, als wären sie in der Eigenschaft "excludeFiles" enthalten.

Ein Nachteil der exclude Einstellung ist, dass der Inhalt von Ordnern wie node_modules häufig in GITIGnore enthalten ist, aber nützlich sein kann, während des Debuggens zu gehen. Folglich unterstützt Live Share die Möglichkeit, eine Regel mithilfe von "!" in der excludeFiles-Eigenschaft rückgängig zu machen. Diese VSLS.json-Datei würde z. B. alles in ".gitignore" mit Ausnahme von node_modules ausschließen:

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"exclude",
    "excludeFiles":[
        "!node_modules"
    ]
}

Die Regeln zum Ausblenden und Ausschließen werden separat verarbeitet. Wenn Sie also weiterhin node_modules ausblenden möchten, um die Unübersichtlichkeit zu reduzieren, ohne sie tatsächlich auszuschließen, können Sie die Datei einfach wie folgt bearbeiten:

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"exclude",
    "excludeFiles":[
        "!node_modules"
    ],
    "hideFiles":[
        "node_modules"
    ]
}

.vsls.json-Dateien in Unterordnern

Schließlich können .vsls.json-Dateien wie .gitignore in Unterordnern platziert werden. Hide/exclude rules are determined by starting with the .vsls.json file in the root folder you have shared (if present) and then walking through at each sub-folder from there from there leading to a given file to look for .vsls.json files to process. Der Inhalt von .vsls.json-Dateien in Ordnern weiter unten in der Dateistruktur, und ergänzen (oder überschreiben) Regeln, die auf höheren Ebenen festgelegt wurden.

Hinweis: Es ist nicht möglich, (!) eine Datei erneut einzuschließen, wenn ein übergeordnetes Verzeichnis dieser Datei ausgeschlossen ist. Ähnlich wie gitignore müssen Sie, wenn Sie eine Datei erneut einschließen, auch jedes übergeordnete Verzeichnis der Datei erneut einschließen.

Deaktivieren der externen Dateifreigabe

Standardmäßig gibt Live Share auch alle Dateien frei, die der Host öffnet, die sich außerhalb des freigegebenen Ordners/der Freigegebenen Lösung befinden. Dies erleichtert das schnelle Öffnen anderer verwandter Dateien, ohne erneut freigeben zu müssen.

Wenn Sie dieses Feature lieber deaktivieren möchten:

• Fügen Sie in VS Code folgendes zu settings.json hinzu:

  "liveshare.shareExternalFiles": false
  

• Legen Sie in Visual Studio "Extras > Options > Live Share "Externe Dateien freigeben > " auf "False" fest.

Schreibgeschützter Modus

Manchmal möchten Sie, wenn Sie Ihren Code als Host freigeben, ihre Gäste keine Bearbeitungen vornehmen. Möglicherweise benötigen Sie Ihren Gast, um einen Blick auf einen Teil Ihres Codes zu werfen, oder Sie zeigen Ihr Projekt einer großen Anzahl von Gästen an und möchten nicht, dass unnötige oder versehentliche Bearbeitungen vorgenommen werden. Live-Freigabe bietet die Möglichkeit, Projekte im schreibgeschützten Modus freizugeben.

Als Host haben Sie beim Freigeben die Möglichkeit, den schreibgeschützten Modus für eine Zusammenarbeitssitzung zu aktivieren. Wenn ein Gast beitritt, können sie den Code nicht bearbeiten, sie können jedoch die Cursor und Hervorhebungen der anderen Weiterhin sehen und durch das Projekt navigieren.

Sie können weiterhin mit Gästen im schreibgeschützten Modus debuggen. Gäste haben nicht die Möglichkeit, den Debugprozess zu durchlaufen, können aber trotzdem Haltepunkte hinzufügen oder entfernen und Variablen überprüfen. Darüber hinaus können Sie Server und Terminals (schreibgeschützt) weiterhin für Gäste freigeben.

Weitere Informationen zum Starten einer schreibgeschützten Zusammenarbeitssitzung finden Sie unter:

Gemeinsames Debuggen

Wenn Sie schwierige Codierungsprobleme oder Fehler angehen, können Sie ein zusätzliches Augenpaar haben, wenn das Debuggen wirklich nützlich sein kann. Visual Studio Live Share ermöglicht das "gemeinsame Debuggen" oder "Gemeinsames Debuggen", indem die Debugsitzung für alle Gäste freigegeben wird, wenn der Host das Debuggen startet.

Als Host haben Sie die vollständige Kontrolle darüber, wann eine Debugsitzung gestartet oder beendet wird, aber das Co-Debugging stellt einige Risiken dar, wenn Sie mit jemandem teilen, dem Sie nicht vertrauen.As a host, you are in complete control over when a debug session starts or stops, but co-debugging does some risk if you are sharing with someone you do not trust. Live Share ermöglicht Gästen, die Sie einladen, Konsolen-/REPL-Befehle auszuführen, und daher besteht das Risiko, dass ein böswilliger Akteur einen Befehl ausführt, den Sie nicht ausführen möchten.

Daher sollten Sie nur mit denen, denen Sie vertrauen, kodebuggt werden.

Weitere Informationen:

Freigeben eines lokalen Servers

Beim gemeinsamen Debuggen kann es sehr hilfreich sein, Zugriff auf verschiedene Teile der Anwendung zu erhalten, die den Gästen vom Gastgeber für die Debugsitzung „serviert“ werden. Vielleicht möchten Sie auf die App in einem Browser zugreifen, auf eine lokale Datenbank zugreifen oder über Ihre Tools einen REST-Endpunkt erreichen. Mit der Livefreigabe können Sie "einen Server freigeben", der einem lokalen Port auf dem Computer des Hosts genau denselben Port auf dem Computer des Gasts zuordnet. Als Gast können Sie dann genau mit der Anwendung interagieren, als ob sie lokal auf Ihrem Computer ausgeführt wurde (z. B. der Host und der Gast können auf eine Web-App zugreifen, die auf ihrem Computer ausgeführt wird. http://localhost:3000).

Als Host sollten Sie jedoch mit den Ports, die Sie für Gäste freigeben , sehr selektiv sein und nur Anwendungsports anstelle von Systemports freigeben. Für Gäste verhalten sich freigegebene Ports so, als würde der Server oder Dienst auf dem lokalen Gastcomputer ausgeführt werden. Dies ist zwar sehr nützlich, kann aber auch riskant sein, wenn der falsche Port freigegeben wird. Aus diesem Grund macht Live Share keine Annahmen darüber, was ohne Konfigurationseinstellung freigegeben werden soll oder nicht freigegeben werden soll, und der Host führt eine Aktion aus.

In Visual Studio wird der in ASP.NET Projekten angegebene Webanwendungsport während des Debuggens automatisch freigegeben, um den Gastzugriff auf die Web-App beim Ausführen zu erleichtern. Sie können diese Automatisierung jedoch deaktivieren, indem Sie bei Bedarf tools > Options > Live Share > "Share Web App on debug" auf "False" festlegen.

In Visual Studio Code versucht Live Share, die richtigen Anwendungsports zu erkennen und freizugeben. Sie können dies jedoch deaktivieren, indem Sie folgendes zu settings.json hinzufügen:

"liveshare.autoShareServers": false

In beiden Fällen müssen Sie beim Freigeben zusätzlicher Ports sorgfalt walten.

Weitere Informationen zum Konfigurieren des Features finden Sie hier:

Freigeben eines Terminals

Die moderne Entwicklung nutzt oft eine Vielzahl von Befehlszeilentools. Glücklicherweise ermöglicht Live Share es Ihnen als Gastgeber, für Gäste optional „ein Terminal freizugeben“. Das freigegebene Terminal kann schreibgeschützt oder vollständig für die Zusammenarbeit eingerichtet sein, damit Sie und Ihre Gäste Befehle ausführen und die Ergebnisse anzeigen können. Als Host können Sie anderen Mitarbeitern erlauben, entweder nur die Ausgabe anzuzeigen oder eine beliebige Anzahl von Befehlszeilentools zum Ausführen von Tests, Builds oder sogar zu triagen umgebungsspezifischen Problemen zu verwenden.

Nur Hosts können gemeinsam genutzte Terminals starten, um zu verhindern, dass Gäste eins starten und etwas tun, das Sie nicht erwarten oder beobachten. Wenn Sie ein freigegebenes Terminal als Host starten, können Sie angeben, ob es schreibgeschützt oder schreibgeschützt sein soll. Im zweiten Fall kann jede Person einschließlich des Gastgebers Befehle im Terminal eingeben. Dadurch können unerwünschte Gastaktionen leicht unterbunden werden. Die Lese- und Schreibberechtigungen sollten Sie aus Sicherheitsgründen ausschließlich Gästen bereitstellen, die darauf angewiesen sind. Terminals mit Leseberechtigungen sollten Sie in Szenarios einsetzen, in denen Gäste nur die Ausgabe der von Ihnen ausgeführten Befehle sehen dürfen.

In Visual Studio werden Terminals standardmäßig nicht freigegeben. In VS Code werden Terminals standardmäßig automatisch schreibgeschützt freigegeben. Sie können dies jedoch deaktivieren, indem Sie folgendes zu settings.json hinzufügen:

"liveshare.autoShareTerminals": false

Weitere Informationen:

AAD-Administratorzustimmung

Wenn Sie sich mit einer von Microsoft gesicherten E-Mail-Adresse für Geschäfts-, Schul- oder Unikonten anmelden, wird möglicherweise eine Meldung mit der Meldung "Administratorgenehmigung benötigen" angezeigt, wenn Sie sich anmelden. Dies liegt daran, dass Live Share Lesezugriff auf Benutzerinformationen für seine Sicherheitsfeatures erfordert, und Ihr Azure AD-Mandant ist so eingerichtet, dass "Administratorzustimmung" für neue Anwendungen erforderlich ist, die auf den Inhalt des Verzeichnisses zugreifen.

Ihr AD-Administrator muss dies für Sie mithilfe der folgenden Informationen beheben:

• Anwendungsname: Visual Studio Live Share (Insider)
• Anwendungstyp: Web App
• Anwendungsstatus: Produktion
• Delegierte Berechtigungen: User.Read
• Anwendungs-URL: https://visualstudio.microsoft.com/services/live-share/
• Antwort-URL: https://insiders.liveshare.vsengsaas.visualstudio.com/auth/redirect/windowslive/

Dies wäre nur einmal erforderlich, damit jeder, der Live-Freigabe verwendet, verwendet wird. Weitere Informationen finden Sie hier und hier .

Siehe auch

• Installieren von und Anmelden bei Live Share in Visual Studio Code
• Installieren von und Anmelden bei Live Share in Visual Studio
• Anforderungen an die Konnektivität für Live Share

Gibt es Probleme? Lesen Sie Troubleshooting oder Feedback geben.