VSCode's SSH Agent Is Bananas (2025)

VSCode's SSH Agent Is Bananas (2025)fly.io

Documentation and guides from the team at Fly.io.

310 points•Rapzid•7 days ago•217 comments•

#agent #ssh #vscodes #bananas #ssh agent #vscodes ssh #vscodes ssh agent #documentation

217 comments

Missing a (2025)

FYI VSCode's SSH Agent is a godsend for remote development - the "disadvantages" that Fly lists are part of its advantages. I've worked in several teams that have made extensive use of the extension, and it's never been an issue. You can restrict SSH access arbitrarily to ensure whatever security or access guardrails you need.

godelski7 days ago

As a Linux user I've hated VSCode's ssh. There's lot of annoying things that make it harder to admin for. Like it doesn't pick up the MotD, preventing me from showing users important messages. I've found that it also doesn't reuse sessions (at least by default. TBF, neither does ssh) and I'll find that there's just dozens of open sessions over months from users. I literally had to write a script to boot people...

It would be one thing if the plugin was just a wrapper and people were still expected to know ssh but the plugin abstracts away all that and is intended to make it a "use VSCode on remote machine" tool. So it needs to do more than just handle creds, otherwise it creates a divergent experience while making people think it's just ssh

throw0101a7 days ago

> There's lot of annoying things that make it harder to admin for.

It also (AIUI) tries to walk the entire file tree, so have fun with NFS (auto)mounts.

It also amounts to letting off fork bombs: we set up limits for a maximum of 256 process per UID, and regularly get folks asking "what does this 'cannot fork' message mean?": it mean you're trying to DoS the system.

Joker_vD7 days ago

I don't think I've ever paid attention to a MotD on any of the servers I had a ssh access to... what do people put there?

causal7 days ago

And it’s really opaque. Would be fine if it were an open source package but there’s a lot of mystery behind how it’s implemented.

w4der7 days ago

The one this that is better than just SSH+Tmux+Vim, is that if your latency is higher than 30-50ms, since VSCode's SSH agent streams the files to your computer, the typing experience feels snappier. When you work half a continent away from where the servers are, it makes life nicer.

shadowgovt6 days ago

This is the first time I've seen anyone assume that anyone ever reads the MotD anymore since approximately 2002.

No snark: does your org also regularly check the mail spool and expect individual users to do so as well?

DanielHB7 days ago

I have been using VSCodium (chromium-like version of VSCode) with this extension:

https://github.com/jeanp413/open-remote-ssh

I run the editor (and its extensions), my projects and any agent harnesses from inside a container and use that extension to get an editor.

This is mostly to protect my credentials and data from malicious extensions/dependencies/rogue-agents, bu it also lets me quickly port my dev environment to any machine (I use linux at home and macos at work). Just install podman, install VSCodium, add the SSH extension, build image, add my utility shellscripts (to quickly get in and out of the container in a shell) and done.

Apparently Microsoft keep some VSCode APIs proprietary so only its own extensions can use it (allegedly for security reasons), which is why this specific extension only works in VSCodium. I wonder if it is vulnerable to the same things the article points out.

qweqwe147 days ago

I used VSCodium before and found it to be a massive waste of time for no benefit. A significant number of extensions either aren't in OpenVSIX (or whatever it's called), or don't work for some reason. Just disable telemetry in VSCode and you're good.

Happy Ungoogled Chromium user though

tyingq7 days ago

Also: https://news.ycombinator.com/item?id=49824802

modeless7 days ago

Yeah this is the right architecture for remote editing with remote tools. It works really well. (There are longstanding bugs around reconnection when the SSH connection is broken but that's not the fault of the architecture.)

neuroticnews257 days ago

It's unusable on low end 512MB RAM VPS servers because someone decided bundling whole node runtime for file operations is a good idea.

cozzyd6 days ago

It also fills up the hard drives on shared server, where each user up to 5 GB of vscode nonsense.

Also, I realized that students are likely to use vscode to connect to embedded Linux machines and fill up their emmcs (and RAM), so I came up with a partial solution for our experiment's yocto image (https://github.com/RNO-G/meta-rno-g/blob/main/recipes-suppor...) , but a more general solution would be nice. Probably better to just not allow any node process to run via LSM.

xg157 days ago

Also using it, and by now at least I see the reason why they did it. VSCode has a large plugin ecosystem, many which are essential for development. The problem is that those plugins don't know anything about remote development and expect to use the standard file system and OS APIs to interact with the workspace.

So how to make the plugins remote-capable? You could write a massive virtualization layer that captures all system calls and forwards them to the remote - or, you could run the plugin on the remote and just pass the user commands and UI updates over the connection.

VSCode does the latter, so the nodejs runtime is where all the plugins are running on the remote.

(I understood the reason, I didn't say it was a good reason...)

memco6 days ago

It also has some unfortunate OS / glibc minimums which means that it's growing less useful as time goes on. I work on a lot of machines that are from centos 7 era (including amazon linux 2, which doesn't have an upgrade path: you just have to build a whole new instance and migrate). I have had to pin my vscode + extensions to old versions because it works on older machines. They just stopped supporting platforms (with lots of notice; to be fair). I would love if they had a binary tool that could be built which was much more agnostic to the vscode / extension version so that I could just keep using it everywhere I've been using it, while allowing me to keep current with the latest and greatest.

At least when Python minimum version changed there was a separate extension forked from the original that I can use when I need to work on old code alongside the new extension for more modern code bases. Sadly, no such thing exists for remote editing that I know of.

Rapzid7 days ago

Nothing has changed as far as the insecurity the article has outlined.

The problem is the remote host has control over local host through the protocol.

10000truths7 days ago

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.

broken-kebab7 days ago

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.

frumiousirc7 days ago

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.

bobtheborg7 days ago

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

jasomill7 days ago

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.

pstuart7 days ago

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

stephbook7 days ago

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

What more could you ask for?

lowbloodsugar7 days ago

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.

lxgr7 days ago

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!?

mhitza7 days ago

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:

dist-epoch7 days ago

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

infamousblah7 days ago

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.

fcatalan7 days ago

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

qwertox7 days ago

  2026-09-24 09:35:24 dev ~ du -h -d 0 .vscode-server
  6.0G    .vscode-server

This is what makes it bananas for me. I don't know what Microsoft is thinking if they allow this.

fransje267 days ago

> I don't know what Microsoft is thinking if they allow this.

First time?

isoprophlex6 days ago

Try installing the azure cli into a docker image. Hope you enjoy having 2 GB of python interpreters around

binlog7 days ago

The agent is supposed to run on a remote dev box. The purpose is to make the remote machine an extension of your local one, to run extensions, containers, install packages, test deployments, forward ports and tons more. Tunneling is part of the feature set. If you are installing it on production servers and are surprised by its behavior that’s on you.

angry_octet7 days ago

It also makes your local client an extension of the remote box. That is going directly against expectations for remote access.

not_a_bot_4sho7 days ago

It's right there though:

> # Security Note > > 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.

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

Big bold text and everything

afiori7 days ago

I think it is so that the server extensions can do stuff on the client, imo the weirder part is that it installs a bunch of stuff on the remote

MajesticHobo27 days ago

This part of VSCode's architecture is acceptable to me. The reverse direction, where a compromised remote can do whatever it wants to my local machine, is not.

devonbleak7 days ago

it does the reverse direction also. there's a security note indicating such on the remote ssh vscode extension page https://marketplace.visualstudio.com/items?itemName=ms-vscod...

Security Note 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.

Rapzid7 days ago

The part you find unacceptable is the entire point of the article..

MajesticHobo26 days ago

Is it? I've read the article twice (yesterday when you posted it and last year when it was first published), and that was not my interpretation.

Read the full thread on Hacker News →

217 comments

Related stories