1 points par GN⁺ 2025-02-09 | 1 commentaires | Partager sur WhatsApp
  • 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

 
GN⁺ 2025-02-09
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

    • J’ai écrit brièvement sur le logiciel sur lequel nous travaillions
  • 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

    • Il y a le nom d’hôte et un document JSON encodé en hexadécimal
    • Si le nom d’hôte contient des majuscules, des informations supplémentaires sont nécessaires
    • La connexion SSH permet de configurer les extensions à installer sur le serveur. Mais si on en installe trop, on ne peut plus se connecter à un hôte Windows
  • 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

    • Je me demande si le problème est qu’une personne sur le même réseau puisse se connecter à un port transféré sans passer par SSH
    • En tant qu’utilisateur, j’apprécie que le système SSH de VSCode fonctionne bien
  • J’administre un serveur réseau, et le fait que les étudiants ne comprennent pas le client OpenSSH est un vrai problème

    • Je préviens les étudiants de ne pas utiliser le plugin de serveur distant de VSCode
    • Tous les étudiants qui utilisent plus de 100 Mo d’espace disque sont des utilisateurs de VSCode
    • J’ai fixé la limite de processus utilisateur à 45. Si les étudiants ignorent les avertissements, ils finissent par atteindre cette limite
    • J’utilise un script qui tue les processus .vscode-server toutes les 10 secondes
  • La fonctionnalité d’édition SSH de VSCode marche bien. Je n’utilise plus vim, nano ou micro sur les machines distantes

    • Le fait que l’agent n’interfère pas rend le travail plus facile
    • Il peut y avoir un risque de sécurité, mais l’expérience de développement est excellente
  • 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

    • SSH est une solution des années 90. C’est du Telnet avec quelques fonctionnalités en plus
    • Beaucoup de choses implémentées via SSH sont inefficaces
    • Nous n’avons pas créé les bons outils. Nous avons ajouté encore plus de fonctionnalités aux outils existants
  • 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

    • On peut exécuter tout l’environnement de développement à distance comme s’il était local
    • Cela peut transformer une vieille machine ou un thin client en poste de travail complet
    • La marketplace VSCode contient beaucoup de plugins qui constituent des menaces de sécurité. SSH Remote ou VS Tunnel n’en font pas partie
  • Autoriser l’édition distante de VSCode sur un serveur de développement me met mal à l’aise. Encore plus sur un serveur de production

    • Utiliser VSCode Remote sur un serveur de production, c’est de la folie
    • Les autres fonctions sont des comportements attendus
  • L’instance locale de VSCode devient un thin client, et l’instance distante prend en charge les tâches lourdes

    • C’est adapté quand on se connecte en SSH depuis un petit portable vers une station de travail puissante
    • Quand on se connecte en SSH depuis une station de travail puissante vers une petite VM/VPS, je recommande plutôt sshfs ou un autre montage de système de fichiers distant