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.
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
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.
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.
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.
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.
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: <a href="https://tanguy.ortolo.eu/blog/article42/ssh-connection-sharing" rel="nofollow">https://tanguy.ortolo.eu/blog/article42/ssh-connection-shari... ), so handshakes don't make everything super slow
10000truths · · focus · HN ↗
bobtheborg · · focus · HN ↗
pstuart · · focus · HN ↗
K0IN · · focus · HN ↗
also "i just want to edit a config file and i want a nice ui", is how you get there.
doc_ick · · focus · HN ↗
jasomill · · focus · HN ↗
[1] <a href="https://code.visualstudio.com/docs/remote/remote-overview" rel="nofollow">https://code.visualstudio.com/docs/remote/remote-overview
brabel · · focus · HN ↗
jayd16 · · focus · HN ↗
Banditoz · · focus · HN ↗
Vegenoid · · focus · HN ↗
__float · · focus · HN ↗
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.
jasomill · · focus · HN ↗
stephbook · · focus · HN ↗
What more could you ask for?
dist-epoch · · focus · HN ↗
fcatalan · · focus · HN ↗
snailmailman · · focus · HN ↗
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.
infamousblah · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
lowbloodsugar · · focus · HN ↗
— <a href="https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh" rel="nofollow">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.
lxgr · · focus · HN ↗
mhitza · · focus · HN ↗
> [...] 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:
broken-kebab · · focus · HN ↗
frumiousirc · · focus · HN ↗
sl-1 · · focus · HN ↗
jlarocco · · focus · HN ↗