Thread

1. 10000truths · 1790201673 · focus · HN ↗

   So a program that is specifically designed to edit files and run arbitrary commands on a remote machine... can do so. Not sure where the bananas part comes in. Sending a binary over SSH/SFTP might sound weird at first glance, but VSCode can't assume that your remote machine can access the wider internet, and it needs a reliable way to bootstrap the agent on the remote. Shipping it over the SSH tunnel is the natural solution.

   1. bobtheborg · 1790202393 · focus · HN ↗

      I think the actual concern, not well expressed in the blog post, is the fact that node and vscode server are installed on, for instance, a prod machine that (probably) should be very tightly controlled in terms of what software is installed and running. You don't want to unwittingly add to the attack surface

      1. pstuart · 1790202529 · focus · HN ↗

         Fair enough, but running VSCode on a prod machine is also bananas.

         1. K0IN · 1790202746 · focus · HN ↗

            agree, but do you think every dev you know konws this?

            also "i just want to edit a config file and i want a nice ui", is how you get there.

            1. doc_ick · 1790203560 · focus · HN ↗

               Expecting vscode to police every single dev using it instead of a company is bananas.
            2. jasomill · 1790212772 · focus · HN ↗

               The very first page[1] of the VSCode remote documentation makes it perfectly clear that VSCode remoting is more akin to running an Emacs server on the remote than TRAMP.

               [1] <a href="https:&#x2F;&#x2F;code.visualstudio.com&#x2F;docs&#x2F;remote&#x2F;remote-overview" rel="nofollow">https:&#x2F;&#x2F;code.visualstudio.com&#x2F;docs&#x2F;remote&#x2F;remote-overview

               1. brabel · 1790250340 · focus · HN ↗

                  Aha, thanks for explaining it in terms I can understand !
            3. jayd16 · 1790264883 · focus · HN ↗

               Every dev with ssh keys into prod should know it.
         2. Banditoz · 1790202919 · focus · HN ↗

            The assumption being made is VSCode is not running on the prod machine.
         3. Vegenoid · 1790203084 · focus · HN ↗

            Yes, and now we are full circle: what is (allegedly) bananas is that using VSCode’s remote edit feature has the potentially surprising and unintuitive behavior of installing a VSCode agent on the target machine.

            1. __float · 1790208041 · focus · HN ↗

               It didn&#x27;t occur to me when I first read the article, but I do see now the author called it &quot;remote editing&quot; as you did too.

               It may be worth more attention though. VSCode is not really remote editing (thick client, thin server binary), it&#x27;s setting up a development environment (compilers, LSPs, editor extensions, etc.) on a remote thing (VM, container) that you access with a thin VSCode shell.

               If you want to quickly edit a config file on a remote machine, TRAMP seems great. VSCode Remote SSH is not meant for that.

      2. jasomill · 1790211939 · focus · HN ↗

         This should be covered by not giving developers SSH shell or equivalent access to production machines in the first place, or at the very least to have measures in place (ACLs, quotas, etc.) to strictly limit what they are able to do from the shell.
      3. stephbook · 1790226844 · focus · HN ↗

         Pre-Download a known good VSCode server binary. VSCode will detect and use it.

         What more could you ask for?

Unofficial Hacker News client; not affiliated with Y Combinator.