Remote Development Tipps und Tricks
Dieser Artikel behandelt Tipps und Tricks zur Fehlerbehebung für jede der Visual Studio Code Remote Development Erweiterungen. Details zur Einrichtung und Arbeit mit jeder einzelnen Erweiterung finden Sie in den Artikeln zu SSH, Containern und WSL. Oder probieren Sie die einführenden Tutorials aus, um schnell in einer Remote-Umgebung einsatzbereit zu sein.
Für Tipps und Fragen zu GitHub Codespaces lesen Sie die Dokumentation zu GitHub Codespaces.
SSH-Tipps
SSH ist leistungsstark und flexibel, was jedoch auch eine gewisse Komplexität bei der Einrichtung mit sich bringt. Dieser Abschnitt enthält einige Tipps und Tricks, um die Erweiterung Remote - SSH in verschiedenen Umgebungen einzurichten und einsatzbereit zu machen.
KI-Chat-Antworten anpassen
Benutzerdefinierte Anweisungen ermöglichen es Ihnen, allgemeine Richtlinien oder Regeln zu beschreiben, um Antworten zu erhalten, die Ihren spezifischen Codierungspraktiken und Ihrem Tech-Stack entsprechen.
Sie können benutzerdefinierte Anweisungen verwenden, um Copilot mehr Informationen über die Art der Remote-Umgebung zu geben, mit der Sie verbunden sind (z. B. welche Sprachen oder Toolchains installiert sind). Sie können eine copilot-instructions.md-Datei genauso verwenden, wie Sie es lokal tun würden. Bei der Verwendung eines Dev-Containers gibt es auch zusätzliche Konfigurationsschritte für Anweisungen, die Sie durchführen können.
Konfigurieren der $EDITOR-Variable
Für macOS / Linux-Remote-Hosts fügen Sie diesen Ausschnitt zu Ihrer Shell-Konfigurationsdatei hinzu (z. B. .bashrc oder .zshrc)
if [ "$VSCODE_INJECTION" = "1" ]; then
export EDITOR="code --wait" # or 'code-insiders' if you're using VS Code Insiders
fi
Für Windows-Hosts hier das entsprechende PowerShell-Skript
if ($env:VSCODE_INJECTION -eq "1") {
$env:EDITOR = "code --wait" # or 'code-insiders' for VS Code Insiders
}
Wenn Sie nun einen Terminalbefehl ausführen, der die $EDITOR-Variable verwendet, wie z. B. git commit, wird die Datei in VS Code geöffnet und nicht der standardmäßige terminalbasierte Editor (wie vim oder nano).
Konfigurieren der schlüsselbasierten Authentifizierung
SSH-Public-Key-Authentifizierung ist eine bequeme und hochsichere Authentifizierungsmethode, die einen lokalen "privaten" Schlüssel mit einem "öffentlichen" Schlüssel kombiniert, den Sie Ihrem Benutzerkonto auf einem SSH-Host zuordnen. Dieser Abschnitt führt Sie durch die Erstellung dieser Schlüssel und deren Hinzufügung zu einem Host.
Tipp: PuTTY für Windows ist kein unterstützter Client, aber Sie können Ihre PuTTYGen-Schlüssel konvertieren.
Schnellstart: Verwendung von SSH-Schlüsseln
Um eine schlüsselbasierte SSH-Authentifizierung für Ihren Remote-Host einzurichten, erstellen wir zunächst ein Schlüsselpaar und kopieren dann den öffentlichen Schlüssel zum Host.
Erstellen Sie Ihr lokales SSH-Schlüsselpaar
Prüfen Sie, ob Sie bereits einen SSH-Schlüssel auf Ihrem lokalen Computer haben. Dieser befindet sich normalerweise unter ~/.ssh/id_ed25519.pub unter macOS / Linux und im .ssh-Verzeichnis in Ihrem Benutzerprofilordner unter Windows (z. B. C:\Users\Ihr-Benutzer\.ssh\id_ed25519.pub).
Wenn Sie keinen Schlüssel haben, führen Sie den folgenden Befehl in einem lokalen Terminal / PowerShell aus, um ein SSH-Schlüsselpaar zu generieren
ssh-keygen -t ed25519 -b 4096
Tipp: Haben Sie
ssh-keygennicht? Installieren Sie einen unterstützten SSH-Client.
Beschränken Sie die Berechtigungen für die private Schlüsseldatei
-
Führen Sie für macOS / Linux den folgenden Shell-Befehl aus und ersetzen Sie den Pfad zu Ihrem privaten Schlüssel bei Bedarf
chmod 400 ~/.ssh/id_ed25519 -
Führen Sie für Windows den folgenden Befehl in PowerShell aus, um Ihrem Benutzernamen expliziten Lesezugriff zu gewähren
icacls "privateKeyPath" /grant <username>:RNavigieren Sie dann zur privaten Schlüsseldatei im Windows Explorer, klicken Sie mit der rechten Maustaste darauf und wählen Sie Eigenschaften. Wählen Sie die Registerkarte Sicherheit > Erweitert > Vererbung deaktivieren > Alle von diesem Objekt geerbten Berechtigungen entfernen.
Autorisieren Sie Ihre macOS- oder Linux-Maschine für die Verbindung
Führen Sie einen der folgenden Befehle in einem lokalen Terminalfenster aus und ersetzen Sie Benutzer- und Hostnamen entsprechend, um Ihren lokalen öffentlichen Schlüssel auf den SSH-Host zu kopieren.
-
Verbindung mit einem macOS- oder Linux-SSH-Host
export USER_AT_HOST="your-user-name-on-host@hostname" export PUBKEYPATH="$HOME/.ssh/id_ed25519.pub" ssh-copy-id -i "$PUBKEYPATH" "$USER_AT_HOST" -
Verbindung mit einem Windows-SSH-Host
-
Der Host verwendet OpenSSH Server und der Benutzer gehört zur Administratorgruppe
export USER_AT_HOST="your-user-name-on-host@hostname" export PUBKEYPATH="$HOME/.ssh/id_ed25519.pub" ssh $USER_AT_HOST "powershell Add-Content -Force -Path \"\$Env:PROGRAMDATA\\ssh\\administrators_authorized_keys\" -Value '$(tr -d '\n\r' < "$PUBKEYPATH")'" -
Andernfalls
export USER_AT_HOST="your-user-name-on-host@hostname" export PUBKEYPATH="$HOME/.ssh/id_ed25519.pub" ssh $USER_AT_HOST "powershell New-Item -Force -ItemType Directory -Path \"\$HOME\\.ssh\"; Add-Content -Force -Path \"\$HOME\\.ssh\\authorized_keys\" -Value '$(tr -d '\n\r' < "$PUBKEYPATH")'"Sie möchten möglicherweise überprüfen, ob die Datei
authorized_keysim Ordner.sshfür Ihren Remote-Benutzer auf dem SSH-Host Ihnen gehört und kein anderer Benutzer darauf zugreifen kann. Details finden Sie im OpenSSH-Wiki.
-
Autorisieren Sie Ihre Windows-Maschine für die Verbindung
Führen Sie einen der folgenden Befehle in einem lokalen PowerShell-Fenster aus und ersetzen Sie Benutzer- und Hostnamen entsprechend, um Ihren lokalen öffentlichen Schlüssel auf den SSH-Host zu kopieren.
-
Verbindung mit einem macOS- oder Linux-SSH-Host
$USER_AT_HOST="your-user-name-on-host@hostname" $PUBKEYPATH="$HOME\.ssh\id_ed25519.pub" $pubKey=(Get-Content "$PUBKEYPATH" | Out-String); ssh "$USER_AT_HOST" "mkdir -p ~/.ssh && chmod 700 ~/.ssh && echo '${pubKey}' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys" -
Verbindung mit einem Windows-SSH-Host
-
Der Host verwendet OpenSSH Server und der Benutzer gehört zur Administratorgruppe
$USER_AT_HOST="your-user-name-on-host@hostname" $PUBKEYPATH="$HOME\.ssh\id_ed25519.pub" Get-Content "$PUBKEYPATH" | Out-String | ssh $USER_AT_HOST "powershell `"Add-Content -Force -Path `"`$Env:PROGRAMDATA\ssh\administrators_authorized_keys`" `"" -
Andernfalls
$USER_AT_HOST="your-user-name-on-host@hostname" $PUBKEYPATH="$HOME\.ssh\id_ed25519.pub" Get-Content "$PUBKEYPATH" | Out-String | ssh $USER_AT_HOST "powershell `"New-Item -Force -ItemType Directory -Path `"`$HOME\.ssh`"; Add-Content -Force -Path `"`$HOME\.ssh\authorized_keys`" `""Überprüfen Sie, ob die Datei
authorized_keysim Ordner.sshfür Ihren Remote-Benutzer auf dem SSH-Host Ihnen gehört und kein anderer Benutzer darauf zugreifen kann. Details finden Sie im OpenSSH-Wiki.
-
Verbessern Sie Ihre Sicherheit mit einem dedizierten Schlüssel
Während die Verwendung eines einzigen SSH-Schlüssels für alle Ihre SSH-Hosts praktisch sein kann, haben Angreifer, die Zugriff auf Ihren privaten Schlüssel erlangen, auch Zugriff auf alle Ihre Hosts. Dies können Sie verhindern, indem Sie einen separaten SSH-Schlüssel für Ihre Entwicklungshosts erstellen. Folgen Sie einfach diesen Schritten:
-
Generieren Sie einen separaten SSH-Schlüssel in einer anderen Datei.
macOS / Linux: Führen Sie den folgenden Befehl in einem lokalen Terminal aus
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519-remote-sshWindows: Führen Sie den folgenden Befehl in einer lokalen PowerShell-Sitzung aus
ssh-keygen -t ed25519 -f "$HOME\.ssh\id_ed25519-remote-ssh" -
Befolgen Sie die gleichen Schritte wie im Schnellstart, um den Schlüssel auf dem SSH-Host zu autorisieren, aber setzen Sie
PUBKEYPATHstattdessen auf die Dateiid_ed25519-remote-ssh.pub. -
Führen Sie in VS Code Remote-SSH: Open Configuration File... in der Befehlspalette (F1) aus, wählen Sie eine SSH-Konfigurationsdatei aus und fügen Sie (oder ändern Sie) einen Host-Eintrag wie folgt hinzu:
Host name-of-ssh-host-here User your-user-name-on-host HostName host-fqdn-or-ip-goes-here IdentityFile ~/.ssh/id_ed25519-remote-sshTipp: Sie können auch
/für Windows-Pfade verwenden. Wenn Sie\verwenden, müssen Sie zwei Schrägstriche verwenden. Zum BeispielC:\\path\\to\\my\\id_ed25519.
Wiederverwendung eines in PuTTYGen generierten Schlüssels
Wenn Sie PuTTYGen zur Einrichtung der SSH-Public-Key-Authentifizierung für den Host verwendet haben, mit dem Sie sich verbinden, müssen Sie Ihren privaten Schlüssel konvertieren, damit andere SSH-Clients ihn verwenden können. Tun Sie dies wie folgt:
-
Öffnen Sie PuTTYGen lokal und laden Sie den privaten Schlüssel, den Sie konvertieren möchten.
-
Wählen Sie Conversions > Export OpenSSH key aus dem Anwendungsmenü. Speichern Sie den konvertierten Schlüssel an einem lokalen Speicherort im Verzeichnis
.sshin Ihrem Benutzerprofilordner (z. B.C:\Users\IhrBenutzer\.ssh). -
Überprüfen Sie, ob diese neue lokale Datei Ihnen gehört und kein anderer Benutzer Zugriff darauf hat.
-
Führen Sie in VS Code Remote-SSH: Open Configuration File... in der Befehlspalette (F1) aus, wählen Sie die SSH-Konfigurationsdatei aus, die Sie ändern möchten, und fügen Sie einen Host-Eintrag in der Konfigurationsdatei wie folgt hinzu (oder ändern Sie ihn), um auf die Datei zu verweisen:
Host name-of-ssh-host-here User your-user-name-on-host HostName host-fqdn-or-ip-goes-here IdentityFile ~/.ssh/exported-keyfile-from-putty
Verbesserung der Sicherheit auf Multi-User-Servern
Die Erweiterung Remote - SSH installiert und wartet den "VS Code Server". Der Server wird mit einem zufällig generierten Schlüssel gestartet, und jede neue Verbindung zum Server muss den Schlüssel angeben. Der Schlüssel wird auf der Festplatte des Remote-Systems gespeichert und kann nur vom aktuellen Benutzer gelesen werden. Es gibt einen HTTP-Pfad, der ohne Authentifizierung unter /version verfügbar ist.
Standardmäßig lauscht der Server auf localhost auf einem zufälligen TCP-Port, der dann an Ihr lokales System weitergeleitet wird. Wenn Sie eine Verbindung zu einem Linux- oder macOS-Host herstellen, können Sie stattdessen Unix-Sockets verwenden, die auf einen bestimmten Benutzer beschränkt sind. Dieser Socket wird dann anstelle des Ports weitergeleitet.
Hinweis: Diese Einstellung deaktiviert die Verbindungsmultiplexing. Daher wird die Konfiguration der Public-Key-Authentifizierung empfohlen.
So konfigurieren Sie es:
-
Stellen Sie sicher, dass Sie einen lokalen OpenSSH 6.7+ SSH-Client unter Windows, macOS oder Linux und einen OpenSSH 6.7+ Linux- oder macOS-Host (Windows unterstützt diesen Modus nicht) haben.
-
Schalten Sie Remote - SSH in den Socket-Modus, indem Sie Remote.SSH: Remote Server Listen On Socket in Ihren lokalen VS Code Benutzereinstellungen aktivieren.

-
Wenn Sie bereits eine Verbindung zum SSH-Host hergestellt haben, wählen Sie Remote-SSH: Kill VS Code Server on Host... aus der Befehlspalette (F1), damit die Einstellung wirksam wird.
Wenn Sie beim Verbinden einen Fehler erhalten, müssen Sie möglicherweise die Socket-Weiterleitung in der sshd-Konfiguration Ihres SSH-Hosts aktivieren. Tun Sie dies wie folgt:
- Öffnen Sie
/etc/ssh/sshd_configin einem Texteditor (wie vi, nano oder pico) auf dem SSH-Host (nicht lokal). - Fügen Sie die Einstellung
AllowStreamLocalForwarding yeshinzu. - Starten Sie den SSH-Server neu. (Unter Ubuntu führen Sie
sudo systemctl restart sshdaus). - Versuchen Sie es erneut.
Fehlerbehebung bei hängenden oder fehlerhaften Verbindungen
Wenn Sie Probleme mit VS Code haben, das beim Versuch einer Verbindung hängt (und möglicherweise die Zeit überschreitet), gibt es einige Dinge, die Sie tun können, um das Problem zu beheben.
Allgemeine Fehlerbehebung: Server entfernen
Ein Befehl, der bei der Fehlerbehebung einer Vielzahl von Remote-SSH-Problemen hilfreich ist, ist Remote-SSH: Kill VS Code Server on Host. Dieser Befehl entfernt den Server, was eine Vielzahl von Problemen und Fehlermeldungen beheben kann, wie z. B. "Could not establish connection to server_name: The VS Code Server failed to start."
Prüfen Sie, ob VS Code auf eine Aufforderung wartet
Aktivieren Sie die Einstellung remote.SSH.showLoginTerminal in VS Code und versuchen Sie es erneut. Wenn Sie aufgefordert werden, ein Passwort oder Token einzugeben, finden Sie weitere Informationen zur Reduzierung der Häufigkeit von Aufforderungen unter Alternative SSH-Authentifizierungsmethoden aktivieren.
Wenn Sie immer noch Probleme haben, legen Sie die folgenden Eigenschaften in settings.json fest und versuchen Sie es erneut
"remote.SSH.showLoginTerminal": true,
"remote.SSH.useLocalServer": false
Umgehung eines Fehlers bei einigen Versionen des Windows OpenSSH Servers
Aufgrund eines Fehlers in bestimmten Versionen des OpenSSH Servers für Windows funktioniert die Standardprüfung, um festzustellen, ob der Host Windows ausführt, möglicherweise nicht richtig. Dies tritt nicht bei dem OpenSSH Server auf, der mit Windows 1909 und älter geliefert wird.
Glücklicherweise können Sie dieses Problem umgehen, indem Sie VS Code spezifisch mitteilen, ob Ihr SSH-Host Windows ausführt, indem Sie das Folgende zu settings.json hinzufügen:
"remote.SSH.useLocalServer": false
Sie können VS Code auch zwingen, einen bestimmten Host als Windows zu identifizieren, indem Sie die folgende Eigenschaft verwenden:
"remote.SSH.remotePlatform": {
"host-in-ssh-config-or-fqdn": "windows"
}
Ein Fix wurde integriert, sodass dieses Problem in einer Version des Servers größer als 8.1.0.0 behoben sein sollte.
TCP-Weiterleitung auf dem Remote-Host aktivieren
Die Remote - SSH-Erweiterung verwendet einen SSH-Tunnel, um die Kommunikation mit dem Host zu erleichtern. In einigen Fällen kann dies auf Ihrem SSH-Server deaktiviert sein. Um zu prüfen, ob dies das Problem ist, öffnen Sie die Kategorie Remote - SSH im Ausgabefenster und suchen Sie nach der folgenden Meldung:
open failed: administratively prohibited: open failed
Wenn Sie diese Meldung sehen, befolgen Sie diese Schritte, um die sshd-Konfiguration Ihres SSH-Servers zu aktualisieren:
- Öffnen Sie
/etc/ssh/sshd_configoderC:\ProgramData\ssh\sshd_configin einem Texteditor (wie Vim, nano, Pico oder Notepad) auf dem SSH-Host (nicht lokal). - Fügen Sie die Einstellung
AllowTcpForwarding yeshinzu. - Starten Sie den SSH-Server neu. (Unter Ubuntu führen Sie
sudo systemctl restart sshdaus. Unter Windows führen Sie in einer Administrator-PowerShellRestart-Service sshdaus). - Versuchen Sie es erneut.
Setzen Sie den Parameter ProxyCommand in Ihrer SSH-Konfigurationsdatei
Wenn Sie sich hinter einem Proxy befinden und keine Verbindung zu Ihrem SSH-Host herstellen können, müssen Sie möglicherweise den Parameter ProxyCommand für Ihren Host in einer lokalen SSH-Konfigurationsdatei verwenden. Sie können diesen Artikel über SSH ProxyCommand für ein Beispiel seiner Verwendung lesen.
Stellen Sie sicher, dass die Remote-Maschine Internetzugang hat
Die Remote-Maschine muss Internetzugang haben, um den VS Code Server und Erweiterungen vom Marketplace herunterladen zu können. Details zu den Konnektivitätsanforderungen finden Sie in der FAQ.
Setzen Sie HTTP_PROXY / HTTPS_PROXY auf dem Remote-Host
Wenn Ihr Remote-Host hinter einem Proxy liegt, müssen Sie möglicherweise die Umgebungsvariable HTTP_PROXY oder HTTPS_PROXY auf dem SSH-Host setzen. Öffnen Sie Ihre Datei ~/.bashrc und fügen Sie Folgendes hinzu (ersetzen Sie proxy.fqdn.or.ip:3128 durch den entsprechenden Hostnamen/IP und Port):
export HTTP_PROXY=http://proxy.fqdn.or.ip:3128
export HTTPS_PROXY=$HTTP_PROXY
# Or if an authenticated proxy
export HTTP_PROXY=http://username:password@proxy.fqdn.or.ip:3128
export HTTPS_PROXY=$HTTP_PROXY
Umgehung von /tmp, das mit noexec gemountet ist
Einige Remote-Server sind so konfiguriert, dass sie die Ausführung von Skripten aus /tmp nicht zulassen. VS Code schreibt sein Installationsskript in das temporäre Verzeichnis des Systems und versucht, es von dort auszuführen. Sie können mit Ihrem Systemadministrator klären, ob dies umgangen werden kann.
Prüfen Sie, ob beim Installieren eine andere Shell gestartet wird
Einige Benutzer starten eine andere Shell aus ihrer .bash_profile oder einem anderen Startskript auf ihrem SSH-Host, weil sie eine andere Shell als die Standard-Shell verwenden möchten. Dies kann das Installationsskript des VS Code Remote-Servers unterbrechen und wird nicht empfohlen. Verwenden Sie stattdessen chsh, um Ihre Standard-Shell auf der Remote-Maschine zu ändern.
Verbindung mit Systemen, die Maschinen dynamisch pro Verbindung zuweisen
Einige Systeme leiten eine SSH-Verbindung jedes Mal, wenn eine SSH-Verbindung hergestellt wird, dynamisch an einen Knoten aus einem Cluster weiter. Dies ist ein Problem für VS Code, da für das Öffnen eines Remote-Fensters zwei Verbindungen hergestellt werden: die erste zum Installieren oder Starten des VS Code Servers (oder zum Finden einer bereits laufenden Instanz) und die zweite zum Erstellen des SSH-Port-Tunnels, den VS Code zur Kommunikation mit dem Server verwendet. Wenn VS Code bei der Erstellung der zweiten Verbindung zu einer anderen Maschine weitergeleitet wird, kann es nicht mit dem VS Code-Server kommunizieren.
Eine Lösung hierfür ist die Verwendung der Option ControlMaster in OpenSSH (nur für macOS/Linux-Clients), die unter Alternative SSH-Authentifizierungsmethoden aktivieren beschrieben ist, sodass die beiden Verbindungen von VS Code über eine einzige SSH-Verbindung zum selben Knoten gemultiplext werden.
Kontaktieren Sie Ihren Systemadministrator für Konfigurationshilfe
SSH ist ein sehr flexibles Protokoll und unterstützt viele Konfigurationen. Wenn Sie andere Fehler sehen, entweder im Login-Terminal oder im Ausgabefenster Remote-SSH, können diese auf eine fehlende Einstellung zurückzuführen sein.
Kontaktieren Sie Ihren Systemadministrator, um Informationen über die erforderlichen Einstellungen für Ihren SSH-Host und -Client zu erhalten. Spezifische Kommandozeilenargumente für die Verbindung zu Ihrem SSH-Host können zu einer SSH-Konfigurationsdatei hinzugefügt werden.
Um auf Ihre Konfigurationsdatei zuzugreifen, führen Sie Remote-SSH: Open Configuration File... in der Befehlspalette (F1) aus. Sie können dann mit Ihrem Administrator zusammenarbeiten, um die notwendigen Einstellungen hinzuzufügen.
Alternative SSH-Authentifizierungsmethoden aktivieren
Wenn Sie eine Verbindung zu einem SSH-Remote-Host herstellen und entweder
- Mit Zwei-Faktor-Authentifizierung verbinden
- Passwortauthentifizierung verwenden
- Einen SSH-Schlüssel mit einer Passphrase verwenden, wenn der SSH-Agent nicht läuft oder nicht erreichbar ist
dann sollte VS Code Sie automatisch auffordern, die benötigten Informationen einzugeben. Wenn Sie die Aufforderung nicht sehen, aktivieren Sie die Einstellung remote.SSH.showLoginTerminal in VS Code. Diese Einstellung zeigt das Terminal an, wenn VS Code einen SSH-Befehl ausführt. Sie können dann Ihren Authentifizierungscode, Ihr Passwort oder Ihre Passphrase eingeben, wenn das Terminal erscheint.
Wenn Sie immer noch Probleme haben, müssen Sie möglicherweise die folgenden Eigenschaften in settings.json hinzufügen und es erneut versuchen
"remote.SSH.showLoginTerminal": true,
"remote.SSH.useLocalServer": false
Wenn Sie unter macOS und Linux sind und die Häufigkeit, mit der Sie ein Passwort oder Token eingeben müssen, reduzieren möchten, können Sie die Funktion ControlMaster auf Ihrem lokalen Computer aktivieren, sodass OpenSSH mehrere SSH-Sitzungen über eine einzige Verbindung ausführt.
So aktivieren Sie ControlMaster:
-
Fügen Sie einen Eintrag wie diesen zu Ihrer SSH-Konfigurationsdatei hinzu:
Host * ControlMaster auto ControlPath ~/.ssh/sockets/%r@%h-%p ControlPersist 600 -
Führen Sie dann
mkdir -p ~/.ssh/socketsaus, um den Socket-Ordner zu erstellen.
Einrichtung des SSH-Agenten
Wenn Sie eine Verbindung zu einem SSH-Host mit einem Schlüssel mit Passphrase herstellen, sollten Sie sicherstellen, dass der SSH-Agent lokal läuft. VS Code fügt Ihren Schlüssel automatisch zum Agenten hinzu, sodass Sie Ihre Passphrase nicht jedes Mal eingeben müssen, wenn Sie ein Remote-VS-Code-Fenster öffnen.
Um zu überprüfen, ob der Agent läuft und von der Umgebung von VS Code erreichbar ist, führen Sie ssh-add -l im Terminal eines lokalen VS-Code-Fensters aus. Sie sollten eine Liste der Schlüssel im Agenten sehen (oder eine Meldung, dass er keine Schlüssel hat). Wenn der Agent nicht läuft, folgen Sie diesen Anweisungen, um ihn zu starten. Nach dem Start des Agenten starten Sie VS Code neu.
Windows
Um den SSH-Agenten unter Windows automatisch zu aktivieren, starten Sie eine lokale Administrator-PowerShell und führen Sie die folgenden Befehle aus:
# Make sure you're running as an Administrator
Set-Service ssh-agent -StartupType Automatic
Start-Service ssh-agent
Get-Service ssh-agent
Der Agent wird nun beim Anmelden automatisch gestartet.
Linux
Um den SSH-Agenten im Hintergrund zu starten, führen Sie aus:
eval "$(ssh-agent -s)"
Um den SSH-Agenten beim Anmelden automatisch zu starten, fügen Sie diese Zeilen zu Ihrer ~/.bash_profile hinzu:
if [ -z "$SSH_AUTH_SOCK" ]; then
# Check for a currently running instance of the agent
RUNNING_AGENT="`ps -ax | grep 'ssh-agent -s' | grep -v grep | wc -l | tr -d '[:space:]'`"
if [ "$RUNNING_AGENT" = "0" ]; then
# Launch a new instance of the agent
ssh-agent -s &> .ssh/ssh-agent
fi
eval `cat .ssh/ssh-agent`
fi
macOS
Der Agent sollte unter macOS standardmäßig laufen.
Den lokalen SSH-Agenten im Remote-System verfügbar machen
Ein SSH-Agent auf Ihrem lokalen Computer ermöglicht der Remote - SSH-Erweiterung die Verbindung zu Ihrem ausgewählten Remote-System, ohne wiederholt nach einer Passphrase zu fragen. Tools wie Git, die auf dem Remote-System laufen, haben jedoch keinen Zugriff auf Ihre lokal entsperrten privaten Schlüssel.
Sie können dies sehen, indem Sie das integrierte Terminal auf dem Remote-System öffnen und ssh-add -l ausführen. Der Befehl sollte die entsperrten Schlüssel auflisten, meldet jedoch stattdessen einen Fehler über die Unfähigkeit, eine Verbindung zum Authentifizierungsagenten herzustellen. Das Setzen von ForwardAgent yes macht den lokalen SSH-Agenten in der Remote-Umgebung verfügbar und löst dieses Problem.
Dies können Sie tun, indem Sie Ihre Datei .ssh/config bearbeiten (oder was auch immer Remote.SSH.configFile eingestellt ist - verwenden Sie den Befehl Remote-SSH: Open SSH Configuration File..., um sicherzugehen) und Folgendes hinzufügen:
Host *
ForwardAgent yes
Beachten Sie, dass Sie restriktiver sein und die Option nur für bestimmte benannte Hosts festlegen möchten.
Beheben von SSH-Datei-Berechtigungsfehlern
SSH kann streng bei Dateiberechtigungen sein, und wenn diese falsch eingestellt sind, sehen Sie möglicherweise Fehler wie "WARNING: UNPROTECTED PRIVATE KEY FILE!". Es gibt mehrere Möglichkeiten, die Dateiberechtigungen zu aktualisieren, um dies zu beheben, die in den folgenden Abschnitten beschrieben werden.
Lokale SSH-Datei- und Ordnerberechtigungen
macOS / Linux
Stellen Sie auf Ihrem lokalen Computer sicher, dass die folgenden Berechtigungen eingestellt sind:
| Ordner / Datei | Berechtigungen |
|---|---|
.ssh in Ihrem Benutzerordner |
chmod 700 ~/.ssh |
.ssh/config in Ihrem Benutzerordner |
chmod 600 ~/.ssh/config |
.ssh/id_ed25519.pub in Ihrem Benutzerordner |
chmod 600 ~/.ssh/id_ed25519.pub |
| Beliebige andere Schlüsseldatei | chmod 600 /pfad/zu/schlüssel/datei |
Windows
Die spezifischen erwarteten Berechtigungen können je nach genauer SSH-Implementierung, die Sie verwenden, variieren. Wir empfehlen die Verwendung des standardmäßigen Windows 10 OpenSSH Client.
Stellen Sie in diesem Fall sicher, dass alle Dateien im .ssh-Ordner für Ihren Remote-Benutzer auf dem SSH-Host Ihnen gehören und kein anderer Benutzer Zugriff darauf hat. Details finden Sie im Windows OpenSSH-Wiki.
Konsultieren Sie für alle anderen Clients die Dokumentation Ihres Clients, um zu erfahren, was die Implementierung erwartet.
Server SSH-Datei- und Ordnerberechtigungen
macOS / Linux
Stellen Sie auf der Remote-Maschine, mit der Sie sich verbinden, sicher, dass die folgenden Berechtigungen eingestellt sind:
| Ordner / Datei | Linux / macOS-Berechtigungen |
|---|---|
.ssh in Ihrem Benutzerordner auf dem Server |
chmod 700 ~/.ssh |
.ssh/authorized_keys in Ihrem Benutzerordner auf dem Server |
chmod 600 ~/.ssh/authorized_keys |
Beachten Sie, dass derzeit nur Linux-Hosts unterstützt werden, weshalb die Berechtigungen für macOS und Windows 10 weggelassen wurden.
Windows
Details zur Einstellung der entsprechenden Dateiberechtigungen für den Windows OpenSSH Server finden Sie im Windows OpenSSH-Wiki.
Installation eines unterstützten SSH-Clients
| Betriebssystem | Anweisungen |
|---|---|
| Windows 10 1803+ / Server 2016/2019 1803+ | Installieren Sie den Windows OpenSSH Client. |
| Frühere Windows-Versionen | Installieren Sie Git für Windows. |
| macOS | Ist vorinstalliert. |
| Debian/Ubuntu | Führen Sie sudo apt-get install openssh-client aus |
| RHEL / Fedora / CentOS | Führen Sie sudo yum install openssh-clients aus |
VS Code sucht im PATH nach dem Befehl ssh. Wenn er nicht gefunden wird, versucht es unter Windows, ssh.exe im Standardinstallationspfad von Git für Windows zu finden. Sie können VS Code auch explizit mitteilen, wo der SSH-Client zu finden ist, indem Sie die Eigenschaft remote.SSH.path zu settings.json hinzufügen.
Installation eines unterstützten SSH-Servers
| Betriebssystem | Anweisungen | Details |
|---|---|---|
| Debian 8+ / Ubuntu 16.04+ | Führen Sie sudo apt-get install openssh-server aus |
Details finden Sie in der Ubuntu SSH-Dokumentation. |
| RHEL / CentOS 7+ | Führen Sie sudo yum install openssh-server && sudo systemctl start sshd.service && sudo systemctl enable sshd.service aus |
Details finden Sie in der RedHat SSH-Dokumentation. |
| SuSE 12+ / openSUSE 42.3+ | Gehen Sie in Yast zu Services Manager, wählen Sie "sshd" in der Liste aus und klicken Sie auf Aktivieren. Gehen Sie dann zu Firewall, wählen Sie die Dauerhafte Konfiguration und aktivieren Sie unter Dienste sshd. | Details finden Sie in der SuSE SSH-Dokumentation. |
| Windows 10 1803+ / Server 2016/2019 1803+ | Installieren Sie den Windows OpenSSH Server. | |
| macOS 10.14+ (Mojave) | Aktivieren Sie die Fernanmeldung. |
Löst Hänger bei Git Push oder Sync auf einem SSH-Host
Wenn Sie ein Git-Repository über SSH klonen und Ihr SSH-Schlüssel eine Passphrase hat, können die Pull- und Sync-Funktionen von VS Code beim Remote-Betrieb hängen bleiben.
Verwenden Sie entweder einen SSH-Schlüssel ohne Passphrase, klonen Sie über HTTPS oder führen Sie git push von der Kommandozeile aus, um das Problem zu umgehen.
Verwendung von SSHFS zum Zugriff auf Dateien auf Ihrem Remote-Host
SSHFS ist ein sicheres Protokoll für den Fernzugriff auf Dateisysteme, das auf SFTP aufbaut. Es bietet Vorteile gegenüber beispielsweise einer CIFS / Samba-Freigabe, da lediglich ein SSH-Zugang zur Maschine erforderlich ist.
Hinweis: Aus Performancegründen eignet sich SSHFS am besten für die Bearbeitung einzelner Dateien und das Hoch- und Herunterladen von Inhalten. Wenn Sie eine Anwendung verwenden müssen, die viele Dateien gleichzeitig liest/schreibt (wie ein lokales Quellcodeverwaltungstool), ist rsync die bessere Wahl.
macOS / Linux:
Unter Linux können Sie den Paketmanager Ihrer Distribution verwenden, um SSHFS zu installieren. Für Debian/Ubuntu: sudo apt-get install sshfs
Hinweis: WSL 1 unterstützt kein FUSE oder SSHFS, daher sind die Anweisungen für Windows derzeit unterschiedlich. WSL 2 enthält FUSE und SSHFS-Unterstützung, daher wird sich dies bald ändern.
Unter macOS können Sie SSHFS mit Homebrew installieren:
brew install --cask macfuse
brew install gromgit/fuse/sshfs-mac
brew link --overwrite sshfs-mac
Wenn Sie die Kommandozeile nicht verwenden möchten, um das Remote-Dateisystem zu mounten, können Sie auch SSHFS GUI installieren.
Um die Kommandozeile zu verwenden, führen Sie die folgenden Befehle von einem lokalen Terminal aus (ersetzen Sie user@hostname durch den Remote-Benutzer und den Hostnamen / die IP-Adresse):
export USER_AT_HOST=user@hostname
# Make the directory where the remote filesystem will be mounted
mkdir -p "$HOME/sshfs/$USER_AT_HOST"
# Mount the remote filesystem
sshfs "$USER_AT_HOST:" "$HOME/sshfs/$USER_AT_HOST" -ovolname="$USER_AT_HOST" -p 22 \
-o workaround=nonodelay -o transform_symlinks -o idmap=user -C
Dadurch wird Ihr Home-Ordner auf der Remote-Maschine unter ~/sshfs verfügbar gemacht. Wenn Sie fertig sind, können Sie ihn über den Finder / Datei-Explorer Ihres Betriebssystems oder über die Kommandozeile unmounten:
umount "$HOME/sshfs/$USER_AT_HOST"
Windows
Befolgen Sie diese Schritte:
-
Fügen Sie unter Linux eine
.gitattributes-Datei zu Ihrem Projekt hinzu, um konsistente Zeilenenden zwischen Linux und Windows zu erzwingen und unerwartete Probleme aufgrund von CRLF/LF-Unterschieden zwischen den beiden Betriebssystemen zu vermeiden. Details finden Sie unter Auflösung von Git-Zeilenendeproblemen. -
Installieren Sie dann SSHFS-Win mit Chocolatey:
choco install sshfs -
Nachdem Sie SSHFS für Windows installiert haben, können Sie die Option Netzlaufwerk zuordnen... im Datei-Explorer mit dem Pfad
\\sshfs\user@hostnameverwenden, wobeiuser@hostnameIhr Remote-Benutzer und Hostname / IP ist. Sie können dies mit der Eingabeaufforderung wie folgt skripten:net use /PERSISTENT:NO X: \\sshfs\user@hostname -
Wenn Sie fertig sind, trennen Sie die Verbindung, indem Sie mit der rechten Maustaste auf das Laufwerk im Datei-Explorer klicken und Trennen auswählen.
Verbindung zu einem Remote-Host aus dem Terminal herstellen
Sobald ein Host konfiguriert ist, können Sie direkt aus dem Terminal eine Verbindung dazu herstellen, indem Sie eine Remote-URI übergeben.
Um beispielsweise eine Verbindung zu remote_server herzustellen und den Ordner /code/my_project zu öffnen, führen Sie aus:
code --remote ssh-remote+remote_server /code/my_project
Wir müssen raten, ob der Eingabepfad eine Datei oder ein Ordner ist. Wenn er eine Dateierweiterung hat, wird er als Datei betrachtet.
Um zu erzwingen, dass ein Ordner geöffnet wird, fügen Sie einen Schrägstrich zum Pfad hinzu oder verwenden Sie
code --folder-uri vscode-remote://ssh-remote+remote_server/code/folder.with.dot
Um zu erzwingen, dass eine Datei geöffnet wird, fügen Sie --goto hinzu oder verwenden Sie
code --file-uri vscode-remote://ssh-remote+remote_server/code/fileWithoutExtension
Verwendung von rsync zur Pflege einer lokalen Kopie Ihres Quellcodes
Eine Alternative zur Verwendung von SSHFS für den Zugriff auf Remote-Dateien ist die Verwendung von rsync, um den gesamten Inhalt eines Ordners auf dem Remote-Host auf Ihren lokalen Computer zu kopieren. Der Befehl rsync ermittelt bei jeder Ausführung, welche Dateien aktualisiert werden müssen, was weitaus effizienter und bequemer ist als die Verwendung von scp oder sftp. Dies sollten Sie in erster Linie in Betracht ziehen, wenn Sie wirklich multifile oder leistungshungrige lokale Tools verwenden müssen.
Der Befehl rsync ist unter macOS standardmäßig verfügbar und kann über Linux-Paketmanager installiert werden (z. B. sudo apt-get install rsync unter Debian/Ubuntu). Für Windows müssen Sie entweder WSL oder Cygwin verwenden, um auf den Befehl zuzugreifen.
Um den Befehl zu verwenden, navigieren Sie zu dem Ordner, in dem Sie die synchronisierten Inhalte speichern möchten, und führen Sie Folgendes aus (ersetzen Sie user@hostname durch den Remote-Benutzer und den Hostnamen / die IP-Adresse sowie /remote/source/code/path durch den Remote-Quellcode-Speicherort).
Unter macOS, Linux oder innerhalb von WSL
rsync -rlptzv --progress --delete --exclude=.git "user@hostname:/remote/source/code/path" .
Oder mit WSL aus PowerShell unter Windows
wsl rsync -rlptzv --progress --delete --exclude=.git "user@hostname:/remote/source/code/path" "`$(wslpath -a '$PWD')"
Sie können diesen Befehl jedes Mal erneut ausführen, wenn Sie die neueste Kopie Ihrer Dateien erhalten möchten, und nur die Aktualisierungen werden übertragen. Der Ordner .git ist sowohl aus Leistungsgründen als auch damit Sie lokale Git-Tools verwenden können, ohne sich um den Zustand auf dem Remote-Host sorgen zu müssen, absichtlich ausgeschlossen.
Um Inhalte zu pushen, vertauschen Sie die Quell- und Zielparameter im Befehl. Unter Windows sollten Sie jedoch zuvor eine .gitattributes-Datei zu Ihrem Projekt hinzufügen, um konsistente Zeilenenden zu erzwingen. Details finden Sie unter Auflösung von Git-Zeilenendeproblemen.
rsync -rlptzv --progress --delete --exclude=.git . "user@hostname:/remote/source/code/path"
Aufräumen des VS Code Servers auf dem Remote-System
Die SSH-Erweiterung bietet einen Befehl zum Aufräumen des VS Code Servers auf dem Remote-System: Remote-SSH: Uninstall VS Code Server from Host.... Der Befehl tut zwei Dinge: Er beendet alle laufenden VS Code Server-Prozesse und löscht den Ordner, in dem der Server installiert war.
Wenn Sie diese Schritte manuell ausführen möchten oder wenn der Befehl bei Ihnen nicht funktioniert, können Sie ein Skript wie folgt ausführen:
# Kill server processes
kill -9 $(ps aux | grep vscode-server | grep $USER | grep -v grep | awk '{print $2}')
# Delete related files and folder
rm -rf $HOME/.vscode-server # Or ~/.vscode-server-insiders
Der VS Code Server wurde zuvor unter ~/.vscode-remote installiert, daher können Sie auch diesen Speicherort überprüfen.
SSH auf einen Remote-WSL-2-Host
Sie möchten möglicherweise SSH verwenden, um eine Verbindung zu einer WSL-Distribution auf Ihrer Remote-Maschine herzustellen. Schauen Sie sich diesen Leitfaden an, um zu erfahren, wie Sie von einer externen Maschine mit SSH in Bash und WSL 2 unter Windows 10 zugreifen können.
Einreichen eines Problems
Wenn Sie Probleme mit der Remote-SSH-Erweiterung haben und denken, dass Sie ein Problem einreichen müssen, stellen Sie zunächst sicher, dass Sie die Dokumentation auf dieser Website gelesen haben, und sehen Sie sich dann das Wiki-Dokument zur Fehlerbehebung an, um Informationen zum Abrufen der Logdatei und zum Ausprobieren weiterer Schritte zu erhalten, die helfen können, die Quelle des Problems einzugrenzen.
Dev Containers Tipps
Wenn Sie Tipps zur Verwendung von Dev Containers lesen möchten, können Sie zu Dev Containers Tipps und Tricks wechseln.
WSL-Tipps
Erster Start: Voraussetzungen für den VS Code Server
Einige WSL-Linux-Distributionen verfügen nicht über die Bibliotheken, die für den Start des VS Code-Servers erforderlich sind. Sie können zusätzliche Bibliotheken zu Ihrer Linux-Distribution mit deren Paketmanager hinzufügen.
Debian und Ubuntu
Öffnen Sie die Debian- oder Ubuntu-WSL-Shell, um wget und ca-certificates hinzuzufügen.
sudo apt-get update && sudo apt-get install wget ca-certificates
Alpine
Öffnen Sie die Alpine-WSL-Shell als Root (wsl -d Alpine -u root), um libstdc++ hinzuzufügen.
apk update && apk add libstdc++
Unter Windows 10 April 2018 Update (Build 1803) und älter ist /bin/bash erforderlich.
apk update && apk add bash
Auswählen der von der WSL-Erweiterung verwendeten Distribution
WSL: Neues Fenster öffnet die als Standard registrierte WSL-Distribution.
Um eine nicht standardmäßige Distribution zu öffnen, führen Sie code . aus der WSL-Shell der zu verwendenden Distribution aus oder verwenden Sie WSL: Neues Fenster mit Distribution.
Mit WSL-Versionen älter als Windows 10, Mai 2019 Update (Version 1903), kann der WSL-Befehl nur die Standarddistribution verwenden. Aus diesem Grund fordert die WSL-Erweiterung Sie möglicherweise auf, ob Sie der Änderung der Standarddistribution zustimmen.
Sie können wslconfig.exe jederzeit verwenden, um Ihre Standardeinstellung zu ändern.
Zum Beispiel
wslconfig /setdefault Ubuntu
Sie können sehen, welche Distributionen Sie installiert haben, indem Sie ausführen
wslconfig /l
Konfigurieren der Umgebung für den Serverstart
Wenn die WSL-Erweiterung den VS Code-Server in WSL startet, führt sie keine Shell-Konfigurationsskripte aus. Dies geschah, um zu verhindern, dass benutzerdefinierte Konfigurationsskripte den Start behindern.
Wenn Sie die Startumgebung konfigurieren müssen, können Sie das Umgebungseinrichtungsskript wie hier beschrieben verwenden.
Konfigurieren der Umgebung für den Remote-Erweiterungshost
Die Umgebung für den Remote-Erweiterungshost und das Terminal basiert auf den Konfigurationsskripten der Standard-Shell. Um die Umgebungsvariablen für den Remote-Erweiterungshost-Prozess auszuwerten, erstellt der Server eine Instanz der Standard-Shell als interaktive Login-Shell. Er ermittelt die Umgebungsvariablen daraus und verwendet sie als anfängliche Umgebung für den Remote-Erweiterungshost-Prozess. Die Werte von Umgebungsvariablen hängen daher davon ab, welche Shell als Standard konfiguriert ist und was die Konfigurationsskripte für diese Shell enthalten.
Siehe Unix Shell-Initialisierung für einen Überblick über die Konfigurationsskripte jeder Shell. Die meisten WSL-Distributionen haben /bin/bash als Standard-Shell konfiguriert. /bin/bash sucht zuerst nach Startdateien unter /etc/profile und nach beliebigen Startdateien unter ~/.bash_profile, ~/.bash_login, ~/.profile.
Um die Standard-Shell einer WSL-Distribution zu ändern, folgen Sie den Anweisungen dieses Blogbeitrags.
Fehlerbehebung bei nicht funktionierendem code-Befehl
Wenn die Eingabe von code von einem WSL-Terminal unter Windows nicht funktioniert, da code nicht gefunden werden kann, fehlen Ihnen möglicherweise einige wichtige Pfade in Ihrer PATH-Umgebungsvariable in WSL.
Überprüfen Sie dies, indem Sie ein WSL-Terminal öffnen und echo $PATH eingeben. Sie sollten den VS Code-Installationspfad aufgeführt sehen. Standardmäßig ist dies
/mnt/c/Users/Your Username/AppData/Local/Programs/Microsoft VS Code/bin
Aber wenn Sie den Systeminstaller verwendet haben, ist der Installationspfad
/mnt/c/Program Files/Microsoft VS Code/bin
...oder...
/mnt/c/Program Files (x86)/Microsoft VS Code/bin
Es ist ein Feature von WSL, dass Pfade von der PATH-Variablen in Windows geerbt werden. Um die Windows-PATH-Variable zu ändern, verwenden Sie den Befehl Umgebungsvariablen für Ihr Konto bearbeiten aus dem Startmenü in Windows.
Wenn Sie die Pfadfreigabe deaktiviert haben, bearbeiten Sie Ihre .bashrc, fügen Sie Folgendes hinzu und starten Sie ein neues Terminal
WINDOWS_USERNAME="Your Windows Alias"
export PATH="$PATH:/mnt/c/Windows/System32:/mnt/c/Users/${WINDOWS_USERNAME}/AppData/Local/Programs/Microsoft VS Code/bin"
# or...
# export PATH="$PATH:/mnt/c/Program Files/Microsoft VS Code/bin"
# or...
# export PATH="$PATH:/mnt/c/Program Files (x86)/Microsoft VS Code/bin"
Hinweis: Achten Sie darauf, Leerzeichen in den Verzeichnisnamen in Anführungszeichen zu setzen oder zu maskieren.
Probleme mit dem Befehl 'code' finden
Wenn die Eingabe von code von einer Windows-Eingabeaufforderung VS Code nicht startet, können Sie uns helfen, das Problem zu diagnostizieren, indem Sie VSCODE_WSL_DEBUG_INFO=true code . ausführen.
Bitte erstellen Sie ein Issue und fügen Sie die vollständige Ausgabe bei.
Probleme beim Starten oder Verbinden mit dem Server finden
Wenn das WSL-Fenster keine Verbindung zum Remote-Server herstellen kann, erhalten Sie weitere Informationen im WSL-Protokoll. Beim Erstellen eines Issues ist es wichtig, immer den vollständigen Inhalt des WSL-Protokolls zu senden.
Öffnen Sie das WSL-Protokoll, indem Sie den Befehl WSL: Protokoll öffnen ausführen. Das Protokoll wird in der Terminalansicht unter dem WSL-Tab angezeigt.

Um noch detailliertere Protokollinformationen zu erhalten, aktivieren Sie die Einstellung remote.WSL.debug in den Benutzereinstellungen.
Der Server startet mit einem Segmentierungsfehler
Sie können uns bei der Untersuchung dieses Problems helfen, indem Sie uns die Core-Dump-Datei senden. Um die Core-Dump-Datei zu erhalten, befolgen Sie diese Schritte
In einer Windows-Eingabeaufforderung
- Führen Sie
code --locate-extension ms-vscode-remote.remote-wslaus, um den Ordner der WSL-Erweiterung zu ermitteln. cdSie zu dem zurückgegebenen Pfad.- Öffnen Sie das Skript
wslServer.shmit VS Code,code .\scripts\wslServer.sh. - Fügen Sie vor der letzten Zeile (vor
"$VSCODE_REMOTE_BIN/$COMMIT/bin/$SERVER_APPNAME" "$@")ulimit -C unlimitedhinzu. - Starten Sie das WSL-Fenster, das den Remote-Server ausführt, und warten Sie auf den Segmentierungsfehler.
Die Core-Datei befindet sich im oben genannten Ordner der WSL-Erweiterung.
Ich sehe den Fehler EACCES: permission denied beim Versuch, einen Ordner im geöffneten Arbeitsbereich umzubenennen
Dies ist ein bekanntes Problem mit der WSL-Dateisystemimplementierung (Microsoft/WSL#3395, Microsoft/WSL#1956), verursacht durch den von VS Code aktiven Dateibeobachter. Das Problem wird erst in WSL 2 behoben sein.
Um das Problem zu vermeiden, setzen Sie remote.WSL.fileWatcher.polling auf true. Allerdings hat derPolling-basierte Ansatz Leistungseinbußen bei großen Arbeitsbereichen.
Bei großen Arbeitsbereichen möchten Sie möglicherweise das Abfrageintervall remote.WSL.fileWatcher.pollingInterval erhöhen und die überwachten Ordner mit files.watcherExclude steuern.
WSL 2 hat dieses Problem mit dem Dateibeobachter nicht und ist von der neuen Einstellung nicht betroffen.
Behebung von Git-Zeilenendeproblemen in WSL (führt zu vielen geänderten Dateien)
Da Windows und Linux unterschiedliche Standard-Zeilenenden verwenden, kann Git eine große Anzahl von geänderten Dateien melden, die abgesehen von ihren Zeilenenden keine Unterschiede aufweisen. Um dies zu verhindern, können Sie die Konvertierung von Zeilenenden mit einer .gitattributes-Datei deaktivieren oder global auf der Windows-Seite.
Typischerweise ist das Hinzufügen oder Ändern einer .gitattributes-Datei in Ihrem Repository der zuverlässigste Weg, dieses Problem zu lösen. Das Committen dieser Datei in die Quellcodeverwaltung hilft anderen und ermöglicht es Ihnen, das Verhalten je nach Repository nach Bedarf anzupassen. Zum Beispiel erzwingt das Hinzufügen des Folgenden zu einer .gitattributes-Datei im Stammverzeichnis Ihres Repositories, dass alles LF ist, mit Ausnahme von Windows-Batchdateien, die CRLF benötigen
* text=auto eol=lf
*.{cmd,[cC][mM][dD]} text eol=crlf
*.{bat,[bB][aA][tT]} text eol=crlf
Beachten Sie, dass dies in Git v2.10+ funktioniert. Wenn Sie also Probleme haben, stellen Sie sicher, dass ein aktueller Git-Client installiert ist. Sie können andere Dateitypen in Ihrem Repository, die CRLF benötigen, zu derselben Datei hinzufügen.
Wenn Sie weiterhin immer Unix-Zeilenenden (LF) hochladen möchten, können Sie die Option input verwenden.
git config --global core.autocrlf input
Wenn Sie die Konvertierung von Zeilenenden vollständig deaktivieren möchten, führen Sie stattdessen Folgendes aus
git config --global core.autocrlf false
Schließlich müssen Sie möglicherweise das Repository erneut klonen, damit diese Einstellungen wirksam werden.
Gemeinsame Nutzung von Git-Anmeldeinformationen zwischen Windows und WSL
Wenn Sie HTTPS zum Klonen Ihrer Repositories verwenden und einen konfigurierten Anmeldeinformations-Helfer unter Windows haben, können Sie diesen mit WSL teilen, damit Passwörter, die Sie eingeben, auf beiden Seiten gespeichert werden. (Beachten Sie, dass dies nicht für die Verwendung von SSH-Schlüsseln gilt.)
Befolgen Sie einfach diese Schritte
-
Konfigurieren Sie den Anmeldeinformations-Manager unter Windows, indem Sie Folgendes in einer Windows-Eingabeaufforderung oder PowerShell ausführen
git config --global credential.helper wincred -
Konfigurieren Sie WSL so, dass derselbe Anmeldeinformations-Helfer verwendet wird, indem Sie Folgendes in einem WSL-Terminal ausführen
git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe"
Jedes Passwort, das Sie bei der Arbeit mit Git unter Windows eingeben, ist nun für WSL verfügbar und umgekehrt.
Behebung von Hängern bei Git-Push oder Synchronisierung von WSL
Wenn Sie ein Git-Repository über SSH klonen und Ihr SSH-Schlüssel eine Passphrase hat, können die Pull- und Sync-Funktionen von VS Code beim Remote-Betrieb hängen bleiben.
Verwenden Sie entweder einen SSH-Schlüssel ohne Passphrase, klonen Sie über HTTPS oder führen Sie git push von der Kommandozeile aus, um das Problem zu umgehen.
GitHub Codespaces Tipps
Für Tipps und Fragen zu GitHub Codespaces siehe die GitHub Codespaces-Dokumentation. Sie können auch die bekannten Einschränkungen und Anpassungen im Web überprüfen, die Ihre Codespaces beeinträchtigen können.
Erweiterungs-Tipps
Während viele Erweiterungen unverändert funktionieren, gibt es einige Probleme, die verhindern können, dass bestimmte Funktionen wie erwartet funktionieren. In einigen Fällen können Sie ein anderes Kommando verwenden, um das Problem zu umgehen, während in anderen Fällen die Erweiterung geändert werden muss. Dieser Abschnitt bietet eine Kurzübersicht über häufige Probleme und Tipps zur Behebung. Sie können auch den Hauptartikel über Erweiterungen auf Unterstützung der Remote-Entwicklung für eine ausführliche Anleitung zur Änderung von Erweiterungen zur Unterstützung von Remote-Erweiterungshosts konsultieren.
Behebung von Fehlern wegen fehlender Abhängigkeiten
Einige Erweiterungen sind auf Bibliotheken angewiesen, die in der Basisinstallation bestimmter WSL-Linux-Distributionen nicht gefunden werden. Sie können zusätzliche Bibliotheken zu Ihrer Linux-Distribution mit deren Paketmanager hinzufügen. Führen Sie für Ubuntu und Debian-basierte Distributionen sudo apt-get install <package> aus, um die benötigten Bibliotheken zu installieren. In der Dokumentation Ihrer Erweiterung oder der Laufzeitumgebung, die in der Fehlermeldung erwähnt wird, finden Sie zusätzliche Installationsdetails.
Lokale absolute Pfadeinstellungen schlagen fehl, wenn sie remote angewendet werden
Die lokalen Benutzereinstellungen von VS Code werden wiederverwendet, wenn Sie sich mit einem Remote-Endpunkt verbinden. Während dies Ihre Benutzererfahrung konsistent hält, müssen Sie möglicherweise absolute Pfadeinstellungen zwischen Ihrem lokalen Computer und jedem Host/Container/WSL variieren, da die Zielorte unterschiedlich sind.
Auflösung: Sie können Endpunkt-spezifische Einstellungen vornehmen, nachdem Sie sich mit einem Remote-Endpunkt verbunden haben, indem Sie den Befehl Einstellungen: Remote-Einstellungen öffnen aus der Befehlspalette (F1) ausführen oder den Tab Remote im Einstellungen-Editor auswählen. Diese Einstellungen überschreiben alle lokalen Einstellungen, die Sie haben, wenn Sie sich verbinden.
Lokale VSIX-Dateien müssen auf dem Remote-Endpunkt installiert werden
Manchmal möchten Sie eine lokale VSIX-Datei auf einem Remote-Computer installieren, entweder während der Entwicklung oder wenn ein Erweiterungsautor Sie bittet, einen Fix auszuprobieren.
Auflösung: Sobald Sie sich mit einem SSH-Host, Container oder WSL verbunden haben, können Sie die VSIX-Datei auf die gleiche Weise installieren wie lokal. Führen Sie den Befehl Erweiterungen: Von VSIX installieren... aus der Befehlspalette (F1) aus. Möglicherweise möchten Sie auch "extensions.autoUpdate": false zu settings.json hinzufügen, um automatische Updates auf die neueste Marketplace-Version zu verhindern. Weitere Informationen zur Entwicklung und zum Testen von Erweiterungen in einer Remote-Umgebung finden Sie unter Unterstützung der Remote-Entwicklung.
Browser öffnet sich nicht lokal
Einige Erweiterungen verwenden externe Node.js-Module oder benutzerdefinierten Code, um ein Browserfenster zu starten. Leider kann dies dazu führen, dass die Erweiterung den Browser remote anstelle von lokal startet.
Auflösung: Die Erweiterung kann die API vscode.env.openExternal verwenden, um dieses Problem zu lösen. Details finden Sie im Leitfaden für Erweiterungsautoren.
Zwischenablage funktioniert nicht
Einige Erweiterungen verwenden Node.js-Module wie clipboardy, um mit der Zwischenablage zu integrieren. Leider kann dies dazu führen, dass die Erweiterung falsch mit der Zwischenablage auf der Remote-Seite integriert.
Auflösung: Die Erweiterung kann zur Behebung des Problems auf die VS Code-Zwischenablage-API umstellen. Details finden Sie im Leitfaden für Erweiterungsautoren.
Lokaler Webserver kann nicht von Browser oder Anwendung aufgerufen werden
Beim Arbeiten innerhalb eines Containers, SSH-Hosts oder über GitHub Codespaces kann der Port, mit dem der Browser eine Verbindung herstellt, blockiert sein.
Auflösung: Erweiterungen können die APIs vscode.env.openExternal oder vscode.env.asExternalUri (die localhost-Ports automatisch weiterleiten) verwenden, um dieses Problem zu lösen. Details finden Sie im Leitfaden für Erweiterungsautoren. Als Workaround verwenden Sie den Befehl Port weiterleiten, um dies manuell zu tun.
Webview-Inhalte werden nicht angezeigt
Wenn der Webview-Inhalt der Erweiterung ein iframe verwendet, um eine Verbindung zu einem lokalen Webserver herzustellen, kann der Port, mit dem der Webview verbunden ist, blockiert sein. Wenn die Erweiterung außerdem vscode-resource:// URIs hartkodiert anstatt asWebviewUri verwendet, werden Inhalte im Codespaces-Browsereditor möglicherweise nicht angezeigt.
Auflösung: Die Erweiterung kann webview.asWebviewUri verwenden, um Probleme mit vscode-resource:// URIs zu lösen.
Wenn Ports blockiert sind, ist der beste Ansatz, stattdessen die API für Webview-Nachrichtenübertragung zu verwenden. Als Workaround kann vscode.env.asExternalUri verwendet werden, um dem Webview den Zugriff auf gestartete localhost-Webserver von VS Code zu ermöglichen. Dies ist jedoch derzeit für den browserbasierten Editor (nur) von Codespaces durch MicrosoftDocs/vscodespaces#11 blockiert. Details zum Workaround finden Sie im Leitfaden für Erweiterungsautoren.
Blockierte localhost-Ports
Wenn Sie versuchen, von einer externen Anwendung aus eine Verbindung zu einem localhost-Port herzustellen, kann der Port blockiert sein.
Auflösung: VS Code 1.40 hat eine neue API vscode.env.asExternalUri eingeführt, mit der Erweiterungen beliebige Ports programmatisch weiterleiten können. Details finden Sie im Leitfaden für Erweiterungsautoren. Als Workaround können Sie den Befehl Port weiterleiten verwenden, um dies manuell zu tun.
Fehler beim Speichern von Erweiterungsdaten
Erweiterungen versuchen möglicherweise, globale Daten zu speichern, indem sie auf dem Linux-System nach dem Ordner ~/.config/Code suchen. Dieser Ordner existiert möglicherweise nicht, was dazu führen kann, dass die Erweiterung Fehler wie ENOENT: no such file or directory, open '/root/.config/Code/User/filename-goes-here auslöst.
Auflösung: Erweiterungen können die Eigenschaft context.globalStorageUri oder context.storageUri verwenden, um dieses Problem zu lösen. Details finden Sie im Leitfaden für Erweiterungsautoren.
Anmeldung fehlgeschlagen / Anmeldung bei jeder neuen Verbindung erforderlich
Erweiterungen, die eine Anmeldung erfordern, können Geheimnisse mit eigenem Code speichern. Dieser Code kann aufgrund fehlender Abhängigkeiten fehlschlagen. Selbst wenn er erfolgreich ist, werden die Geheimnisse remote gespeichert, was bedeutet, dass Sie sich für jeden neuen Endpunkt anmelden müssen.
Auflösung: Erweiterungen können die SecretStorage API verwenden, um dieses Problem zu lösen. Details finden Sie im Leitfaden für Erweiterungsautoren.
Eine inkompatible Erweiterung verhindert die Verbindung von VS Code
Wenn eine inkompatible Erweiterung auf einem Remote-Host, in einem Container oder in WSL installiert wurde, haben wir Fälle gesehen, in denen der VS Code-Server aufgrund der Inkompatibilität hängt oder abstürzt. Wenn sich die Erweiterung sofort aktiviert, kann dies Sie daran hindern, sich zu verbinden und die Erweiterung zu deinstallieren.
Auflösung: Löschen Sie manuell den Remote-Erweiterungsordner, indem Sie die folgenden Schritte ausführen
-
Stellen Sie für Container sicher, dass Ihre
devcontainer.jsonkeinen Verweis auf die fehlerhafte Erweiterung mehr enthält. -
Verwenden Sie als Nächstes ein separates Terminal/eine Eingabeaufforderung, um sich mit dem Remote-Host, Container oder WSL zu verbinden.
- Wenn Sie SSH oder WSL verwenden, verbinden Sie sich entsprechend mit der Umgebung (führen Sie
sshaus, um eine Verbindung zum Server herzustellen, oder öffnen Sie ein WSL-Terminal). - Wenn Sie einen Container verwenden, identifizieren Sie die Container-ID, indem Sie
docker ps -aaufrufen und die Liste nach einem Image mit dem richtigen Namen durchsuchen. Wenn der Container gestoppt ist, führen Siedocker run -it <id> /bin/shaus. Wenn er läuft, führen Siedocker exec -it <id> /bin/shaus.
- Wenn Sie SSH oder WSL verwenden, verbinden Sie sich entsprechend mit der Umgebung (führen Sie
-
Sobald Sie verbunden sind, führen Sie
rm -rf ~/.vscode-server/extensionsfür VS Code Stable und/oderrm -rf ~/.vscode-server-insiders/extensionsfür VS Code Insiders aus, um alle Erweiterungen zu entfernen.
Erweiterungen, die vordefinierte native Module liefern oder erwerben, schlagen fehl
Native Module, die mit einer VS Code-Erweiterung gebündelt (oder dynamisch erworben) sind, müssen mit Electron's electron-rebuild neu kompiliert werden. Der VS Code-Server führt jedoch eine Standardversion (nicht-Electron) von Node.js aus, was dazu führen kann, dass Binärdateien bei der Remote-Nutzung fehlschlagen.
Auflösung: Erweiterungen müssen geändert werden, um dieses Problem zu lösen. Sie müssen beide Sätze von Binärdateien (Electron und Standard-Node.js) für die Node.js-"Module"-Version, die VS Code liefert, einschließen (oder dynamisch erwerben) und dann in ihrer Aktivierungsfunktion prüfen, ob context.executionContext === vscode.ExtensionExecutionContext.Remote gilt, um die richtigen Binärdateien einzurichten. Details finden Sie im Leitfaden für Erweiterungsautoren.
Erweiterung schlägt nur auf nicht-x86_64 Hosts oder Alpine Linux fehl
Wenn eine Erweiterung auf Remote-SSH-Hosts, Containern oder WSL unter Debian 9+, Ubuntu 16.04+ oder RHEL/CentOS 7+ funktioniert, aber auf unterstützten nicht-x86_64 Hosts (z. B. ARMv7l) oder Alpine Linux-Containern fehlschlägt, enthält die Erweiterung möglicherweise nur native Code- oder Laufzeitumgebungen, die diese Plattformen nicht unterstützen. Zum Beispiel enthalten die Erweiterungen möglicherweise nur x86_64-kompilierte Versionen von nativen Modulen oder Laufzeitumgebungen. Für Alpine Linux funktionieren die enthaltenen nativen Code- oder Laufzeitumgebungen möglicherweise aufgrund grundlegender Unterschiede zwischen der Implementierung von libc in Alpine Linux (musl) und anderen Distributionen (glibc) nicht.
Auflösung: Erweiterungen müssen sich für die Unterstützung dieser Plattformen entscheiden, indem sie Binärdateien für diese zusätzlichen Ziele kompilieren/einbeziehen. Es ist wichtig zu beachten, dass einige Drittanbieter-npm-Module auch nativen Code enthalten können, der dieses Problem verursachen kann. In einigen Fällen müssen Sie sich also mit dem Autor des npm-Moduls zusammenarbeiten, um zusätzliche Kompilierungsziele hinzuzufügen. Details finden Sie im Leitfaden für Erweiterungsautoren.
Erweiterungen schlagen aufgrund fehlender Module fehl
Erweiterungen, die sich auf Electron- oder VS Code-Basismoduln (nicht über die Erweiterungs-API verfügbar) verlassen, ohne einen Fallback bereitzustellen, können remote fehlschlagen. Sie sehen möglicherweise Fehler in der Entwicklertools-Konsole wie original-fs nicht gefunden.
Auflösung: Entfernen Sie die Abhängigkeit von einem Electron-Modul oder stellen Sie einen Fallback bereit. Details finden Sie im Leitfaden für Erweiterungsautoren.
Remote-Arbeitsbereichsdateien können nicht auf lokale Rechner zugegriffen oder übertragen werden
Erweiterungen, die Arbeitsbereichsdateien in externen Anwendungen öffnen, können Fehler verursachen, da die externe Anwendung nicht direkt auf die Remote-Dateien zugreifen kann.
Auflösung: Wenn Sie eine "UI"-Erweiterung erstellen, die lokal ausgeführt werden soll, können Sie die API vscode.workspace.fs verwenden, um mit dem Dateisystem des Remote-Arbeitsbereichs zu interagieren. Sie können dies dann zu einer Abhängigkeit Ihrer "Arbeitsbereich"-Erweiterung machen und sie bei Bedarf über einen Befehl aufrufen. Details zu verschiedenen Erweiterungstypen und zur Kommunikation zwischen ihnen finden Sie im Leitfaden für Erweiterungsautoren.
Auf das angeschlossene Gerät kann von der Erweiterung nicht zugegriffen werden
Erweiterungen, die auf lokal angeschlossene Geräte zugreifen, können keine Verbindung zu ihnen herstellen, wenn sie remote ausgeführt werden.
Auflösung: Derzeit keine. Wir untersuchen den besten Ansatz zur Lösung dieses Problems.
Fragen und Feedback
Probleme melden
Wenn Sie auf ein Problem mit einer der Remote-Entwicklungserweiterungen stoßen, ist es wichtig, die richtigen Protokolle zu sammeln, damit wir Ihnen helfen können, Ihr Problem zu diagnostizieren.
Jede Remote-Erweiterung hat einen Befehl zur Anzeige ihrer Protokolle.
Sie können die Protokolle der Remote-SSH-Erweiterung mit Remote-SSH: Protokoll anzeigen aus der Befehlspalette (F1) abrufen. Wenn Sie Remote-SSH-Probleme melden, überprüfen Sie bitte auch, ob Sie sich von einem externen Terminal (nicht mit Remote-SSH) mit Ihrem Computer verbinden können.
Ebenso können Sie die Protokolle der Dev Containers-Erweiterung mit Dev Containers: Containerprotokoll anzeigen abrufen.
Wie die beiden oben genannten können Sie die WSL-Erweiterungsprotokolle mit WSL: Protokoll anzeigen abrufen. Prüfen Sie auch, ob Ihr Problem im WSL-Repository verfolgt wird (und nicht auf die WSL-Erweiterung zurückzuführen ist).
Wenn Sie Probleme mit anderen Erweiterungen remote haben (z. B. andere Erweiterungen werden in einem Remote-Kontext nicht geladen oder ordnungsgemäß installiert), ist es hilfreich, die Protokolle aus dem Ausgabefenster Remote Extension Host (Ausgabe: Ausgabeansicht fokussieren) zu erhalten und Log (Remote Extension Host) aus der Dropdown-Liste auszuwählen.
Hinweis: Wenn Sie nur Log (Extension Host) sehen, handelt es sich um den lokalen Erweiterungshost, und der Remote-Erweiterungshost wurde nicht gestartet. Das liegt daran, dass der Protokollkanal erst erstellt wird, nachdem die Protokolldatei erstellt wurde. Wenn also der Remote-Erweiterungshost nicht startet, wurde die Protokolldatei des Remote-Erweiterungshosts nicht erstellt und wird nicht in der Ausgabeansicht angezeigt. Dies sind dennoch hilfreiche Informationen, die Sie in Ihr Issue aufnehmen sollten.
Ressourcen für Remote-Fragen und Feedback
Wir haben eine Vielzahl anderer Remote-Ressourcen
- Siehe Remote Development FAQ.
- Auf Stack Overflow suchen.
- Eine Funktionsanforderung hinzufügen oder ein Problem melden.