Sicherheitsfeatures von Live Share

Zusammenarbeitssitzungen in Visual Studio Live Share sind leistungsstark, da beliebig viele Personen an einer Sitzung teilnehmen und gemeinsam Bearbeitungen vornehmen, debuggen und weitere Aktionen ausführen können. Angesichts dieser Zugriffsmöglichkeiten interessieren Sie sich jedoch bestimmt für die Sicherheitsfeatures von Live Share. In diesem Artikel geben wir einige Empfehlungen und stellen Optionen für die Sicherung Ihrer Umgebung nach Bedarf vor.

Wie bei jedem Tool für die Zusammenarbeit gilt: Sie sollten Ihren Code, Ihre Inhalte und Anwendungen nur für Personen freigeben, denen Sie vertrauen.

Konnektivität

Wenn eine Sitzung zwischen Peers initiiert wird, versucht Live Share, eine Peer-to-Peer-Verbindung herzustellen. Nur wenn dies nicht möglich ist (z. B. aufgrund von Firewalls/NATs), wird auf ein Cloudrelay zurückgegriffen. Bei 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 setzt die SSH-Verschlüsselung auf TLS-verschlüsselten WebSockets auf. Somit ist Live Share in Bezug auf Sicherheit nicht vom Cloudrelaydienst abhängig. Selbst bei einer Kompromittierung könnte das Relay die Live Share-Kommunikation nicht entschlüsseln.

Die Rolle des Live Share-Diensts ist auf die Benutzerauthentifizierung und Sitzungsermittlung beschränkt. Der Dienst selbst speichert den Inhalt einer Sitzung nicht und hat auch keinen Zugriff darauf. 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 darauf aufbauenden Erweiterungen bereitgestellt werden.

Weitere Informationen zum Ändern dieser Verhaltensweisen und zu den Konnektivitätsanforderungen von Live Share finden Sie unter Anforderungen an die Konnektivität für Live Share.

Verbindungsverschlüsselung

Das SSH-Protokoll verwendet einen Diffie-Hellman-Schlüsselaustausch, um ein freigegebenes Geheimnis für die Sitzung festzulegen, und leitet davon einen Schlüssel für die symmetrische AES-Verschlüsselung ab. Der Verschlüsselungsschlüssel rotiert regelmäßig während der Dauer der Sitzung. Das freigegebene Sitzungsgeheimnis und alle Verschlüsselungsschlüssel werden von beiden Seiten nur im Arbeitsspeicher gehalten und sind nur für die Dauer der Sitzung gültig. Sie werden niemals auf Datenträger geschrieben oder an einen Dienst gesendet (auch nicht an Live Share).

Peerauthentifizierung

Für die SSH-Sitzung erfolgt auch eine bidirektionale Authentifizierung. Der Host (SSH-Serverrolle) verwendet die Authentifizierung mit öffentlichem/privatem Schlüssel, wie es für das SSH-Protokoll Standard ist. Wenn ein Host eine Live Share-Sitzung freigibt, generiert er ein eindeutiges RSA-Schlüsselpaar mit öffentlichem/privatem Schlüssel für die Sitzung. Der private Schlüssel des Hosts wird nur im Speicher des Hostprozesses gespeichert; er wird niemals auf Datenträger geschrieben oder an einen Dienst gesendet, auch nicht an den Live Share-Dienst. Der öffentliche Hostschlüssel wird zusammen mit den Sitzungsverbindungsinformationen (IP-Adresse und/oder Relayendpunkt) im Live Share-Dienst veröffentlicht. Dort können Gäste über den Einladungslink darauf zugreifen. Beim Herstellen einer Verbindung zur SSH-Sitzung des Hosts verwendet der Gast das SSH-Hostauthentifizierungsprotokoll, um zu überprüfen, ob der Host den dem veröffentlichen öffentlichen Schlüssel entsprechenden privaten Schlüssel enthält (ohne dass der Gast den privaten Schlüssel zu sehen bekommt).

Der Gast verwendet ein Live Share-Token für die Authentifizierung beim Host. Das Token ist ein signiertes JWT, das vom Live Share-Dienst ausgestellt wurde und Angaben zur Benutzeridentität enthält (abgerufen über MSA-, AAD- oder GitHub-Anmeldung). Das Token enthält auch Angaben, die besagen, dass der Gast auf diese bestimmte Live Share-Sitzung zugreifen darf (da er den Einladungslink hatte und/oder speziell vom Host eingeladen wurde). Der Host validiert dieses Token und prüft die Angaben (und kann abhängig von den Optionen den Hostbenutzer dazu auffordern), bevor er den Gast an der Sitzung teilnehmen lässt.

Einladungen und Teilnahmezugang

Jedes Mal, wenn Sie eine neue Zusammenarbeitssitzung starten, generiert Live Share einen neuen eindeutigen Bezeichner, der in den Einladungslink eingefügt wird. Diese Links bieten eine solide, sichere Grundlage für die Einladung von Personen, denen Sie vertrauen, da der Bezeichner in dem Link nicht erraten werden kann 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:

Die Benachrichtigung gibt Ihnen sogar die Möglichkeit, einen beigetretenen Gast zu entfernen, wenn Sie ihn aus irgendeinem Grund nicht kennen. (Wenn Sie Ihren Link beispielsweise versehentlich in einem unternehmensweiten Chatsystem veröffentlicht haben und ein Mitarbeiter zufällig beigetreten ist.) Klicken Sie einfach in der Benachrichtigung auf die Schaltfläche „Entfernen“, und die betreffende Person wird aus der Zusammenarbeitssitzung ausgeschlossen.

In VS Code haben Sie auch dann noch die Möglichkeit, einen Teilnehmer zu entfernen, wenn Sie eine Beitrittsbenachrichtigung abgelehnt haben. Wenn Sie die Live Share-Ansicht im Explorer oder die benutzerdefinierte Registerkarte in der VS Code-Aktivitätsleiste öffnen, können Sie den Mauszeiger auf den Namen eines Teilnehmers bewegen oder mit der rechten Maustaste auf den Namen eines Teilnehmers klicken und das Symbol oder die Option zum Entfernen eines Teilnehmers auswählen.

Anfordern einer Gastgenehmigung

In der Regel werden Teilnehmer, die einer Zusammenarbeitssitzung beitreten, mit einem Microsoft-Geschäfts-, -Schul- oder -Unikonto (AAD), einem persönlichen Microsoft-Konto oder einem GitHub-Konto bei Live Share angemeldet. Während die Standardeinstellung „Notification + remove“ (Benachrichtigung + Entfernen) für angemeldete Benutzer bei diesen Gästen eine gute Mischung aus Schnelligkeit und Kontrolle bietet, sollten Sie in einem vertraulicheren Kontext möglicherweise mehr Sicherheit bieten.

Außerdem kann es unter bestimmten Umständen problematisch sein, die Anmeldung aller Gäste zu erzwingen, die an einer Zusammenarbeitssitzung teilnehmen möchten. Beispiele hierfür sind die Aufforderung an eine Person, die neu bei Live Share ist, als Gast beizutreten, Kursraum-/Lernszenarien oder die Zusammenarbeit mit einer Person, die nicht über einen der unterstützten Kontotypen verfügt. Aus diesen Gründen kann Live Share Benutzern, die nicht angemeldet sind, den Beitritt zu Zusammenarbeitssitzungen als Gäste nur mit Lesezugriff ermöglichen. Zwar muss der Host diese Gäste genehmigen, bevor sie standardmäßig beitreten können, Sie können diese „anonymen“ Gäste jedoch unterbinden oder immer zulassen.

Anfordern einer 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 (Datei > Einstellungen > Einstellungen):

  "liveshare.guestApprovalRequired": true
  

• Legen Sie in Visual Studio für Extras > Optionen > Live Share > „Gastgenehmigung erforderlich“ True fest.

  

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

In Visual Studio Code:

In Visual Studio:

Wenn Sie als Gast an einer Sitzung teilnehmen, bei der der Host diese Einstellung aktiviert hat, werden Sie in der Statusleiste oder im Dialogfeld „Beitreten“ benachrichtigt, dass Live Share auf die Genehmigung durch den Host wartet.

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

Wie oben beschrieben, kann Live Share so konfiguriert werden, dass Benutzer, die nicht angemeldet sind, als Gäste nur mit Lesezugriff an einer Zusammenarbeitssitzung teilnehmen können. Zwar müssen diese „anonymen“ Gäste einen Namen eingeben, wenn sie der Sitzung beitreten, ein einfacher Name bietet jedoch nicht dasselbe Maß an Sicherheit wie eine richtige Anmeldung. Daher wird der Host standardmäßig aufgefordert, anonyme Gäste zu genehmigen, unabhängig von der oben beschriebenen Einstellung „Gastgenehmigung erforderlich“.

Sie können anonyme Gäste immer ablehnen (deaktivieren) oder immer akzeptieren, indem Sie wie folgt vor gehen:

• Legen Sie in VS Code für liveshare.anonymousGuestApproval in der Datei „settings.json“ (Datei > Einstellungen > Einstellungen) nach Bedarf accept, reject oder prompt (Standardwert) fest.

• Legen Sie in Visual Studio für Extras > Optionen > Live Share > „Genehmigung anonymer Gäste“ nach Bedarf „Akzeptieren“, „Ablehnen“ oder „Prompt“ (Standardwert) fest.

Denken Sie stets daran, dass Sie nur Live Share-Einladungslinks an Personen senden sollten, denen Sie vertrauen.

Zulassen der Gastbefehlssteuerung

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

• Legen Sie in VS Code für liveshare.languages.allowGuestCommandControl in der Datei „settings.json“ (Datei > Einstellungen > Einstellungen) true oder false (Standardeinstellung) fest.

Kontrolle 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 in der gesamten freigegebenen Dateistruktur navigieren und Dateien bearbeiten. Diese flexible Möglichkeit birgt jedoch einige Risiken für den Host. Im Prinzip könnte ein Entwickler Quellcode ohne Ihr Wissen ändern oder vertraulichen Quellcode oder „Geheimnisse“ irgendwo in der freigegebenen Dateistruktur einsehen. Daher möchten Sie als Host möglicherweise nicht immer, dass der Gast Zugriff auf das gesamte Projekt hat, das Sie freigeben. Glücklicherweise haben Sie bei diesem Remotemodell die Möglichkeit, Dateien „auszuschließen“, die Sie für niemanden freigeben möchten, ohne dass dies zulasten der Funktionalität geht. Ihre Gäste können weiterhin beispielsweise an Debugsitzungen teilnehmen, die normalerweise Zugriff auf diese Dateien erfordern würden, wenn sie dies selbst tun wollten.

Sie können dies erreichen, indem Sie dem Ordner oder Projekt, den/das Sie freigeben, eine Datei .vsls.json hinzufügen. Alle Einstellungen, die Sie dieser JSON-formatierten Datei hinzufügen, ändern die Art und Weise, wie Live Share Dateien verarbeitet. Diese Dateien ermöglichen Ihnen nicht nur eine direkte Kontrolle, sondern können auch der Quellcodeverwaltung übergeben werden, sodass jeder, der ein Projekt klont, diese Regeln ohne zusätzlichen Aufwand nutzen kann.

Hier sehen Sie 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, die Sie freigeben, schreibschützen, wenn Sie eine Zusammenarbeitssitzung starten. Einzelheiten dazu finden Sie weiter unten.

Sehen wir uns einmal an, wie diese Eigenschaften die Möglichkeiten für die Gäste ändern.

Eigenschaften

Mit der Eigenschaft excludeFiles können Sie eine Liste von Glob-Dateimustern (ähnlich wie bei .gitignore-Dateien) angeben, die verhindert, dass Live Share bestimmte Dateien oder Ordner für Gäste öffnet. Beachten Sie, dass dies Szenarien wie einen Gast, der Ihnen zu Ihrer Bearbeitungsposition folgt oder zu dieser springt, die schrittweise Ausführung einer Datei während des gemeinsamen Debuggens, alle Codenavigationsfeatures wie „Gehe zu Definition“ und vieles mehr umfasst. Dies ist für Dateien vorgesehen, die Sie unter keinen Umständen freigeben möchten, wie z. B. Dateien mit Geheimnissen, Zertifikaten oder Kennwörtern. Da sie die Sicherheit kontrollieren, sind Dateien „.vsls.json“ beispielsweise immer ausgeschlossen.

Die Eigenschaft hideFiles ist ähnlich, aber nicht ganz so strikt. Diese Dateien werden einfach aus der Dateistruktur ausgeblendet. Wenn Sie beispielsweise beim Debuggen zufällig zu einer dieser Dateien gelangen, wird sie weiterhin im Editor geöffnet. Diese Eigenschaft ist vor allem hilfreich, wenn Sie keine .gitignore-Datei eingerichtet haben (wie es der Fall wäre, wenn Sie ein anderes Quellcodeverwaltungssystem verwenden würden) oder wenn Sie einfach das bereits Vorhandene ergänzen möchten, um ein Durcheinander oder Verwirrung zu vermeiden.

Die Einstellung gitignore 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ären 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 durch eine Einstellung des Gasteditors gefiltert).
hide	Der Standardwert. Globs innerhalb von .gitignore werden so verarbeitet, als wären sie in der Eigenschaft „hideFiles“ enthalten.
exclude	Globs innerhalb von .gitignore werden so verarbeitet, als wären sie in der Eigenschaft „excludeFiles“ enthalten.

Ein Nachteil der Einstellung exclude ist, dass der Inhalt von Ordnern wie node_modules häufig in .gitignore enthalten ist, es jedoch hilfreich sein kann, während des Debuggens darauf zurückzugreifen. Folglich unterstützt Live Share die Möglichkeit, eine Regel mithilfe von „!“ in der Eigenschaft „excludeFiles“ umzukehren. Diese Datei „.vsls.json“ würde beispielsweise 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 node_modules zur Verbesserung der Übersichtlichkeit weiterhin ausblenden möchten, ohne es 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"
    ]
}

Dateien „.vsls.json“ in Unterordnern

Schließlich können Dateien „.vsls.json“ wie .gitignore in Unterordnern platziert werden. Die Regeln für das Ausblenden/Ausschließen werden bestimmt, indem mit der Datei „.vsls.json“ im Stammordner begonnen wird, den Sie freigegeben haben (sofern vorhanden), und dann von dort aus die einzelnen Unterordner durchgegangen werden, die zu einer bestimmten Datei führen, um nach zu verarbeitenden Dateien „.vsls.json“ zu suchen. Der Inhalt der Dateien „.vsls.json“ in weiter unten in der Dateistruktur befindlichen Ordnern ergänzt (oder überschreibt) dann die auf höheren Ebenen festgelegten Regeln.

Hinweis: Es ist nicht möglich, eine Datei erneut einzuschließen (!), wenn ein übergeordnetes Verzeichnis dieser Datei ausgeschlossen ist. Ähnlich wie bei .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 und die sich außerhalb des freigegebenen Ordners/der freigegebenen Lösung befinden. Auf diese Weise können andere zugehörige Dateien schnell geöffnet werden, ohne erneut freigegeben werden zu müssen.

Gehen Sie wie folgt vor, 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 für Extras > Optionen > Live Share > „Externe Dateien freigeben“ den Wert „False“ fest.

Schreibgeschützter Modus

Wenn Sie als Host Ihren Code freigeben, möchten Sie manchmal nicht, dass Ihre Gäste Bearbeitungen vornehmen. Möglicherweise soll Ihr Gast einen Blick auf einen Teil Ihres Codes werfen, oder Sie zeigen Ihr Projekt zahlreichen Gästen und möchten nicht, dass unnötige oder versehentliche Bearbeitungen vorgenommen werden. Live Share bietet die Möglichkeit, Projekte im schreibgeschützten Modus freizugeben.

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

Im schreibgeschützten Modus können Sie weiterhin gemeinsam mit Gästen debuggen. Gäste können den Debugprozess zwar nicht schrittweise durchlaufen, aber dennoch 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

Beim Debugging von schwierigen Codierungsproblemen oder Fehlern kann es sehr hilfreich sein, dass sich eine weitere Person dies anschaut. Visual Studio Live Share ermöglicht ein „gemeinsames Debuggen“, indem die Debugsitzung für alle Gäste freigegeben wird, wenn der Host mit dem Debuggen beginnt.

Als Host haben Sie die vollständige Kontrolle darüber, wann eine Debugsitzung beginnt oder endet, das gemeinsame Debugging birgt jedoch einige Risiken bei einer Freigabe für eine Person, der Sie nicht vertrauen. Live Share bietet den von Ihnen eingeladenen Gästen die Möglichkeit, Konsolen-/REPL-Befehle auszuführen. Daher besteht die Gefahr, dass ein böswilliger Akteur einen Befehl ausführt, den er nicht ausführen soll.

Folglich sollten Sie nur mit Personen gemeinsam debuggen, denen Sie vertrauen.

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. Live Share ermöglicht Ihnen die „Freigabe eines Servers“, wodurch ein lokaler Port auf dem Computer des Hosts genau demselben Port auf dem Computer des Gasts zugeordnet wird. Als Gast können Sie dann mit der Anwendung genauso interagieren, als wenn sie auf Ihrem Computer lokal ausgeführt würde (beispielsweise können sowohl Host als auch Gast auf eine Web-App zugreifen, die auf http://localhost:3000). ausgeführt wird).

Als Host sollten Sie allerdings nur ganz bestimmte Ports für Gäste freigeben und nur Anwendungsports, keine 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 trifft Live Share keine Annahmen darüber, was freigegeben werden soll und was nicht, ohne dass eine Konfigurationseinstellung vorgenommen wurde und der Host eine Aktion ausgeführt hat.

In Visual Studio wird der in ASP.NET-Projekten angegebene Webanwendungsport nur während des Debuggens automatisch freigegeben, um den Gastzugriff auf die Web-App während der Ausführung zu erleichtern. Sie können diese Automatisierung jedoch deaktivieren, indem Sie für Tools > Optionen > Live Share > „Share Web App on debug“ (Web-App beim Debuggen freigeben) „False“ festlegen, wenn Ihnen dies lieber ist.

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 jedem Fall sollten Sie bei der Freigabe zusätzlicher Ports vorsichtig sein.

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 Mitarbeitenden erlauben, entweder nur die Ausgabe anzuzeigen oder eine beliebige Anzahl von Befehlszeilentools zum Ausführen von Tests, für Builds oder sogar zur Selektierung von umgebungsspezifischen Problemen zu verwenden.

Nur Hosts haben die Möglichkeit, freigegebene Terminals zu starten. So werden Gäste daran gehindert, ein eigenes Terminal aufzurufen und unerwartete Befehle auszuführen, die Sie nicht überwachen können. Wenn Sie als Host ein freigegebenes Terminal starten, können Sie angeben, ob es schreibgeschützt sein soll oder der Lese-/Schreibzugriff möglich 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-Administratoreinwilligung

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

Ihr AD-Administrator muss dieses Problem mithilfe der folgenden Informationen für Sie 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 muss für jeden, der Live Share verwendet, nur einmal geschehen. 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.