L’agent SSH de VSCode est absurde
(fly.io)-
VSCode et l’édition à distance
- VSCode dispose d’une fonctionnalité prenant en charge l’édition à distance via SSH.
- De nombreux utilisateurs s’appuient sur VSCode et les LLM (grands modèles de langage) pour générer du code.
- Lorsque les LLM génèrent du code erroné, on parle d’« hallucination », et pour y remédier, il est important de fermer la boucle entre le LLM et l’environnement d’exécution via un paramétrage d’« agent ».
- Ce processus fonctionne de manière itérative : le LLM génère du code, l’agent exécute le code, produit des erreurs, puis les renvoie au LLM comme retour afin de recommencer.
-
Problèmes dans l’environnement de développement
- Il n’est pas souhaitable que ce processus de développement itératif se déroule sur le laptop du développeur.
- Comme le LLM peut aussi affecter la configuration du système, il vaut mieux effectuer ce travail sur une instance Linux propre.
-
Emacs et Tramp
- Emacs prend en charge l’édition à distance via un Elisp utile appelé Tramp.
- Tramp peut se connecter, via une session SSH, à un environnement interactif capable d’exécuter des commandes shell Bourne.
-
L’approche de VSCode
- VSCode offre une fonctionnalité similaire à Tramp, mais contrairement à Tramp, il tente une intrusion beaucoup plus globale dans la connexion distante.
- Il exécute un stager d’extraits Bash pour télécharger l’agent, y compris l’installation des binaires de Node.
- L’agent fonctionne via du SSH avec redirection de ports et se connecte au frontend de VSCode par une connexion WebSockets.
- Le protocole de base de cette connexion permet d’explorer le système de fichiers, de modifier des fichiers arbitraires, de lancer son propre processus shell PTY et de disposer d’une persistance.
-
Préoccupations de sécurité
- Utiliser sans discernement VSCode pour l’édition à distance sur un serveur de développement peut poser des problèmes pour les informations sensibles ou la protection de l’infrastructure.
- On s’inquiète en particulier du fait qu’utiliser l’édition à distance de VSCode lorsqu’un problème survient en environnement réel (production) soit extrêmement risqué.
-
Conclusion
- En interne chez Fly.io, ce type d’agent complexe n’est pas forcément nécessaire pour relier directement une Fly Machine à VSCode.
- Cependant, c’est dans le cadre d’un billet de blog que l’équipe a enquêté sur le mode de connexion à distance de VSCode, et a découvert les éléments ci-dessus au cours de cette enquête.
1 commentaires
Avis Hacker News
J’essayais d’écrire un long article sur un logiciel depuis un mois. Kurt s’inquiète de ne rien publier sur son blog. J’ai décidé d’écrire quelque chose de simple. Ça devrait pouvoir se faire en 30 minutes
Plus j’en apprends sur le fonctionnement de VSCode, plus j’ai l’impression que ça tient avec des rustines. Rien que l’extension SSH a deux formats d’URI d’espace de travail
Je ne comprends pas bien le problème de sécurité. Si on peut accéder à une machine en SSH et faire du port forwarding de socket, on peut aussi faire bien d’autres choses
J’administre un serveur réseau, et le fait que les étudiants ne comprennent pas le client OpenSSH est un vrai problème
.vscode-servertoutes les 10 secondesLa fonctionnalité d’édition SSH de VSCode marche bien. Je n’utilise plus vim, nano ou micro sur les machines distantes
J’ai appris qu’il était possible d’exécuter du code à distance. Une confiance mal placée dans les outils de développement mène souvent à des regrets
Le terme « agent SSH » prête à confusion. En général, il désigne un daemon qui met en cache des jetons d’authentification
Les gens qui recommandent sshfs ne comprennent pas les avantages de l’environnement VSCode SSH Remote
Autoriser l’édition distante de VSCode sur un serveur de développement me met mal à l’aise. Encore plus sur un serveur de production
L’instance locale de VSCode devient un thin client, et l’instance distante prend en charge les tâches lourdes