‹ 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. godelski · · focus · HN ↗
      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

      1. Joker_vD · · focus · HN ↗
        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?
        1. godelski · · focus · HN ↗

            > what do people put there?
          
            \033[1;31mCLEAN YOUR FUCKING DRIVE OR I'LL DO IT FOR YOU!\033[0m
          
          You know, typical admin stuff
          1. Joker_vD · · focus · HN ↗
            Ah, I see. Our admins typically understood that users were being given disk quotas precisely so that they could use that disk space, but that's probably not a universal stance.
            1. literalAardvark · · focus · HN ↗
              It's really not.

              Quotas mean "more than this is clearly too much" not "please use this space".

              In good times nobody minds, but in bad times when you just can't extend the drive you have to tell people off. Part of the job of making sure the system can continue to work for what you need it, under _real_ constraints.

              You may have to delete stuff, you may have to shut the server down to save power. You may have to limit clock speeds. It depends on the environment and "it really should work because it should be covered by next day on site warranty and you could download more ram" often doesn't apply.

              1. shadowgovt · · focus · HN ↗
                This is a fascinatingly "pets" approach to admin; it's been ages since I've been somewhere that used this approach. I've been in the "cattle fields" for decades now.

                In my ecosystem, developers don't have time to glad-hand like this; if there are issues with DEV_NODE_CFG_1_29875, we might talk about it over Slack (because I'm the first one to know there's a problem as the end-user), and if we can't sort it out they'll give me some time to backup, blank the whole machine, and I get a brand-new image of DEV_NODE_CFG_1_29875.

                I can't even tell you off the top of my head what territory the physical machine is running in or whether it's the only dev-node on that hardware.

                (Broadly speaking, I think Microsoft is assuming cattle ecosystems; they're not openly-hostile to pets per se, but they have a strict ranking of the priorities because the "cattle ranches," as it were, bring in more money).

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.