VSCode’s SSH agent is bananas

Thanks for the post. I see now that it's bananas, but I didn't quite get that from the blog post. You list the things this agent can do, but I immediately assumed it went in the other direction, because anything else would be bananas. The statement in the README put it more succinctly for me:

> A compromised remote could use the VS Code Remote connection to execute code on your local machine.

I feel like that "security note" should have a CVE number next to it.

That first paragraph (in your HN comment, not the blog post) would have read better with zero periods.

Glad to see one of my favorite blogs is still active. I was starting to get a little worried.

The first two blogs currently listed, McCord-Valim’s FLAME-Livebook-GPU and your post which has the word “murid”, truly captures the psychological arc of a developer.

Thanks!

More low effort posts please!

It seems like ssh may be the problem. I feel like there should be a way to ask for a docker like experience when ssh ing. Tell it to use is specific APIs to prevent process or filesystem access outside a particular folder (possibly allowing system binaries, although that might complicate things and require vscode to push more stuff to client). Basic googling indicates some choot options in the ssh server but nothing is mentioned on 5he ssh client man page.

Although maybe the solution is to download a docker container on the remote (directly if it has access to dockehub or over an ssh connection if it doesn't) then run a docker container mounting the remote directory and connect to it over ssh.

The problem with only syncing files from the subdirectory is that you also want to be able to run &debug on the remote started by vscode. So plugins also need access to remote or to run remotely for some code observation that may be prohibitively expensive if run locally(pre sync of whole subdir)

« we’ve decided to just be a blog again, so: we had to learn this, and now you do too. »

This is, indeed, the way.

Good writing and fun, congrats! Is there a semi-hidden Monty Python reference in the middle?

Absolutely hilarious. My partner and I have this same conversation every two weeks.

You have definitely covered noodling

I don't know, I found VS Code to be nicer than Eclipse. I've never had a need for SSH through an IDE, so I can't speak to that. Usually I'd just SSH through putty and use Vi if I need to do stuff on the server.

I like it because it’s really easy to extend the editor with custom language support/tooling if you know JavaScript/Typescript. Providing custom completions, diagnostics, etcetera. I can also provide custom Go to definitions for cross-language support.

> The more I learn about how VSCode works ...... duct tape

The most unfortunate few lines. [0]

I wish Microsoft would hire me for a couple months to do nothing but sit in a corner by myself untangling this mess.

[0] https://github.com/microsoft/vscode/blob/6dbde2a3ed308f88164...

It’s shit and string. Gone back to vim.

I think the difference is that what VSCode is doing is not an SSH Session like you get in a terminal with the ssh command or putty.

VSCode is installing a remote agent on the target machine that happens to use ssh as its transport protocol, and offers to share that transport with the user.

Is this a problem? Not if it only does things you want it to do. However any agent based system exposing an arbitrary API is suddenly a much bigger attack and risk surface area than the well trod (and still fraught) path of emulating a terminal over ssh.

This is the relevant part:

> The agent runs over port-forwarded SSH. It establishes a WebSockets connection back to your running VSCode front-end. The underlying protocol on that connection can:

- Wander around the filesystem - Edit arbitrary files - Launch its own shell PTY processes - Persist itself

When you ssh into a remote server as a client, afaik that server cannot execute arbitrary code on the client. At a minimum, the client would have to explicitly take action for that to happen.

I think you’re basically right: it’s not a security problem in that it doesn’t inherently traverse any vulnerabilities or security boundaries.

But it is a security problem in the same way that “curl | bash” is a security problem. An even closer equivalence might be something like “curl | bash” in your bashrc.

The agent on the dev server is now a vector back to VS Code on your laptop.

The agent is networked and running all the time so a hole on the dev server’s firewall is now a hole in your laptop’s firewall.

> you already have permission to do all the other things

Of course. The problem is that a 3rd party agent can now use your permission to do what it wants, and you will be none the wiser.

It's helpful for evading detection, because if you've compromised a machine, you can drop in the server binary and it'll have been added to the allowlist for devs to run.

> If you can ssh into a machine and port forward a socket, you already have permission to do all the other things.

Only technically. There are lots of situations where people (or robotic alarm bells) will be miffed if you instal your custom sw stacks, remote shells, "i don't know what these binaries are" etc on some servers you're supposedly just editing config files on.

A piece of software that is ostensibly trying to help you is gathering information without your knowledge and.. one of these days may upload it to the mothership? That's kinda not ok don't you think?

Your comment is bringing back so many memories of being in university and working around the anachronistically strict limits the uni sysadmins had on the network

This isn't something specific to VSCode being popular. When I was in college over a decade ago, there were students using Sublime with an SFTP plugin, coding locally and copying stuff with FileZilla or other similar GUI clients to transfer files (I distinctly remember seeing some program that was named something duck-related but for the life of me I can't remember any other specifics). Sublime in particular could be frustrating in the class I TA'd where they had some assignments to deal with processing some (very basic) machine code to simulate running the tool the class used to assemble and run the code from the (similarly basic) ISA they had been taught, which involved them using hexdump or something similar to understand how the bytes in the files worked, but Sublime "helpfully" would render the object files as as their text representation of the hexdump, with extra spacing for readability and swapped endianness compared to the way the bytes would show up if hexdumped on the school's Linux server. There would always be several students every semester who would show up at office hours unable to figure out why their code that was written to try to read an ASCII string like "AD DE EF BE " but instead would instead find some text they didn't recognize because they didn't think to look at the actual byte values, which would always just happen to start with 0xDE, 0xAD, 0xBE, and 0xEF.

Can you explain why though? I get that you had to put a lot of effort into blocking VSCode but it's not clear what have VSCode caused to motivate this.

>50 Node processes

Every day we stray further from God.

For those like me who were wondering what "murid" was referring to and had never heard of RAT, it stands for Remote Access Trojan.

> 1., I set a motd on our class servers asking the students not to use the VSCode remote server plugin. ...When students inevitably ignored the motd...

VSCode doesn't show the motd :/

Disable TCP forwarding in SSHD

This was a major annoyance, so you descided to become an even bigger one?

The alternative is suggested by tramp, which from what I know treats the remote as a network filesystem instead of an execution host. I don't believe that tramp deploys any binaries: it reads and writes bytes over pipes and all meaningful execution happens locally. Notably, it does not achieve persistence, because there's a difference between "VSCode plugins have access while you're SSH'd in" and "VSCode plugins have access forever".

The security risk comes from all those unvetted plugins, that have unrestricted access to the editor.

From what I’ve seen, my colleagues using vscode are hampered in ways they don’t recognize because they have no concept of how good things could be. Working with multiple remotes, they’re often completely unaware of which one they’re connected to or what state their connection is in. Their terminals are laggy and session state persistence is inconsistent. It’s just a massively worse experience than tmux + a real text editor. Plus the server is a real pig and they often end up running half a dozen server instances because the server doesn’t terminate properly. And then, half the updates break and they lose an hour because they don’t know how to ssh into the host with a real ssh client and clean up the busted vscode server.

> I don't know what the alternative would be here

I'm not sure what features VSCode offers exactly, but I find sshfs works quite well for remote editing of a bunch of stuff. I think it should basically be the same as VSCode?

> I don't know what the alternative would be here.

Emacs' TRAMP is pretty crap but still more reliable and user-friendly than the hot mess of VSCode remote editing.

Me, me, me, got it. Unfortunately there are other folks in the world. ;-)

Students need to focus on fundamentals, not the fanciest automatic whiz-bang tools available. Why we learn arithmetic before allowing calculators.

It's not the developers who did this, it's the "network security" people. If you block all outgoing ports except for HTTPS and ssh, everything is henceforth going to be tunneled over HTTPS or ssh.

This is also the reason why, if you allow outgoing HTTPS connections, you should as a general rule be allowing all outgoing connections except for SMTP. Because actually malicious traffic is just going to be tunneled over HTTPS anyway and all you're doing is inhibiting the deployment of any new protocols that don't take on the complexity and inefficiency of the tunnel.

To the contrary, i find the ssh keypair authentication (and certificates) the best kind of authentication i know. And it integrates with FIDO2 without prior set up.

I wish web logins would be more like what SSH does.

Man, I'm getting hard tinfoil conspiracy vibes from this one. Not everything in life is done with malicious intent. Most of the time it's humans trying to do the best they can come up with under pressure.

Maybe go touch some grass once in a while, it's healthy for the soul.

Also, please make a suggestion on how to build a better SSH protocol. Complaints are kind of useless without constructive criticism.

Agreed, because VSCode does not provide an SSH Agent but does communicate with your local one (their own version of ForwardAgent, complete with the security implications that carries). And the way it does that breaks a popular macOS SSH agent: https://github.com/maxgoedjen/secretive/issues/543

The "VSCode" before "SSH Agent" does the disambiguation fairly well.

I wonder what the use case is for this given the security implications. Staging instances that are sufficiently isolated from other environments?

I agree that Tramp is not great, but there's a simpler solution that works much better: `watchexec` + `rsync`.

I can set it up to watch specific file paths, and sync exactly what I need. I'm still working on the local FS, so there's no editing delay, I can use all my local tooling, and the syncing takes milliseconds. I can also make it delete files remotely when they're deleted locally. And finally, I always have a local copy once I stop working on the remote machine, which is something I always needed to sync manually with Tramp. Plus, it's editor agnostic.

This VS Code feature would make me nervous, especially now that I know what it does.

I joined a new team that's very VSCode centric and I've been thinking a lot about why I still prefer vim. My latest observation is that I find all the toolbars and other content filling the screen to be visually noisy. I turned on Copilot and wow it's more toolbars and text is flying into where I'm trying to write. Vim just lets me looks at, think about, and write code. I can't get into "flow" with VSCode.

Oh and since people are citing age in sibling posts, I'm mid-30s. I used emacs in university and switched to vim at my first job. I used IntelliJ for a really gnarly Java project, but otherwise I keep using vim.

> likes to demagic tools through exploration, values completely open source, highly tinkerable community driven projects, etc.

I liked all this stuff when I coded as a hobby. Now that it’s my job, I like VSCode because I never need to tinker with it to any significant extent and I can focus on getting my work done. I fire up vim occasionally if I need to do some fancy regexp munging.

The principal and distinguished engineers on my team used Vim and Emacs :P

I don't see any reasonable alternatives that can support what VScode does, like running extensions that aren't installed locally. Maybe those features aren't something you want, but they're part of the product feature set.

It’s not clear to me, are these issues on the local or remote vs code instance? If remote, I understand elisp tramp is a lighter touch as far as dependencies go, but is the attack surface all that different? (That is, does the remote node binary have any permissions a user running arbitrary ssh clans wouldn’t?)

The OPs goal was to give an llm keys the kingdom on an ephemeral/throwaway virtual machine, are they saying the sockets opened up by the agent allow it to fiddle with the developer machine it’s meant to be isolated from?

One perspective is to think of these as things that a modern OS should provide as a standardized feature, and VSCode is just working around the fact they don't exist. It's crazy to think about but the kernel itself could have a webserver (or other protocol) with encryption and auth that let you directly control the entire machine through EBPF. It could be an entirely different paradigm for client/server remoting. Also a security hole you could drive a death star through.

it was fixed with workaround, in newer versions, they copy statically compiled nodejs to the server and it works.