You probably have an SSH agent running on your laptop, caching your private keys so you don’t have to type your passphrase every time you hit a jump host. It is convenient, sure. But that socket living in /tmp is a wide-open door if a malicious process or a rogue container lands on your machine and assumes your UID. If you can read the socket, you can sign arbitrary data without ever needing the original key file.

The danger of socket hijacking

Most of us treat the SSH agent like a local vault. The reality is that any process running as your user can talk to that unix domain socket. I have seen developers accidentally expose this socket to containers during local development, effectively giving every node_modules package in their build chain the ability to impersonate their SSH identity. That isn’t zero trust; that’s just an easy way to get your production access compromised.

ssh-add -K -t 1h ~/.ssh/id_ed25519

• Force a timeout on your identities so they don’t linger indefinitely
• Never export your SSH_AUTH_SOCK into random docker run commands
• Use ssh-add -c to require manual confirmation for every single sign operation

Hardening the local handshake

If you really want to lock this down, move away from long-lived agents and start using hardware-backed keys. If the private key material never leaves the Yubikey, even a root-level compromise of your local machine won’t allow an attacker to dump your key. It’s an extra physical step, but it beats explaining to your boss why your identity was used to nuke the staging database.

Check your current agent environment now. If you see keys that you added days ago and forgot about, you’re living on borrowed time. Purge them, tighten your expiry settings, and start treating your local credentials with the same suspicion you reserve for public-facing edge nodes.