Why My Deploy Key Lives in a Password Manager, Not on Disk

A developer describes keeping an SSH deploy key exclusively inside an encrypted password manager vault, never as a file on disk, after a near-miss where a private key was pasted into an AI chat window. The key is served via a bridged SSH agent between WSL2 and Windows, requiring an approval prompt for each use. The developer emphasizes verifying keys by fingerprint rather than raw material.

I have an SSH key that has never once existed as a file on my disk. It lives only inside an encrypted password manager vault, and every time it's used, I get a prompt to approve it. Here's why I set that up, and the near-miss that convinced me it was worth the extra friction. I once pasted a private key into an AI chat window and asked, essentially, "is this the right one?" It felt harmless — I just wanted to confirm an identity before deploying something. It wasn't harmless: the moment a private key is pasted anywhere — a chat, a file, a terminal that logs history — it has to be treated as compromised, because that transcript persists and gets processed elsewhere. Fortunately it was a freshly generated, not-yet-deployed key. I rotated it immediately — regenerated it, deployed the new one, deleted the old one everywhere — before it was ever used for anything real. But it was a clean demonstration of the actual rule: verify a key's identity by its fingerprint, never by looking at or pasting the raw key material. ssh-keygen -lf ~/.ssh/some key.pub That gives you a fingerprint you can compare against what you expect, with zero exposure. That incident pushed me to stop keeping my most sensitive deploy key as a plain file at all. My password manager's desktop app already runs its own SSH agent — it can hold a key, unlocked only when I approve it, without ever writing the private material to a file the OS or any process can just read. The only wrinkle: my dev environment is WSL2, and the password manager's agent lives on the Windows side. Bridging the two took two small pieces: npiperelay.exe socat WSL side, roughly socat UNIX-LISTEN:$HOME/.ssh/agent-bridge.sock,fork \ EXEC:"npiperelay.exe //./pipe/openssh-ssh-agent",nofork & export SSH AUTH SOCK=$HOME/.ssh/agent-bridge.sock Auto-started guarded so it doesn't spawn duplicates from my shell profile, so it's just always there. Verify it's working with: ssh-add -l Now that specific deploy key exists in exactly one place — the vault — and gets served to ssh only on unlock, with an approval prompt every time it's used. If my laptop disk were imaged tomorrow, that key wouldn't be on it. I keep a clear line between two things that are easy to accidentally merge: chmod 600 env files, auto-loaded by my shell profile. Fast, no unlock friction, appropriate for things that aren't catastrophic if a single machine is compromised.I deliberately didn't architect the runtime layer to fetch everything from the vault on every command. It sounds more secure, but it isn't, really — it just adds friction, and anything a tool or an assistant uses ends up in its working context regardless of which vault it came from. The vault's real value is as an audited, approval-gated path for the handful of secrets where that friction is actually worth paying.