‹ BackHN Continuity

Thread

VSCode's SSH Agent Is Bananas (2025)

310 points · 218 comments · Rapzid

  1. danielklnstein · · focus · HN ↗
    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.

    1. neuroticnews25 · · focus · HN ↗
      It's unusable on low end 512MB RAM VPS servers because someone decided bundling whole node runtime for file operations is a good idea.
      1. xg15 · · focus · HN ↗
        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...)

      2. cozzyd · · focus · HN ↗
        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&#x27;s yocto image (<a href="https:&#x2F;&#x2F;github.com&#x2F;RNO-G&#x2F;meta-rno-g&#x2F;blob&#x2F;main&#x2F;recipes-support&#x2F;fuck-vscode&#x2F;files&#x2F;home-rno%5Cx2dg-.vscode%5Cx2dserver.mount" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;RNO-G&#x2F;meta-rno-g&#x2F;blob&#x2F;main&#x2F;recipes-suppor...) , but a more general solution would be nice. Probably better to just not allow any node process to run via LSM.

      3. memco · · focus · HN ↗
        It also has some unfortunate OS &#x2F; glibc minimums which means that it&#x27;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&#x27;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 &#x2F; extension version so that I could just keep using it everywhere I&#x27;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.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.