13 ms·

VSCode’s SSH agent is bananas

• dogmatism 2y ago
  the answer is in the blog as always, Emacs
• ilrwbwrkhv 2y ago
  Yes vscode is awful. Zed ssh does a far better job. But we are living in an awful world.
  • sa1 2y ago
    Zed also downloads a remote agent.
    • dsissitka 2y ago
      And toolchains without asking: https://github.com/zed-industries/zed/issues/12589 https://github.com/zed-industries/zed/issues/12589
  • rednafi 2y ago
    What are you yapping about? Zed does it in the same way.
    • ilrwbwrkhv 2y ago
      It's much lighter
      • rednafi 2y ago
        It’s “lighter” on features too.
• 1oooqooq 2y ago
  pretty on par with the dowload the world as dependecies trend.
• andrewfromx 2y ago
  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.
  • jazzyjackson 2y ago
    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?
    • throwanem 2y ago
      Emacs Tramp just uses whatever SSH access you already have to a remote host, to copy files back and forth. It may use scp or sftp if the remote host advertises the protocol, but it does not install anything or invent any of its own protocols.
      • regularfry 2y ago
        Now I'm wondering if you could inject an emacs lisp interpreter onto the remote machine. There are exploit frameworks that do something similar. Whether such a thing should ever be written is a completely different question, of course.
        • kreyenborgi 2y ago
          tramp doesn't require running anything on the remote server, it's more like using sshfs. But if you find an exploit that will run by simply editing a file in emacs, you could put that file on the server and
• apatheticonion 2y ago
  Honestly, I'd love a terminal based editor/IDE that is essentially a shameless clone of VSCode. nvim showed me that it's possible, with mouse events, right-click context menus, and a rich editing experience. I did genuinely try to transition to nvim but I use my mouse a lot; resizing panels, using the file tree, copy/cut/pasting files in the file browser, tabs, etc. That's not to say nvim is bad, but after hours of configuration, I personally found myself less productive with it when compared to VSCode - however VSCode is bloated, slow, uses a lot of RAM, and SSH functionality is unreliable. I actually started writing this as a side project - using Rust, ratatui and a plugin system based on wasm (and dynamic C libs), but you know how side projects go
  • tiltowait 2y ago
    I had a similar experience. I liked nvim for simple editing, but not for anything multi-file. And then I found Helix, and I never looked back. I only hop into vscode if I want a Jupyter notebook.
    • apatheticonion 2y ago
      Thanks for the recommendation. Just looked it up, I'll give it a try! EDIT: https://helix-editor.com/ https://helix-editor.com/ I love that the homepage has a video showing usage. Such a great way to demonstrate it.
  • pshc 2y ago
    Have you tried Zed?
    • apatheticonion 2y ago
      Yes I have. Last time I tried it, it didn't have SSH support (I'm on a MBP so my life involves around remote development tooling). I'll take a look again
      • sunshowers 2y ago
• theamk 2y ago
  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.
  • chupasaurus 2y ago
    Task runners have to interpret the tasks one way or the other. Speaking of crazy stuff, Ansible in general ships out Python scripts to be executed remotely.
  • pjc50 2y ago
    Nothing magic about the byte code, it's a compiled bit of the CI script. The whole point of Jenkins is to run arbitrary code on a machine farm.
  • hiccuphippo 2y ago
    Maybe they could make a wasm interpreter with well defined limitations. Similar to how Deno does it for Javascript.
• gopalv 2y ago
  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 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.
  • nooorofe 2y ago
    it was fixed with workaround, in newer versions, they copy statically compiled nodejs to the server and it works.
• kevmo314 2y ago
  Is the news here that someone bolted an LLM onto that? Extensions always had this degree of access. npm or pip install can also do some pretty nasty stuff with a malicious package.
• concerndc1tizen 2y ago
  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)
  • jeffbee 2y ago
    Eclipse theia. It is an almost pixel-perfect ripoff of VS Code that integrates the open source components such as Monaco. It is what you are using if you've ever started a Google Cloud Shell Editor.
    • TiredOfLife 2y ago
      Theia embraced the Monaco editor. Are extending it and now are trying to extinguish VS Code.
    • brabel 2y ago
      Amazing that most commenters seem to even be unaware of Eclipse Theia which is basically THE open-source VSCode. They need better marketing (well, being open-source, they'll never have great marketing like MSFT, of course).
      • exceptione 2y ago
        I would add: ...and being Eclipse they will have no marketing at all. Eclipse offers tons of interesting IDE's, languages ranging from C, Java, PHP, there used to be Haskell support as well. Granted, not every language has the same depth of features, and some plugins are practically abandoned. There are tools for the automotive industry, tools for building Dsl's and IDEs, hardware programming, the list goes on. Eclipse is built as an IDE, but also as a platform to build your own IDE. I think that DBeaver is also based on Eclipse-the-platform. But eclipse also reinforces memes, look at eclipse.org - Software from the US: Great marketing, invasive, beginner friendly, attention to UX, great design, steals your data by default. - Software from the EU: Deeply buried on a 2007 website, great feature depth, interface tailored to power users, designers have been killed, community equals you + 20 experts on some mailing list, no data sharing or only as opt-in (they are just memes, with a pinch of truth)
• cratermoon 2y ago
  Can you say, "RCE"?
• jeffbee 2y ago
  Other than not being the exact way the author would have done things, what's the issue? If you're afraid your editor will go wild — and this is a possibility for any editor — you should setup your development environment in some type of sandbox. Personally, I host mine in a multipass virtual machine.
• smallerize 2y ago
  Oh and it keeps old copies around after an upgrade. (Maybe this was fixed?) I've had it use up all the disk space on a small VM.
• appleaday1 2y ago
  This is an actual issue can someone write a rust replacement for whatever VSCode is doing and also making sure this works on the open source version (VSCodium) thanks
• throwanem 2y ago
  Of course, if VS Code can't be run securely on dev endpoints, that's an argument for provisioning Codespaces, right?
• kazinator 2y ago
  "SSH agent" is a confusing term to use here, because it usually stands for a daemon that caches authentication tokens.
  • rednafi 2y ago
    The "VSCode" before "SSH Agent" does the disambiguation fairly well.
    • bqmjjx0kac 2y ago
      I, for one, was actually confused.
    • akvadrako 2y ago
      Only of you already know what the VSCode agent does and then you don't need the article.
  • CGamesPlay 2y ago
    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 https://github.com/maxgoedjen/secretive/issues/543
    • epistasis 2y ago
      Oh shoot, secretive is one of the few ways I knew of to keep track of each time an SSH key was actually used to auth something. I love using Agent Forwarding but the idea of anybody with root being able to arbitrarily auth stuff gave me a (perhaps unreasonable) feeling of insecurity.
    • RockRobotRock 2y ago
      I love secretive.
• rednafi 2y ago
  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.
  • spacemanspiff01 2y ago
    The security risk comes from all those unvetted plugins, that have unrestricted access to the editor.
    • rednafi 2y ago
      Yeah, I'm all in for a more secure option as long as it allows me to do everything that VSCode's SSH agent does. But if the devex goes down the drain because of "security" then I'm good for now.
    • shipp02 2y ago
      That's an issue with any plugin system, right? AFAIK no IDE has a plugin system with capabilities or a sandboxed interpreter. VSCode does have a thing where it's like do you trust the authors of this project. Not sure what it does because I've never had to use it. From StackOverflow[1]: >If you select No, I don't trust the authors, Visual Studio Code will open the workspace in 'restricted mode'. This is the default for all new workspaces. It lets you safely browse through code but disables some editor feature, including debugging, tasks, and many extensions. However, keep in mind that 'restricted mode' is all you need for many use cases. Actually if restricted mode[2] is any good, vscode might be better at security than most other editors/IDEs. [1]:https://stackoverflow.com/a/67914669/11422647 https://stackoverflow.com/a/67914669/11422647 [2]:https://code.visualstudio.com/docs/editor/workspaces/workspace-trust#_restricted-mode https://code.visualstudio.com/docs/editor/workspaces/workspa...
      • 2y ago
• modeless 2y ago
  This is what makes VSCode's remoting features awesome. This is the right architecture. Parts of the editor should run on the client and other parts on the server. > The underlying protocol on that connection can: Wander around the filesystem, Edit arbitrary files, Launch its own shell PTY processes, Persist itself Yeah that's what SSH access gives you too.
  • rednafi 2y ago
    I was wondering about this too. Once you have SSH access, unless your user is restricted, you can do whatever in the remote system. All VSCode is doing here is installing node to run the extensions, setting up a WSS connection back the client for realtime communication. I don't see the harm there given the extensive feature set.
    • fpoling 2y ago
      One can ssh into untrusted remote host with little risk for local machine security. That is, if the remote site is compromised one cannot use it general to compromise the local machine. At best the attacker can try to exploit bugs in terminal escape sequence handlings or rendering of complex Unicode characters by the local terminal. This is a relatively small attack surface. With vscode that exposes the local machine to the remote with support of very complex and undocumented protocol it is entirely different story. Which is a pity especially given that VScode is browser-based and browsers are designed to allow connections to untrusted servers. I suppose it will be a different story if VScode was designed with remote editing capabilities and treated the local stuff not different from remote. But given that the ssh extension was brought as an after thought with little regards for the local security we have the present unfortunate situation.
  • roywiggins 2y ago
    It's the other way around: the post is saying that the remote VSCode agent can tell the client to just do whatever. That's not how SSH usually works, if an SSH server can pwn a client that's a bug.
    • 2y ago
• shipp02 2y ago
  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.
  • schmichael 2y ago
    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.
    • shipp02 2y ago
      Is it better to programmatically interact with bash to provide the features VSCode does? Do note that I am unwilling to accept an implementation with less features/ease of use! I can see how writing a custom agent that provides remote access to privileged API's is a bad idea but bash isn't exactly the most secure piece of software in the world.
      • zelphirkalt 2y ago
        Bash is not running though. You might get a Bash session once you connect via SSH, but it just sits there waiting for you to input commands, while the VS Code installed agent thing does network stuff on its own iiuc. Bash is not acting as a server, afaik.
    • shitter 2y ago
      > 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. I can see how this increases local (to the remote system) attack surface, but as long as the agent has the same OS privileges as the user logged in over SSH, what extra remote risk does this introduce?
• tptacek 2y ago
  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.
  • bradgessler 2y ago
    [flagged]
    • verandaguy 2y ago
      This is intensely self-promotional.
  • alexgartrell 2y ago
    More low effort posts please!
    • tptacek 2y ago
      I can't tell you how much I love that this post has generated 156 comments and I have nothing to rebut about any of them. I'm sure they're all right!
      • DonHopkins 2y ago
        Emacs is better than vi and spaces are better than tabs!!! (I just wanted to get that in as long as you're agreeing with all the comments.)
        • mediumsmart 2y ago
          I second both of these
• hughes 2y ago
  > 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.
  • Salgat 2y ago
    I wonder what the use case is for this given the security implications. Staging instances that are sufficiently isolated from other environments?
    • thinkharderdev 2y ago
      I think the use case is mostly dev servers, either remote machines running in the cloud or docker containers running locally. I don't use VSCode much, but the one thing I do use it for is when I need to do something linux-specific. I spin up a linux VM on my MacBook and use VSCode to remote into the VM.
    • knallfrosch 2y ago
      https://github.com/features/codespaces https://github.com/features/codespaces All you need is a well-defined .devcontainer file. Debugging, extensions, collaborative coding, dependant services, OS libraries, as much RAM as you need (as opposed to what you have), specific NodeJS Versions — all with a single click. It's dev-environment-as-code and you can version control it.
• amluto 2y ago
  VSCode’s entire security model is bananas. As far as I can tell: The client and its scripts and plugins get unrestricted access to the remote system. The code you’re editing (if not in restricted mode) gets full access to the system it’s on (which is IMO an unfortunate default but not surprising — it’s really time for development systems to wake up and sandbox the code being developed to at least be limited to its own directory tree, but that’s a different story). The code you’re editing (if not in restricted mode) and remote plugins (no prompt at all AFAICT) get effectively full access to the client system, subject only to whatever privileges the client itself has. Yes, you read that right, if you Remote-SSH into a machine, that machine immediately owns you. Microsoft knows, and they do not care. See, for example, https://github.com/microsoft/vscode-remote-release/issues/6608 https://github.com/microsoft/vscode-remote-release/issues/66...
  • Spivak 2y ago
    I mean if VSCode is wrong then Vim and Emacs are condemned to an eternity of hell. I think there's a culture of editors being powerful in this way to a fault, on purpose. I think that's why devs like them— the training wheels, guard rails, seatbelts are all off.
    • amluto 2y ago
      This is, frankly, absurd. I have literally never, in my entire time using VSCode with Remote-SSH, wanted the repository or an extension or anything at all in the whole IDE to have any sort of access to my client machine with the possible exception of reading my VSCode config. No files in my home directory, no network, no anything. (Some people may like VSCode to forward a port to get a local web browser to target the remote machine. Fine, make that an option. I, personally, prefer to forward the port myself.)
  • rkagerer 2y ago
    Sorry, do you mean to say if I download untrusted code and open it in VSCode to inspect it, said code can pwn my system? (Forgive me if this question sounds uninformed, I haven't used VSCode much, but if true this would not be behavior I expect from a code editor).
• bhouston 2y ago
  > LLM-generated code is useful in the general case if you know what you’re doing. But it’s ultra-useful if you can close the loop between the LLM and the execution environment (with an “Agent” setup). Why not just run the agent locally to close the loop? I wrote an agentic coder just in the last week (open sourced it a few hours ago) that runs on the command line: https://github.com/bhouston/mycoder https://github.com/bhouston/mycoder Works great and simple. Why this complex SSH setup in the first place?
• neuroelectron 2y ago
  VS Code is written in JavaScript, it's inherently insecure. Now add an LLM that's familiar with JavaScript and it can easily escape and do arbitrary things. Where's the issue? Programming an IDE completely in JavaScript. It's like writing a text editor in English.
  • mardifoufs 2y ago
    Why is JavaScript fundamentally insecure? What would be a secure language in your opinion? And how are the issues highlighted in the blogpost related to JavaScript?
    • neuroelectron 2y ago
      You read the article right? VS Code has inherent security concerns due to the dynamic and unbounded nature of JavaScript combined with the attack surface introduced by its extensibility and web-based architecture. Electron (the JS interpreter used) has a dynamic web-based attack surface. Even if you mapped it out, it can change at any time thanks to the changing nature of JS standards. Furthermore, the security issue with extensions in VS Code is well documented. And the obvious bit is it's executing code sometimes, arbitrary user code and extension code. Telementry, etc. are built in. It's really up to the user to use it in a secured manner. A lot of people just don't consider this.
• dlx 2y ago
  As mentioned in other threads, I'd love it if I could use Sublime Text remotely, but am stuck using VSCode simply because of what this setup allows in terms of remote coding. Perhaps a standard too that any editor could use would be amazing -- is there anything else out there that enables this much functionality out there?
• sunshowers 2y ago
  Former long-time Tramp user, now Zed for the most part + VSCode for a few things. I'll say that neither Tramp, nor running an editor directly on the remote, are nearly as usable on a high-latency connection as Zed or VSCode. I think that generally wins out over the security concerns for me.
  • deleted 2y ago
    [deleted]
• midtake 2y ago
  I am still using Sublime Text, for some reason.
  • bigstrat2003 2y ago
    Because Sublime Text is awesome and has yet to be surpassed by other editors, that's why.
• toprerules 2y ago
  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).
  • qwe----3 2y ago
    The principal and distinguished engineers on my team used Vim and Emacs :P
    • IshKebab 2y ago
      I would imagine that is more due to age than anything else.
      • qwe----3 2y ago
        That is true
  • imiric 2y ago
    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.
• khana 2y ago
  [dead]
• kiitos 2y ago
  > the LLM generates the code, the agent scaffolding runs the code, the code generates errors, the agent feeds it back to the LLM, the process iterates wait what
  • cruffle_duffle 2y ago
    Cursor does exactly this and it’s pretty wild the first few times it happens. Then you realize it does it only sometimes so you change its “English script prompt” file and make it do a full lint scan so it catches all the linter errors and then you watch it fix something in a wrong way so you stop it and ask WTF it was thinking, and then it apologizes and 50% of the time does the fix the right way and 50% of the time you chase a rabbit hole. Also sometimes it selectively ignores some of your script file prompt so you have to reprint and tell it to fix its script in a way that ensures it understands it… and it does that so you commit the new script document to git (or have it do it) It’s the future. We live in it.
• ak217 2y ago
  The proper name for this functionality is Visual Studio Code Remote - SSH (https://code.visualstudio.com/docs/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.
  • nomendos 2y ago
    When is the Risc-V support coming?
  • Aurornis 2y ago
    > Whether you consider this architecture bananas or not depends on your security model. Knowing about the security risks is good. In all of my use cases I control both client and server machine. The remote SSH capability just lets me use the UI comfortably on my laptop.
• mfrw 2y ago
  >> VSCode mounts a full-scale invasion I love to read articles that have a bit of humour(no offence to VScode people); somehow, it seems one can connect more with the writer. Thank you, kind stranger on the internet. You made me smile when I most needed it :)
• bkallus 2y ago
  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.
  • bogantech 2y ago
    Disable TCP forwarding in SSHD
  • kalleboo 2y ago
    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
    • jaygreco 2y ago
      Ah yes, one of my favorite skills learned in school was how to work around arbitrary rules made up by cranky sysadmins! I still use it all the time. The smart kids (whom I’m sure look like they are learning that precious openssh client) are doing their assignment locally or on a free tier VPS with VS Code and scping the thing over when it’s done. They’re also smart enough to learn openssh when they need it IRL.
      • ytans 2y ago
        In the class which I have managed the infrastructure for, we have 1 to 2 students per VM, so this is less of an issue and there aren't any restrictions. One of the reasons we provide the VMs is so that students can experience working in a remote server environment. The concern that I have is that these remote ssh tools allow you to bypass learning/practicing how to perform basic actions, e.g. cd, read/edit files. Granted, as mentioned, you can scp/rsync (or git pull), but at least this seems to be more appropriate when you eventually need to interact with a real production server.
• pritambaral 2y ago
  TFA is light on details, but I have a few choice anecdotes about negative consequences of this: ---- I work on a large C++ codebase that takes quite a lot of CPU and RAM to build. To ease development access, we set-up a beefy VM in the cloud, put LXD in that, and gave every developer an LXD container of their own. Access via SSH was simple: ProxyJump via the LXD host (VM) into you container. Now, I don't use VSCode, I use Emacs, and my container was setup by me to do everything The Right Way™. Devtools like clangd and clang-format were installed via the OS package manager. Everything Just Worked™. The VSCode users on this team had their own containers, so however their setup was didn't affect me. Until one of them connected their VSCode to my container. My dev setup broke because their VSC decided to download a Microsoft-built binary of clangd and install it onto the PATH in my container. I was horrified, but the coworker who had (inadvertently) done this didn't see the problem. Their VSC worked just fine. I had to write-off that container of mine and create a new one. Today, we mandate use of the LLVM-provided clangd extension in VSCode in the team, which does not automatically download anything from the internet. But this habit of "helpfully" auto-downloading LSP servers is apparently still common among VSC extensions. To the point that the Emacs lsp-mode package also offers to do that. Thankfully, it's Emacs, so it's pretty easy to disable that behaviour. ---- As we SSH into machines quite a lot, we strongly discourage per-container SSH keys and strongly encourage SSH Agent Forwarding instead (with per-use confirmation). VS Code found a way to break that too. But we couldn't wait for the VSCode overlords to fix it — we were affected already, and urgently needed a fix — so we looked into what could be happening. Turns out, VSC hijacks the way your shell loads, all so it can inject arbitrary stuff into the embedded terminal. You think you know how and when bash loads ~/.bash_profile and ~/.bashrc and so on. None of that matters because VSC uses its own homebrew init script for bash. A script that tries to, emulate how bash loads, though not entirely accurately. If you're building a terminal emulator and you want shell integration, the correct way to do it is to ask your users to load your terminal's support code into their shells. The VSCode way is to never tell the user anything and just silently take over their shell for them. ---- Now, I no longer even try to support VSCode on the team. VSCode users are on their own. I help them setup Vim, NeoVim, Emacs, or even IntelliJ. If they have to have VSC, I might look into Eclipse Theia. But, as far as VSC is concerned, I expect nothing less than this malware-style behaviour and thus refuse to waste my time on it.
• ei625 2y ago
  It's open source and even has long design documents, better to improve it instead of just complaining about. If your opinion is valid, some others will rewrite to fix it.
  • eru 2y ago
    Complaining is fine, you don't need to read the blog. I agree that parts of it are open source.
  • roywiggins 2y ago
    The "Remote" bits, and VS Code Server, aren't open source though.
    • causal 2y ago
      This is my biggest issue with it. Security concerns aside, it's difficult to even debug when issues arise because of how opaque it is.
• mediumsmart 2y ago
  VSCode is a perfect fit for most of the projects it is used for on an internet gone bananas.
• dsp_person 2y ago
  A simple solution is to use bubblewrap locally. Only bind mount specific directories into it and a copy of your vscode config (which you could merge any changes back if you need). Then you can install random extensions and let the AI wreak havoc generally without it leaking to your main system. On arch linux bwrap'ing vscode also seems to work without zypak.
• 0xbadcafebee 2y ago
  What did we learn? That remote code execution is a thing? That misplaced trust in [dev] tools is often regretted? That modern software design is ass? If you've been paying attention, all of that has been obvious. SSH is a solution from the 90s. It's Telnet with a couple extra features bolted on, and despite being called the "secure" shell, is literally less secure than Telnet+TLS would be. There's so much stupid-yet-glorified bullshit implemented over SSH, because lazy assholes had a tunnel into a server with a user session, and decided "why implement a whole extra protocol for network transport and secure connections for my application? I already have an authenticated user session, in this very specific protocol, computing design, and network architecture. who care if nobody else on the planet but computer nerds have used something like this since 2000? works for me!" Discard the concepts learned from distributed OSes, ignore all the advanced AuthN+Z that had been developed, embrace the shittiest, easiest thing you can. These "SSH agents" aren't bananas. We refused to get off our stupid lazy asses to build the right tool for the job. So we had to keep shoving more shit into pre-existing tools that were never designed for what we decided to do with it. We have no right to pretend we're surprised. This is the world we have made. All of you, and me too. Either with your labor or your silent compliance. If it's not SSH, it's politics, commerce, school, and everything else. We live every day in the shit-pile we carved for ourselves, and every day that we don't do something about it, we throw another shovel on the pile. You don't get to sit there shoveling shit and pretend this is a fucking surprise, or crazy. You're holding a shovel.
  • h4ck_th3_pl4n3t 2y ago
    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.
    • 0xbadcafebee 2y ago
      1) I never said it was malicious, 2) humans do not try to do their best (have you looked around lately?), 3) complaints are entirely useful regardless of constructive criticism, they are literally user feedback
• RainyDayTmrw 2y ago
  Most remote access software has the same patterns as malware, no? It's only a matter of who's driving? A related anecdote: I watched, in person, a user call into their workplace's offshore IT support, who had honestly no idea what they were doing, and kept poking around aimlessly in a remote desktop session. I remarked that, having watched tech support scam baiting videos, the interactions were honestly indistinguishable, and hopefully the user had dialed the correct number. The user was not amused.
• partloyaldemon 2y ago
  what is the type of application that was hinted as being murid? I couldn't crack that one.
  • Dibby053 2y ago
    I think it's RAT (remote access tool)
• dig1 2y ago
  > because everybody is using VSCode now Maybe I'm living under the rock, but I know only 2-3 people that are using VSCode
  • nsteel 2y ago
    It's extremely popular: https://survey.stackoverflow.co/2024/technology#1-integrated-development-environment https://survey.stackoverflow.co/2024/technology#1-integrated... But anecdotally, nobody in my office uses it.
• rs_rs_rs_rs_rs 2y ago
  I'll take VSCode "insecure" ssh agent over Emacs Tramp any day of the week because it actually works. Sometimes you just gotta be pragmatic and use the stuff that works and makes your life easy.
• self_awareness 2y ago
  VSCode remote editing trojan is the only remote editing mechanism that actually works. Tramp might be good in imagination, but in reality it's just a poor plugin that sometimes works, and even if it works, it's only good for some use cases.
• agumonkey 2y ago
  is murid short for remote access greek horse ?
• LoganDark 2y ago
  I wish the SSH agent weren't so stupid. It spawns so many processes just by existing that it kills a bunch of other stuff on the server. I can only use it on machines without ulimit.
• bravura 2y ago
  "[LLM-generated code] is ultra-useful if you can close the loop between the LLM and the execution environment (with an “Agent” setup). There’s lots to say about this, but for the moment: it’s a semi-effective antidote to hallucination: the LLM generates the code, the agent scaffolding runs the code, the code generates errors, the agent feeds it back to the LLM, the process iterates." Okay, so who's doing this today and how? This question came up recently in the Aider discord and not many had a good answer. Aider is great but the SDK is weak and second-class, so interacting with the repl frustrates agent-dev. Sidecar (which can run independently of Aide IDE, not to be confused with Aider), https://github.com/codestoryai/sidecar/ https://github.com/codestoryai/sidecar/ is one agent that was mentioned. Many of that projects issues are auto-responded to by a PR-creating agent. Anything else I'm missing? In general, I know how I would build an agentic dev-loop, I'm just looking for a good SDK that handles prompting and diff merging etc. i.e. Aider as an SDK or similar.
  • skp1995 2y ago
    Hey I am the coredev on sidecar. The reason you see autogenerated PRs is cause I am using our agents to write the code for the agent lol The big difference is the complete loop, each PR gets its own VM with the tool chains installed so the agent can run cargo check or cargo tests etc. We do find the LLMs of today are not the best elite engineers but very very competent junior engineers. It's been a weird but eye opening workflow to use.
    • bravura 2y ago
      I am super interested in sidecar. When will it support o3-mini-high? I also need an SDK to script it, tbh. What I want is to have actually a few different agents that interact with each other. Do you expose a good SDK?
      • skp1995 2y ago
        I does support o3-mini-high already, we use it for a few flows in the agent. What kind of SDK support are you looking for?
• sklivvz1971 2y ago
  I am very confused by this post: 1. VSCode uses SSH (with its security profile) and the user can't do anything more with VSCode that they can already do with SSH. If the comparison is between a system without SSH and a system with VSCode and SSH--sure--I understand the concern, but it's an issue with enabling SSH and not VSCode. 2. VSCode can change files and persist? Well, it's a local editor, so yeah, it can change files and persist, that's literally its purpose. If that's an issue, disable editing permissions for the user.
  • n144q 2y ago
    You are not the one who's confused. The author of the article is.
  • roywiggins 2y ago
    The server running at the remote end can execute code on the client. If an SSH server can do that it's a security issue and a bug. The README does warn about this: "A compromised remote could use the VS Code Remote connection to execute code on your local machine." https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh https://marketplace.visualstudio.com/items?itemName=ms-vscod...
  • kreyenborgi 2y ago
    Normally on connecting to a remote machine you expect to be able to control that machine, you don't expect that machine to gain control over yours.
• PeterStuer 2y ago
  "The underlying protocol on that connection can: Wander around the filesystem Edit arbitrary files Launch its own shell PTY processes Persist itself" Given that this was the solution, what was the goal?
• juliangmp 2y ago
  > ”hallucination” is what we call it when LLMs get code wrong; “engineering” is what we call it when people do. I should print this out, frame it and hang it on the office walls omg
  • Neywiny 2y ago
    It's a bit offensive, tbh. Hallucination is because LLMs can't think and don't operate on facts. To even suggest engineering is that haphazard shows a clear lack of understanding of engineering. I've had LLMs hallucinate entire libraries existing with examples of how to use them. Others have had worse. If a person did that, they're no engineer.
    • IshKebab 2y ago
      That's not exactly true either. Hallucinations are because LLMs aren't trained to be truthful, they're trained to be plausible, which usually coincides with the truth. Humans have better training, but I've worked with someone who had LLM levels of bullshitting. Straight up made shit up and it worked. I'm still not quite sure why but everyone else was either too polite or oblivious to call him out (apparently that's not an unusual response to proper bullshitters). Fortunately those people are pretty rare, but it's really a question of degree. The latest LLMs bullshit far less than they used to. Less than that guy I worked with.
      • Neywiny 2y ago
        Yes but would you call what that person did engineering? I certainly wouldn't.
        • averageRoyalty 2y ago
          No, of course not. But it's a tongue-in-cheek joke, obviously.
• hvenev 2y ago
  For local communication Microsoft Visual Studio Code often uses TCP sockets (bound to localhost) even though UNIX sockets are available. What's more, old versions used to pass the authentication token as a command-line argument, exposing it to all users on the system. I wonder how many other security disasters it contains that nobody has discovered yet.
• kdmtctl 2y ago
  The first time I've actually checked what kind of bloat VSCode brings to a server, I stopped used it this way. No deep inspection, just in sake of Occam. Long forgotten mutagen works much cleaner, although requires a bit of a setup.
• Retr0id 2y ago
  The silver lining of all this is that your local vscode instance becomes more of a thin client, with the heavy lifting being done by the remote instance. It's perfect for the "small laptop ssh'd into beefy workstation" use-case, but less so for the "beefy workstation ssh'd into tiny VM/VPS". If you're doing the latter, I'd recommend using sshfs or some other remote-fs-mount setup, and opening the mounted directory in vscode normally.
• faebi 2y ago
  It's very much the reason vscode is successfull in my opinion. They differences between local and remote development start to disappear. This is especially useful in corporate environments, but not exclusively so. At the same time vscode keeps the input latency as low as reasonably possible. It's not the best in the world, but the most integrated. And the cherry on top is the out of the box connection loss handling. Just reconnect some when later exactly where you left it.
• yapyap 2y ago
  rolled my eyes at the sidenote “”hallucination” is what we call it when LLMs get code wrong; “engineering” is what we call it when people do.” gtfo
  • greenchair 2y ago
    that was the best line!
• jFriedensreich 2y ago
  I found this out the hard way as some servers had a high cpu load and a weird agent that i did not install. After having a heart attack and assuming an intruder i discovered vscode had injected some agent that was stuck walking the servers filesystem and consumed 100% cpu on one core. On the one hand i love how having a server open in vscode feels especially as things like the docker extension work pretty well but on the other hand i really wonder if it requires these nightmarish sacrifices.
• wink 2y ago
  I don't remember, but if it can do ESC-. (which IntelliJ's can't and which I try to use multiple times per week, I'm not learning) it's less bananas than that one, for me.
• blakehawkins 2y ago
  https://github.com/devspace-sh/devspace https://github.com/devspace-sh/devspace Devspace works the same way
• dmd 2y ago
  > Unlike Tramp, which lives off the land on the remote connection, VSCode mounts a full-scale invasion I would argue that "lives off the land" is a poor analogy, and is much more like what VSCode does. Tramp specifically does not live off the land. It has a supply line back to home base; all its resources come from home.
  • lupusreal 2y ago
    Tramp goes into the woods with nothing. Finds a rock and throws it at a rabbit. Finds some sticks and rubs them together to make a fire and cook the rabbit. VSCode doesn't look around for rabbits, sticks, or rocks. It brings an RV with a fully stocked pantry and kitchen.
• pjmlp 2y ago
  As someone that always favoured X Windows, and mastered enough vi when (X)Emacs wasn't available on the development server/production system, never bothered with tramp. Likewise with VSCode, now 30 years later, one of the few plus of it being Electron based, and having started its life as browser based app, is that the browser has replaced my X Windows session. So don't really care how much bananas the SSH agent happens to be.
• cedws 2y ago
  This is a perfect use case for unveil(): you have a program that wants to operate on a specific directory (your repo), and never outside of it.
  • sph 2y ago
    Dev tools are written with people running macOS. They already have trouble following XDG instead of polluting one's home directory, imagine asking them to use unveil. Also AFAIK unveil is an OpenBSD thing. Does VSCode even do BSDs? chroot is POSIX and none of the junior devs employed by Microsoft are aware of it.
    • cedws 2y ago
      Of course, I meant this is an argument for other operating systems to implement a similar syscall. Maybe NT/Darwin have something similar that I'm not aware of.
• opliko 2y ago
  The more I learn about how VSCode works the more it seems like it's held together with duct tape and the most cursed ideas a JS developer could come up with. Even just from the SSH extension - the workspace URIs have two formats: essentially just the hostname and hex-encoded JSON documents. The latter case happens when additional info is needed, e.g. specific username, or... The hostname includes an uppercase letter. Which is actually necessary because when they're saved to recent workspaces they're lowercased for whatever reason. The SSH connections also support configuring extensions that are to be installed on the server, but don't go too crazy with it or you won't be able to connect to Windows hosts, since they're passing them ass command line arguments via CMD, which has a 8191 character limit (they're using CMD to call... PowerShell...).
  • fujinghg 2y ago
    It’s shit and string. Gone back to vim.
    • bayindirh 2y ago
      Give Eclipse a go?
      • johnisgood 2y ago
        Is it not written in Java?
        • bayindirh 2y ago
          Yes. However, today's Eclipse is only similar in appearance to its former self (I'm using it since 2002). Has its own JRE bundled, and uses that one if you don't have any JRE installed. Has a stable release every three months. Starts in 5 seconds, uses ~600MB of RAM (less than VSCode!), and works very snappy. Supports web development, C/C++, Python, remote execution and much more. Plus it has the best Git integration I have seen ever (incl. GitTower + Kaleidoscope). In C/C++ land integrates directly with debuggers, Valgrind, etc. The trick is, it didn't get bloated or heavier over the years, the contrary, and draws circles around everything in its class. Plus it has modern amenities like LSP support, synchronization between installations, etc. Oh, and you can migrate it with two small XML files. Preferences and software configuration.
• bitlad 2y ago
  Security has two aspects: Objective security - things like do not open mongodb server with default passwords to internet etc. which are definitely bad. Subjective security - blogs and consultants saying something is bad and do not have objectivity to back it. It may not be a bad things, ugly sure, but it would need lot of context. It could be bananas, ugly etc. but may not bit a big deal. Sure things, go wrong white remote editing. Did I bring a server down, you could do the same while VI thinking it UAT but it turns out to prod or rm a mount. Are millions of orgs doing this day-in day-out? yep.
• bloopernova 2y ago
  I'm DevOps and don't pretend to understand good code layout in large projects, but why would you keep a "printTime" function in remote extension management code? https://github.com/microsoft/vscode/blob/c9e7e1b72f80b12ffc00e06153afcfedba9ec31f/src/vs/server/node/remoteExtensionManagement.ts#L12 https://github.com/microsoft/vscode/blob/c9e7e1b72f80b12ffc0... (Genuine question, I'm puzzled!)
  • righthand 2y ago
    You don’t know/care and the reviewer doesn’t care. The code was probably written by an llm helping enforce the not-caring.
    • bloopernova 2y ago
      Are you OK? I just asked a question, which implies that I cared enough to at least ask.
      • righthand 2y ago
        No I think it implies that you wanted to appear to care in order to make a point.
        • bloopernova 2y ago
          oh. I really didn't, can you tell me what made it sound that way? I'm autistic and freely admit that I get words incorrect, and miss contexts. I'm mostly OK at programming, but I like to learn, and HN is full of people who are much, much smarter than me who also like to share their knowledge. Thank you for replying. I wasn't trying to make a point, I was just trying to learn why a seemingly utility function wasn't in some shared /lib/timestamps.ts or whatever. I won't bother you further.
          • righthand 2y ago
            I didn’t say I was bothered, and I don’t think you were attacking me. I don’t think you misused anything and I fully grokked your context. Sorry if my reply came off as snark or disgruntled. Yes I am okay, my original comments was to make a point about general populace’s level of dedication to their employment and interest in the strict rules of good software design. The original commentary was a bit snarky. Thank you for asking if I was alright it, it is important to reach out when snarkiness cannot be discerned from distress.
• wiradikusuma 2y ago
  Maybe it's because I'm an old dog, but I was a long-time user of Eclipse before settling on IntelliJ, and I don't understand what's the fuss about VSCode. Compared to IntelliJ, VSCode feels "messy" (I don't know how to describe it). I'm trying to convert myself, though, because I need to work on a less powerful machine (from MacBook Pro to MacBook Air). Any tip from successful IntelliJ -> VSCode convert?
  • noodletheworld 2y ago
    Well, I’m not going to go into the arguments about using or not; but if you are serious about the switch put something like key promoter on to learn the new shortcuts. Most of the inertia that stops people changing is just muscle memory. Once you fix that, it’s fine. Also, if you write plugins, check out the plugin guide. Maintaining IntelliJ plugins has driven me away; once you start writing vscode plugins you’ll find it a good reason to stay.
  • knallfrosch 2y ago
    I switched from VSC to IntelliJ. I installed plugins to make the keyboard shortcuts and the colour scheme match. Other than that, you'll just have to accept that any first-party support from IntelliJ will require 1–3 plugins. 3 for Java, Docker, 3 plugins for React, npm, Prettier, SonarLint, Copilot, database, Gitlens, Maven — don't be surprised if a single project becomes usable only after 20+ plugins.
    • mdaniel 2y ago
      > from IntelliJ will require 1–3 plugins. 3 for Java, Docker, 3 plugins for React, npm, Prettier, SonarLint, Copilot, database, Gitlens, Maven How old is your copy of IJ that you need to download the Maven plugin? To the very best of my knowledge, every one of these in the "plugins" directory ships with IJ and is not something one needs to download from the JetBrains marketplace: https://github.com/JetBrains/intellij-community/tree/idea/251.20015.29/plugins/maven https://github.com/JetBrains/intellij-community/tree/idea/25... I obviously can't link to the GitHub repo for IJ Ultimate but the DataGrip behavior is similarly bundled. What may be up for hair-splitting is that think they do use the concept of plugins as an update mechanism. That is: I don't think one could download a copy of IJ Ultimate that doesn't speak Java, Docker, npm, database, or Maven. But they do use plugins such that one could acquire a bug-fix to (e.g.) the Docker plugin without having to re-download the whole IJ
• api 2y ago
  I’ve been using Zed for some time and like it a lot. Much faster and lighter than VSCode and works great for Rust and C/C++. Haven’t tried it with JS or other languages yet. Took a little customization to get it how I want it, but not hard. I might buy Zed’s cloud stuff just to support them even though I don’t need it.
• neilsimp1 2y ago
  > because everybody is using VSCode now Are they though? I don't have numbers right now to back this up but last I remember, people were leaving VS Code, not moving to it.
  • nsteel 2y ago
    I'm sure there's some bias here but the best numbers currently available show it's still staggering https://survey.stackoverflow.co/2024/technology/#1-integrated-development-environment https://survey.stackoverflow.co/2024/technology/#1-integrate... You're going to have to provide a source of you want to claim otherwise.
• notpushkin 2y ago
  > they’ll iterate on your system configuration just as happily on the Git project you happen to be working in Ehhh... no they won’t? Unless you give them access, of course.
• fsh 2y ago
  The VSCode agent is so bloated that it tends to OOM raspberrypi pies. Truly remarkable for a piece of software whose job it is to forward some text.
  • IshKebab 2y ago
    It's extensions that do that. VSCode with no extensions is very light.
  • __jonas 2y ago
    > Truly remarkable for a piece of software whose job it is to forward some text That is not its job. It's job is to run a whole IDE on a remote host, turning the local host into a thin client. This includes language servers, extensions etc. all being shifted to run on the remote machine – if you want to forward some text, there are significantly lighter options.
• hnbear 2y ago
  murid, noun, Any member of the Muroidea superfamily of rodents. RAT, a remote access tool/trojan.
• woahperson 2y ago
  Works great for me, idk what you all are doing wrong
• woahperson 2y ago
  This functionality has worked great for me as a web developer working on huge websites. I have not experienced any issues
• openplatypus 2y ago
  If any of you are recommending sshfs or a like you really don't understand the benefits of full VS Code SSH Remote environment. You can effectively run whole development (LSP, docker, compiler, files) on remote like it is on your local machine. You can turn any underpowered legacy machine or a thin client to a full featured workstation. There is tons of horrible plugins that scream security threat in VS Code market place. The SSH Remote or VS Tunnel ain't one of them.
  • krobelus 2y ago
    > You can effectively run whole development (LSP, docker, compiler, files) on remote like it is on your local machine. the same is possible with any other editor that implements a client/server model, and it can be done without giving the server the ability to execute code on the client
  • blueflow 2y ago
    > You can effectively run whole development (LSP, docker, compiler, files) on remote like it is on your local machine. This has always been possible with ssh+tmux. And before tmux was popular, people used gnu screen.
  • averageRoyalty 2y ago
    > If any of you are recommending sshfs or a like you really don't understand the benefits of full VS Code SSH Remote environment. Or we don't need them. Most peoples workflow is send file to remote, trigger remote. There are definitely other cases that this plugin may be more suitable for, but the trade offs for most people (which I suspect the majority of developers don't understand) are not very good.
• advael 2y ago
  My days of not trusting a single thing microsoft controls are certainly coming to a middle
• koakuma-chan 2y ago
  > because everybody is using VSCode now, and, in particular, they’re using forks of VSCode that generate code with LLMs :crylaugh: :crylaugh: :crylaugh:
• nyoomboom 2y ago
  Thank you for this - it dissolved an assumption I had about vscode ssh - that it was similar to Tramp