How to Share SSH Keys Securely
Without Slack, email, or Git history
Public keys are safe to share. Private keys are not. Learn when to avoid private-key handoffs, how to deliver one with a burn-after-reading encrypted link, and which PrivateNote developer extensions keep PEMs out of chat.
Key takeaways
- Private SSH keys never belong in chat, email, or tickets.
- Prefer short-lived access or certificates over shipping long-lived keys.
- If you must hand off a key, use an encrypted one-time link.
- Rotate or revoke after the task ends.
A teammate needs onto the staging box. A contractor needs a deploy key for the weekend. Someone’s laptop died and the only remaining access is the private key on your machine.
The fastest path is usually the same bad habit: paste the PEM block into Slack, email it “just this once,” or drop it into a ticket. That message syncs to phones, lands in search indexes, and can sit in backups long after the emergency is over.
SSH private keys are high blast-radius secrets. One leaked key can mean full shell access. This guide covers when you should share a private key at all, what never to paste into chat, and how to hand one off with a burn-after-reading encrypted link—plus the PrivateNote developer extensions that make the secure path the fast one.
Public key vs private key (30 seconds of clarity)
An SSH key pair has two halves. The public key is designed to be shared: you add it to ~/.ssh/authorized_keys, a cloud console, or a GitHub deploy key. Sending someone’s public key in chat is normal.
The private key (id_ed25519, id_rsa, a .pem file) is the secret. Anyone who has it can authenticate as that identity until you revoke access. Treat it like a password that unlocks a server—because that is what it is.
If your instinct is “we need to share the private key,” pause. In many cases you should share the public key instead: the recipient generates their own pair locally and you authorize their public key on the host.
Rule of thumb
Prefer adding their public key over sending your private key. Private-key handoffs are for break-glass and legacy cases—not default onboarding.
Prefer not sharing the private key
Before you encrypt and send anything, ask whether the private key must move at all:
Add their public key
Have them run ssh-keygen, send you the .pub file (safe in chat), and append it to authorized_keys or the provider’s SSH settings. They keep the private half; you never see it.
Use a purpose-built deploy key
For CI or a single repo, create a dedicated deploy key with the minimum scope. Avoid reusing a personal laptop key across systems.
Prefer short-lived access
Where your stack supports it—SSH certificates, bastion jump hosts, Tailscale SSH, cloud IAM roles—prefer time-bounded access over copying long-lived private keys.
When private-key handoff is justified
Break-glass recovery, a legacy host that cannot enroll new keys quickly, or an emergency where only one passphrase-protected key exists. Even then: encrypt the transfer, keep expiry short, confirm receipt, then rotate or revoke.
Where SSH keys die in the wild
The same channels that leak API keys and passwords leak SSH material—often with worse consequences.
| Channel | Why it fails | What attackers get |
|---|---|---|
| Slack, Teams, Discord | Searchable history, device sync, workspace exports | Full private key in plaintext forever |
| Inboxes, archives, mobile sync, forwards | A durable copy you cannot reliably erase | |
| Tickets & docs | Jira, Notion, Confluence, GitHub issues | Keys in backups, AI search, and audit trails |
| Git repositories | History is sticky; “delete and push” does not erase | Scanners find PEMs in minutes on public repos |
If the secret has already appeared in chat or git, assume it is burned. Revoke the key, generate a new pair, and deliver the replacement through a one-time encrypted link—not another paste. For pipeline and .env leaks, see secrets in CI/CD and GitHub.
A safer SSH private-key handoff
When you must move a private key, treat the transfer as temporary delivery—not storage. The same pattern used for passwords and API keys applies: encrypt locally, send a link, burn after read, then rotate.
PrivateNote encrypts in the browser (or in your editor/CLI) with AES-256-GCM before anything reaches the network. The decryption key lives only in the URL fragment—the #… part browsers never send to servers. Details: what end-to-end encryption means here and how to make a private note.
A practical break-glass workflow:
- 1
Step 1
Scope and protect the key
Prefer a dedicated key for this host or task. Use a passphrase on the private key. Avoid shipping your daily personal identity key if a narrower key will do.
- 2
Step 2
Encrypt locally
Paste only the key material (not a novel of hostnames and usernames) into PrivateNote via the web app, VS Code / Cursor extension, CLI, or Chrome extension.
- 3
Step 3
Send the link—not the PEM
Share the encrypted link in Slack or email. Optionally enable passphrase wrapping and send that passphrase on a separate channel (split-channel tip). Prefer 15 minutes or 1 hour expiry and burn-after-reading.
- 4
Step 4
Confirm, then rotate
Recipient installs the key with correct permissions (
chmod 600), confirms login, then you revoke the old key or rotate. Treat any key that sat in an AI prompt as seen—rotate it.
Need to hand off an SSH key now? Create an encrypted one-time note and send the link instead of the private key.
Create a private noteBest practices and pitfalls
Never commit private keys
Keep id_* and *.pem out of repos. Add them to .gitignore. If a key hit git history, rotate it—rewriting history is not enough once the repo was cloned or scanned.
Fix file permissions
Private keys should be chmod 600 (or 400). SSH will refuse overly permissive key files on many systems—and world-readable keys on shared machines are an own-goal.
Do not put context inside the note
Put only the key material in the encrypted note. Send hostname, username, and port in a separate message. If the link leaks, the attacker should not also get a labeled map of what it unlocks.
Passphrase and split channels
Passphrase-protect the key file itself, and optionally wrap the PrivateNote with a separate passphrase sent on another channel. Same guidance as secure password sharing.
Agent forwarding is not a sharing strategy
SSH agent forwarding can reduce key copies on remote hosts, but it is not a substitute for careful key distribution—and it expands trust to every hop you forward through. Use it deliberately, not as an excuse to email PEMs.
Frequently asked questions
Is it safe to send a public key in Slack?
Yes. Public keys are meant to be distributed. Still avoid dumping entire ~/.ssh directories—people accidentally include private files.
Can I put an SSH private key in a password manager?
For long-term storage of keys you keep, a password manager or hardware-backed agent is appropriate. Use a one-time encrypted link for the human-to-human delivery moment—then the recipient stores the key properly. PrivateNote is delivery, not a secrets vault.
Should I share the key and the passphrase together?
No. That recreates a single point of failure. Send the encrypted link on one channel and any passphrase on another—or have the recipient set their own passphrase after install and rotate.
What expiry should I use?
For live coordination, 15 minutes with burn-after-reading. For async contractor handoffs, 1 hour or 1 day at most. Prefer shorter whenever the recipient is reachable.
Is PrivateNote a replacement for Vault or cloud secret managers?
No. Use Vault, AWS Secrets Manager, and similar tools for machine-to-machine storage and injection. Use PrivateNote for the person-to-person moment when a key must cross chat or email without becoming a permanent archive. Same distinction as in the API key guide.
Final thoughts
Most SSH “sharing” problems are really enrollment problems: add a public key, use a deploy key, or issue short-lived access. When a private key must move, do not leave it in chat history or email.
Encrypt locally, send a self-destructing link, confirm install, then rotate. Wire the developer tools you already use so the secure path is also the path of least resistance.