ChatGPT Desktop forwards your SSH agent to remote machines

comments (10)

• It's amazing how often product decisions head this way for the purposes of 'removing friction'.

  In security, friction is a GOOD thing. You want to have some ceremony to do things. It's pretty much inevitable that people will give up control for convenience.

  Look at Artifacts for example.

  recsv-heredoc 2d ago

• I'd suggest to use ssh keys inside the secure enclave on macOS that require your fingerprint for every new session [0]. That way agents cannot initiate anything, and you will always be aware when a new ssh connection is being made.

  [0]: https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb...

  littlecranky67 2d ago

• The Bitwarden desktop app has a built in SSH agent [1], which lets you store SSH keys inside Bitwarden. I have set the app to always ask me for confirmation when the key is requested.

  [1] https://bitwarden.com/help/ssh-agent/

  Lukas_Skywalker 2d ago

• I don't understand what the linked pull request is supposed to prove, considering it was closed and not merged.

  yfontana 2d ago

• At this point, should cases like this even be news? Isn't that a fundamental security design issue? Local agent security guardrails appear to always be built around blacklists, which will always be unreliable and leaky. It is left as an exercise to the user to properly sandbox them.

  There may be some limited form of whitelisting, but often it is just a facade, as it is very coarse-grained. So, with tools with very broad capabilities (ssh, kubectl, gcloud, etc) you end up with the agent performing unwanted actions.

  m000 2d ago

• this is a normal ssh feature meant to allow keys to be used while keeping keys local …

  its actually a keystone of secure infrastructure setups, aka jump hosts.

  granted its meant for human or scripted uses, as is everything else

  carterschonwald 2d ago

• If this bothers you, it can be guarded against in your ssh config file:

    Host trusted-server
        HostName server.example.com
        ForwardAgent yes
  
    Host another-trusted-server
        HostName another.example.com
        ForwardAgent yes
  
    Host *
        ForwardAgent no

  otterley 2d ago

• Things are awful for this at the moment. [Was the same for docker desktop at some point.](https://rupertrutledge.com/posts/docker-sbx-s-ssh-security-i...)

  Same for [devpod](https://devpod.sh/) for sshing to devcontainers. They are particularly annoying because they just dump it into your config. Use an include statement to your own file for goodness sake.

  It was often not ideal in the old world. Now agents are doing everything in those boxes, it is kind of mad.

  I have my own utilities now for managing these sockets and files now to deal with this stuff.

  eosis 2d ago

• yes I was also surprised, back then the codex response the changes already deployed on production, which is codex doint commit, push, merge to master, and deployed to the server through ssh credential alone. which I dont told to do it.

  khalidahmad 13h ago

• > The agent running on a remote machine can authenticate using your local SSH credentials.

  No it doesn't. I'm using and enforcing SSH U2F keys. You physically press on a Yubikey (or similar) or you don't authenticate.

  As for my own Git server, it's of course over SSH and it requires pressing the Yubikey too. As a sidenote as I do it from Magit I modified Magit to add a small but obvious message stating that the Yubikey probably awaits touching (otherwise it's easy to miss / not realize).

  The great thing with all these hacks and bad practices is that I believe, eventually, people are going to learn better security hygiene.

  TacticalCoder 2d ago