Why SSH keys end up in the wrong places

A new developer needs access to the production server. Someone DMs them the private key over Slack. It sits in the channel history, in message search, in the workspace export. If someone needs it for a deploy pipeline, it ends up in a repo. Git remembers. Even if you delete the file and force-push, the key is still in the reflog.

SSH private keys are long-lived credentials. A leaked key stays useful until someone rotates it, and rotation means touching every server and service that trusts that key.

How to share an SSH key

1 Go to the tool and paste the SSH private key, or attach the key file (id_rsa, id_ed25519, .pem). Your browser encrypts it with XChaCha20-Poly1305 before sending anything to the server.

2 Set the view limit to 1. Set a short expiry, an hour or less if the recipient is online. SSH keys are high-value. Minimize the window.

3 Copy the link and send it. For SSH keys, consider using paranoid mode to split the link and the decryption key across two channels. Send the link over Slack and the key over Signal.

4 The recipient opens the link, copies the key or downloads the file, and the encrypted data is hard-deleted from the server. The link in Slack now points to nothing.

Paste vs attach

You can paste the key contents directly into the text area, or attach the key file. Pasting works well for single keys. If you're sharing multiple files (the private key, the public key, and a config file), attach them all. Your browser bundles them into a ZIP archive and encrypts the archive. The recipient downloads and extracts all files at once.

Why not email

Email messages are stored on servers, forwarded, backed up, and indexed. An SSH key in an email is an SSH key in every backup of every mail server that handled that message. Gmail alone keeps deleted messages for 30 days. Corporate mail archives keep them indefinitely. See why passwords in email are a problem.

Why not Git

Even private repositories have contributor access that changes over time. A key committed to a repo is visible to everyone who can clone it. If you push a key and then remove it, Git's history still has it. Force-pushing and BFG Repo-Cleaner can remove it from the history, but any clone made before the cleanup still has the key.

A better approach for teams

For ongoing SSH access, use SSH certificate authorities or short-lived keys managed by your infrastructure. Tools like Vault, Teleport, or AWS SSM Session Manager eliminate the need to distribute private keys at all.

Secret.Broker handles the one-time handoff. When someone needs a key right now, today, and you need it to stop existing in the channel once they have it. For sharing other credentials, see API keys, .env files, or read about why Slack isn't safe for secrets. For details on how the encryption works, see the protocol overview and fragment security model.