How to send an SSH key securely

Why pasting keys into Slack or email is a problem, and what to do instead.

First, check whether you need to send the private key at all. In most setups the right move is the opposite direction: the recipient generates a keypair on their machine and sends you the public key (id_ed25519.pub), which is safe to send anywhere — you add it to authorized_keys or your cloud console. Private keys ideally never move. The legitimate exceptions: migrating your own key to a new machine, handing over a deploy key, or break-glass access to a shared appliance.

Why not email or Slack?

Both keep a copy of everything, forever, searchable. An SSH private key pasted into a channel outlives the moment: it sits in message history, in email threads that get forwarded, in export archives, in compliance backups, and on every device that synced the conversation. If any account involved is ever compromised — years later — the key goes with it. Security teams call this the data-at-rest problem: the transfer took five seconds, but the exposure is permanent.

What a secure transfer looks like

End-to-end encrypted — encrypted before it leaves your machine; no server in the middle can read it.
Read-once — the first retrieval destroys it, so a leaked link is worthless afterwards.
Expiring — if the recipient never picks it up, it deletes itself.
Out-of-band verifiable — the unlock code travels over a different channel (a call, a text) than the link.

Step by step with Secret Share

Open shareasecret.io — no account needed.
Paste the key (e.g. the contents of ~/.ssh/id_ed25519) and click Encrypt & create share code. Encryption happens in your browser; the server only ever sees ciphertext.
You get a code like XKQ2-M7PT-tiger-ocean-cable-ruby-drum and a link. Read the code over a call, or send the link — the secret part never reaches any server (it lives in the URL fragment).
If you keep your tab open and the recipient opens the link while you're online, the key transfers directly browser-to-browser and the encrypted copy is deleted from the server immediately. Otherwise they can claim the encrypted drop any time before it expires.
The first read destroys it. If you pasted the wrong thing, hit Destroy secret now.

For the strictest posture, tick “Direct transfer only” before sharing — then nothing is uploaded at all, not even ciphertext, and the key moves exclusively between your two browsers.

After the transfer

Confirm receipt verbally, then make sure the sender's clipboard is cleared.
If the key protects anything important, put a passphrase on it (ssh-keygen -p).
If there's any doubt the transfer was clean, rotate: generate a new keypair and revoke the old public key from authorized_keys. Rotation is cheap; doubt is not.

Need to hand over a key right now? End-to-end encrypted, read-once, no account.

Share a secret →