Hacker News Reader

Comment by 10000truths | Hacker News Reader

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.

View on HN

TRAMP (mentioned in the article) does it without installing anything on remote machine, just SSH, and shell commands. Which sounds more natural to me. Node.js security history, with all due respect, is not shiny. And the problem the author has with VSCode's way, I guess, is not that it can edit files, but that it extends attack surface without real need.

TRAMP actions are also rather slow (high latency). OTOH, tramp-rpc relies on a little tool to run on the remote and is much snappier. This proves there is a better middle ground than TRAMP with nothing and whatever abomination VSCode injects. Basically, busybox with a persistent RPC connection is all one needs.

Latency can be managed by having shared connections (for example: https://tanguy.ortolo.eu/blog/article42/ssh-connection-shari... ), so handshakes don't make everything super slow

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

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

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.

Expecting vscode to police every single dev using it instead of a company is bananas.

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] https://code.visualstudio.com/docs/remote/remote-overview

Aha, thanks for explaining it in terms I can understand !

Every dev with ssh keys into prod should know it.

The assumption being made is VSCode is not running on the prod machine.

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.

It didn't occur to me when I first read the article, but I do see now the author called it "remote editing" as you did too.

It may be worth more attention though. VSCode is not really remote editing (thick client, thin server binary), it'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.

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.

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

What more could you ask for?

Using Remote-SSH opens a connection between your local machine and the remote. Only use Remote-SSH to connect to secure remote machines that you trust and that are owned by a party whom you trust. A compromised remote could use the VS Code Remote connection to execute code on your local machine.

— https://marketplace.visualstudio.com/items?itemName=ms-vscod...

The issue is that the model can be the attacker, and use the link back to your host.

This really seems bananas. Why? What is the legitimate use case of the remote agent being able to run code on the local client's machine!?

Am I that much of? My reading of the following was that the remotely executed agent pushes commands back to your local vscode.

> [...] VSCode mounts a full-scale invasion: it runs a Bash snippet stager that downloads an agent, including a binary installation of Node. [...]

> It establishes a WebSockets connection back to your running VSCode front-end. The underlying protocol on that connection can:

The bananas part is that it dumps 500 MB of stuff on the remote side.

I just removed 5.5Gb of stale ~/.vscode-server from a dev VM

Oh wow I just checked my servers and on one the folder is 3.2GB and another has 1.7GB. It kind of looks like it just keeps copies of every version its ever installed? Theres several copies of node and `node_modules` folders.

I'm not super low on space but it also pretty clearly doesn't need to be that large, it looks like most of it is copies of itself.

Yeah, I learned how it worked when I made the mistake of trying to use it to develop on a Raspberry Pi, where it filled the disk and crashed/hung the Pi by using all the RAM until it started using swap. Fell back to local with an sshfs mount instead.

The idea that it needs to run an agent on the remote machine to edit files over SSH is itself bananas.

Reply on news.ycombinator.com