‹ BackHN Continuity

Thread

VSCode's SSH Agent Is Bananas (2025)

310 points · 218 comments · Rapzid

  1. walrus01 · · focus · HN ↗
    When I give an agent ssh access to something I want to be able to watch and fully understand what it's doing. I want it to essentially only "type" things into the CLI that I could have typed myself, I can comprehend what it's doing, and am not surprised by the results. Opencode and a smart LLM (qwen 3.8-flash-next, deepseek v4 0731 or smarter) do relatively well with this in my experience.
    1. pixl97 · · focus · HN ↗
      And if everyone was like you AI safety wouldn't be that large of concern. The default human behavior seems to be fire and forget which can go off the rails really quick.
      1. walrus01 · · focus · HN ↗
        It's not like I've never told an agent to build an ssh tunnel or some sort of more persistent connection between my dev machine running the harness and the remote thing it is talking to as an SSH client... Just that I don't want it going and doing that proactively unless I specifically define the parameters first.
        1. Muromec · · focus · HN ↗
          luckily nobody made an actor library in the most pupular programming language that can bootstrap a (resident) remote process in one line of code. it would be a shame if someone did that and then also build a made tool calling process of the harness installable on everything with a stdio.

          it's not like it's any worse than just giving the thing access to your ssh keys.

          1. walrus01 · · focus · HN ↗
            Agents and harnesses don't get access to "my" ssh keys, they get access to new ed25519 key pairs created for specific projects and access to discrete things. The blast radius is relatively well contained to specific VMs they are SSHing into for project specific purposes. I don't run a harness or agent directly on my personal workstation.
            1. Muromec · · focus · HN ↗
              I run the thing on a dedicated hardware machine, but I don't configure the separation between the harness control plane and individual shaitans that run inside it, so all the ssh keys the harness can access they can as well and sometimes they just run commands over ssh in commandline instead of doing it through the harness. I do have an option to put each of the /things/ in it's own isolated docker separate from the harness, but then what would I gain really?

              At the end of the day, harness itself is effectively a backdoor allowing inference provider to run arbitrary shit on my device, regardless of the convoluted ways I use to provision such context.

              They are at least conditioned to not read credentials and report to me if they accidentally read one.

              One thing I totally don't give them access to is my npm token and ssh key that is set up on on github. I would rather type npm pub manually every time than ... than what actually?

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.