textdrop.sh
Guide · Sensitive files

How to share an SSH private key.

You probably shouldn't. But when you genuinely have to, here's how to move a private key without leaving a copy on every backup server in the chain.

May 29, 20265 min read

The short answer

First ask whether you can avoid it by adding the recipient's public key to authorized_keys instead. If you really have to send a private key, passphrase-protect it with ssh-keygen -p, paste it into textdrop.sh as code, turn on burn-after-read, add an access password, and send the link, the access password, and the passphrase through three different channels.

Do this. Not that.

  • Do
  • Have the recipient generate their own keypair, then add their public key
  • If you must share a private key, set a passphrase first with ssh-keygen -p
  • Send the key by one-time encrypted link with a separate access password
  • Don't
  • Email the key file. Sits in two inboxes and four backups.
  • Drop it in Slack or Teams. Workspace-searchable and exportable.
  • AirDrop or scp without a passphrase. Plaintext on the destination disk.

Share an SSH key now

Paste the passphrase-protected key below.

Code format, burn-after-read, password protection, and a 1-hour expiry are already on. Include the full key, BEGIN and END lines included.

Send the link, the paste password, and the key passphrase through three different channels.

Why this matters

A leaked private key is a permanent open door until someone notices and rotates it. Most key leaks aren't exploited from where they were leaked. They're harvested out of email exports, chat archives, or laptop backups months later. A one-time encrypted link with a passphrase removes both the long-lived copy and the single-secret failure mode.

Common questions

Should I ever share an SSH private key?+

Almost never. The right pattern is for each person to generate their own keypair and add their public key to authorized_keys. Share a private key only when you're cloning a service account, handing off a one-off contractor, or recovering access where rotation is genuinely not possible right now.

What's wrong with emailing the key file?+

The file ends up on your sent folder, the recipient's inbox, both providers' servers, every backup of either account, and almost certainly the recipient's Downloads folder for months. Any one of those is a single-breach away from full server access.

Should the key have a passphrase before I share it?+

Yes. If the key isn't already protected by a passphrase, add one with `ssh-keygen -p -f path/to/key` before sharing. Combined with an access-password on the paste, that's two independent secrets the attacker needs.

What expiry should I pick?+

The shortest one your recipient can realistically meet. One hour is right if you're in a live conversation. Burn-after-read makes the expiry mostly a backstop: it self-destructs on first view regardless.

Do I need to rotate the key after?+

If the key has lived in chat, email, or a ticket at any point, yes. After a clean one-time-link transfer with a passphrase, rotation is good hygiene whenever the recipient no longer needs access.

Keep reading