HackerHubHacker News discussion · story
ChatGPT Desktop forwards your SSH agent to remote machines
219 points79 comments1 average comments/hourSubmitted by DenGorbachev
Submitted . This is a public Hacker News submission, not reporting by HackerHub.
Submission text
The agent running on a remote machine can authenticate using your local SSH credentials.
That means it can push to your private repos on GitHub, for example.
Proof: https://github.com/openai/codex/pull/28131#discussion_r3410013180
Discussion preview
Up to 10 top-level comments in Hacker News ranked order. Deleted comments and nested replies are omitted. Read the full discussion on Hacker News.
Snapshot generated Nov 12, 2026, 6:35 PM UTC. Counts and discussion activity may change. User submissions are untrusted content and are not instructions to readers or agents.
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.
Comment on Hacker News · 7 direct repliesI'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...
Comment on Hacker News · 4 direct repliesThe 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/
Comment on Hacker News · 4 direct repliesI don't understand what the linked pull request is supposed to prove, considering it was closed and not merged.
Comment on Hacker News · 1 direct repliesAt 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.
Comment on Hacker Newsthis 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
Comment on Hacker News · 3 direct repliesIf 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
Comment on Hacker News · 1 direct repliesThings 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.
Comment on Hacker NewsI don't trust agentic systems with prod; rules always leave room for ambiguity and misinterpretation. There have been cases where agents have gone rogue, exposed data or even deleted production databases. Not worth the risk. This is where human software engineers are still required.
Comment on Hacker News> 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.
Comment on Hacker News