VSCode's SSH agent is bananas

I have been for like a month now noodling on a long-form post about a piece of software we've been noodling with for 3-4 years now. Kurt is freaking out, because we haven't written anything on the blog since, like August. Finally I'm like, look, I will write the simplest thing I can come up with. We'll do the opposite of what we've been doing. We'll do anti- effortposts. I bet I can do one in 30 minutes.

I promise, I thought about this less than you have. It's a thing we were tinkering with, and I wrote about it. That's all.

VSCode is an IDE designed to suffocate the open source alternatives, so that they retain full strategic control. Oh, and it also promotes their tech (Copilot, Github, C#, TypeScript). It's a long list of issues.

It works well though, particularly over SSH and devcontainers, although it has severe bugs that they refuse to fix, and it isn't open source so you can't fix it yourself.

I wish software was secure by design, like browsers are. But it just isn't a business priority, because consumers have so little to lose. And enterprise customers have strict environments, separate staging/production environments that reduce blast radius, and so on, so the insecurity is tolerable. Besides, employees can't be trusted anyway, so what's the point of having a very secure IDE if they immediately run curl|sudo bash.

Are there any good web-based alternatives? (like Runpod's openvscode-server)

This is going to sound naive but, I don't understand what the security issue is. If you can ssh into a machine and port forward a socket, you already have permission to do all the other things. VSCode's protocol seems to be exposing it in way that's more convenient for them.

How is this a security problem? Is it because someone on the same network as the remote machine but without SSH access can connect the port that is forwarded over SSH?

As a user, I quite like how well VSCode's SSH system works.

I ran the servers for our networks, binary exploitation, and intro systems programming classes, and this thing is a major annoyance. It is because of this stupid RAT that students do not understand how to use the OpenSSH client.

I've tried a few things to fix this: 1., I set a motd on our class servers asking the students not to use the VSCode remote server plugin. 2. I ran `ncdu /home` in front of the class and demonstrated how, without exception, everyone with >100MB of disk usage on the class server was a VSCode user. 3. I set a user process limit of 45, because the VSCode RAT (somehow) uses ~50 Node processes. When students inevitably ignored the motd and the in-class warning, they hit the process cap and had to ask us to kill their processes in order to get back onto the system. 4. I replaced the process limit with a script that kills all the .vscode-server RATs every 10 seconds.

I don't know what the alternative would be here. VSCode's SSH edit works surprisingly well, and I stopped fiddling with vim, nano, or micro on my remote machines long ago.

The agent gets out of my way and lets me work in peace. It almost feels like I'm working from my local machine—a huge win in my book.

This could be a security risk, but the development experience is unmatched. I couldn't care less which other editor VSCode is killing, as I mostly don't care about my tools as long as they get out of the way and let me do my job.

Instead of working with existing remote tools it deploys a comprehensive agent that includes:

A Node.js binary installation. A WebSocket connection back to the VSCode frontend. Extensive system access capabilities.

The VSCode agent has broad permissions including:

File system navigation. File editing capabilities. Shell PTY process creation. Self-persistence abilities.

"SSH agent" is a confusing term to use here, because it usually stands for a daemon that caches authentication tokens.

The proper name for this functionality is Visual Studio Code Remote - SSH (https://code.visualstudio.com/docs/remote/ssh), and it's VSCode's killer feature. With this plugin, VSCode is the first IDE to properly implement the remote IDE paradigm.

When VSCode connects to the remote using the plugin, it installs an entire VSCode server - seamlessly to the user every time they connect to a remote - that keeps track of all project facilities, shells, extension accessory runtimes, takes care of embedded or computationally heavy tasks like compiling, building, running project-wide code analysis tools, etc. while keeping all settings, editor windows, and accessory panes local (which is critical for UX and latency). VSCode appropriately partitions responsibilities between the local and the remote, automatically restores IDE infrastructure on the remote as needed, and enforces the partitioning architecturally for all extensions.

This architecture is not an accident - it's rooted in VSCode's origin as a browser-based IDE, and makes use of the LSP and other features that don't exist in Emacs/TRAMP because nobody really thought deliberately about running the extensions at an arm's length from the editor UI in Emacs, using an async protocol that doesn't allow extensions to impact core UI latency. But the flipside is that the "client" part I described above does place a lot of trust in the "server" part, just as you might expect a browser-based application to do.

Whether you consider this architecture bananas or not depends on your security model. It's probably not the best idea to let people SSH to production using this plugin. If you are trying to rely on it to partition a novel AI tool away from part of your infrastructure, yeah, it wasn't really meant for that. The plugin predates agentic AIs by 5+ years. But it's an incredibly powerful and useful feature. I don't think taking cheap shots against it is helpful when the actual bananas thing is trying to use it in a way it was not intended for.

The way most people learned this is because somewhere in the middle of last year, VSCode's node install stopped working with the old glibc.

https://github.com/microsoft/vscode/issues/201129

Most people who hit this hard pinned their vscode to 1.85 & it took a while till this turned into a simple nag bar on top of their editor.

> I would be a little nervous about letting people VSCode-remote-edit stuff on dev servers, and apoplectic if that happened during an incident on something in production.

Totally agree that using vscode remote on production servers is insane.

Everything else described as "bananas" sounds like expected functionality.

I've reached a level (staff engineer at MAANG) that I consider to be difficult to obtain using plain old Vim, and I've noticed that other high performers tend to still use Vim or Emacs. There's plenty of amazing developers who use VCode, JetBrains, etc. but I think there are certain personality traits - seeks out barriers to entry, likes to demagic tools through exploration, values completely open source, highly tinkerable community driven projects, etc. that explain this phenomenon more than feature set or ease of use.

When I read about how complicated VSCode's remote editing was (which I knew about before this article) it just made me want to use VSCode less. I can just ssh into a machine and use whatever editor is on the machine. VSCode's solution works, but it's also not nearly as elegant or universally applicable, and is more prone to breaking.

Also, Tramp is still quite awful, sorry Emacs users (netrw isn't any better).

Reminds me of Jenkins (the CI system) remote agent.

One would expect a remote agent with well-defined capabilities: read/write/delete files and directories; run the process with stdout/stderr capture; stop the running process started in previous item.

Instead, there is a generic bytecode executor, and Jenkins controller ships out Java bytecode to be executed remotely. Crazy stuff.