Der SSH-Agent von VSCode ist absurd

• VSCode und Remote-Bearbeitung

  • VSCode verfügt über eine Funktion zur Remote-Bearbeitung per SSH.
  • Viele Nutzer verwenden VSCode zusammen mit LLMs (Large Language Models), um Code zu generieren.
  • Wenn ein LLM fehlerhaften Code erzeugt, spricht man von „Halluzinationen“. Um das zu beheben, ist es wichtig, über eine „Agent“-Konfiguration den Kreislauf zwischen LLM und Laufzeitumgebung zu schließen.
  • Dieser Prozess funktioniert so, dass das LLM Code erzeugt, der Agent ihn ausführt, Fehler erzeugt und diese an das LLM zurückmeldet, wodurch sich der Vorgang wiederholt.

• Probleme in der Entwicklungsumgebung

  • Es ist nicht wünschenswert, dass dieser iterative Entwicklungsprozess auf dem Notebook des Entwicklers stattfindet.
  • Da LLMs auch Auswirkungen auf die Systemkonfiguration haben können, ist es besser, solche Arbeiten auf einer Linux-Instanz in sauberem Zustand auszuführen.

• Emacs und Tramp

  • Emacs unterstützt Remote-Bearbeitung über das nützliche Elisp namens Tramp.
  • Tramp kann sich mit einer interaktiven Umgebung verbinden, in der sich Bourne-Shell-Befehle über eine SSH-Sitzung ausführen lassen.

• Der Ansatz von VSCode

  • VSCode bietet eine ähnliche Funktion wie Tramp, versucht bei Remote-Verbindungen aber im Unterschied zu Tramp eine weitreichende Infiltration.
  • Es führt einen Bash-Snippet-Stager aus, lädt einen Agenten herunter und umfasst die Installation von Node-Binärdateien.
  • Der Agent läuft über portweitergeleitetes SSH und ist per WebSockets mit dem VSCode-Frontend verbunden.
  • Das zugrunde liegende Protokoll dieser Verbindung kann das Dateisystem durchsuchen, beliebige Dateien bearbeiten, eigene Shell-PTY-Prozesse starten und Persistenz haben.

• Sicherheitsbedenken

  • Der unbedachte Einsatz von VSCode zur Remote-Bearbeitung auf Entwicklungsservern kann Probleme beim Schutz sensibler Informationen oder der Infrastruktur verursachen.
  • Besonders im tatsächlichen Produktionsumfeld besteht die Sorge, dass die Nutzung der VSCode-Remote-Bearbeitung im Problemfall sehr riskant ist.

• Fazit

  • Intern bei Fly.io ist ein derart komplexer Agent nicht zwingend erforderlich, um Fly Machine und VSCode direkt zu verbinden.
  • Für den Blog wurde jedoch untersucht, wie die Remote-Verbindung von VSCode funktioniert, und dabei wurden die oben genannten Fakten bekannt.

[GN⁺]

Hacker-News-Kommentare

• Ich wollte einen Monat lang einen langen Text über Software schreiben. Kurt macht sich Sorgen, weil er nichts im Blog veröffentlicht. Also habe ich beschlossen, etwas Kurzes zu schreiben. Das sollte in 30 Minuten zu schaffen sein.

  • Ich habe kurz über die Software geschrieben, mit der wir uns beschäftigt haben.

• Je mehr ich verstehe, wie VSCode funktioniert, desto mehr wirkt es wie mit Provisorien zusammengehalten. Schon die SSH-Erweiterung zeigt, dass Workspace-URIs zwei Formate haben.

  • Es gibt den Hostnamen und ein hexadezimal kodiertes JSON-Dokument.
  • Wenn der Hostname Großbuchstaben enthält, werden zusätzliche Informationen benötigt.
  • Bei SSH-Verbindungen kann man konfigurieren, welche Erweiterungen auf dem Server installiert werden. Installiert man aber zu viele, kann man keine Verbindung mehr zu Windows-Hosts herstellen.

• Ich verstehe das Sicherheitsproblem nicht. Wenn man sich per SSH auf eine Maschine verbinden und Sockets weiterleiten kann, kann man auch andere Dinge tun.

  • Ich frage mich, ob das Problem darin besteht, dass jemand im selben Netzwerk ohne SSH eine Verbindung zu einem weitergeleiteten Port herstellen kann.
  • Als Nutzer gefällt mir, dass das SSH-System von VSCode gut funktioniert.

• Ich betreibe einen Netzwerkserver, und ein großes Problem ist, dass Studierende den OpenSSH-Client nicht verstehen.

  • Ich weise die Studierenden darauf hin, das VSCode-Remote-Server-Plugin nicht zu verwenden.
  • Studierende mit mehr als 100 MB Plattennutzung sind ausnahmslos VSCode-Nutzer.
  • Ich habe das Limit für Nutzerprozesse auf 45 gesetzt. Wenn die Studierenden die Warnungen ignorieren, laufen sie in das Prozesslimit.
  • Ich verwende ein Skript, das alle 10 Sekunden die .vscode-server-Prozesse beendet.

• Die SSH-Bearbeitungsfunktion von VSCode funktioniert gut. Dadurch muss ich auf der Remote-Maschine weder vim noch nano noch micro verwenden.

  • Der Agent stört nicht, dadurch arbeitet es sich leichter.
  • Es mag ein Sicherheitsrisiko geben, aber die Developer Experience ist hervorragend.

• Ich habe gelernt, dass Remote-Code-Ausführung möglich ist. Falsches Vertrauen in Entwicklerwerkzeuge führt oft zu Reue.

  • SSH ist eine Lösung aus den 90ern. Im Grunde ist es Telnet mit ein paar zusätzlichen Funktionen.
  • Vieles, was über SSH umgesetzt wird, ist ineffizient.
  • Wir haben keine passenden Werkzeuge gebaut. Stattdessen haben wir bestehenden Werkzeugen immer mehr Funktionen hinzugefügt.

• Der Begriff „SSH-Agent“ ist verwirrend. Normalerweise bezeichnet er einen Daemon, der Authentifizierungs-Tokens im Cache hält.

• Leute, die sshfs empfehlen, verstehen die Vorteile der VSCode-SSH-Remote-Umgebung nicht.

  • Man kann die komplette Entwicklungsumgebung remote ausführen, als wäre sie lokal.
  • Damit lassen sich alte Maschinen oder Thin Clients in vollständige Workstations verwandeln.
  • Im VSCode-Marktplatz gibt es viele Plugins, die ein Sicherheitsrisiko darstellen. SSH Remote oder VS Tunnel gehören nicht dazu.

• Es fühlt sich unangenehm an, Remote-Bearbeitung mit VSCode auf Entwicklungsservern zuzulassen. Auf Produktionsservern erst recht.

  • VSCode Remote auf Produktionsservern zu verwenden, ist völlig verrückt.
  • Die anderen Funktionen sind erwartbares Verhalten.

• Die lokale VSCode-Instanz wird zu einem Thin Client, während die Remote-Instanz die schwere Arbeit übernimmt.

  • Das passt gut, wenn man von einem kleinen Notebook per SSH auf eine leistungsstarke Workstation zugreift.
  • Wenn man von einer leistungsstarken Workstation per SSH auf eine kleine VM/VPS zugreift, würde ich sshfs oder das Einrichten eines anderen Remote-Dateisystem-Mounts empfehlen.