developersecuritypasswords

How to Share SSH Keys Securely (Without Slack, Email, or Git History)

July 20, 20267 min read

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.

SSH private keys belong in encrypted, short-lived handoffs—not Slack, email, or git history. Image: programming desk via Pixabay.

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
Email	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 note

Developer extensions: share SSH keys from where you work

Handoffs fail when the secure tool is three clicks farther than Slack. PrivateNote integrations keep encryption in your editor, browser, terminal, or agent workflow. Full tour: PrivateNote for developers.

Your situation	Best path
Key is already open in the editor	VS Code / Cursor / Codex IDE extension — select → share as PrivateNote
Key is on a webpage or ticket	Chrome extension — highlight → Create PrivateNote
You are in a terminal	CLI — pipe the file so the PEM never sits in shell history
You want an agent to produce the link	MCP server — then rotate; prefer the editor extension for private keys
Recipient is non-technical	Web app link at privatenote.ai

VS Code, Cursor, and Codex IDE

Install from the marketplace (PrivateNote.privatenote-vscode), select the key block, and use Share as PrivateNote—or open the sidebar composer. Encryption runs in the editor host process, so the plaintext never has to enter an AI chat. Setup: VS Code / Cursor extension.

Chrome extension

When a key appears in a ticket, docs page, or admin console, highlight it and create an encrypted note without copying into Slack first. Install: Chrome extension.

CLI

Pipe from a file so the secret is not an echo argument in shell history: cat id_ed25519 | npx privatenote-cli --expire 15m --output-url-only. Docs: PrivateNote CLI.

MCP for Cursor, Claude, and Codex

Agents can call create_private_note after you install privatenote-mcp. Useful for orchestration—but if you paste the private key into the agent prompt, the model provider may see it before encryption. For SSH private keys, prefer the editor or Chrome extension. Codex-specific setup: PrivateNote with Codex.

Honest caveat
MCP encrypts after the agent reads the prompt. Persistent chat/email exposure is gone; AI-provider visibility is not. For private keys, use the VS Code or Chrome extension so plaintext never leaves your machine until it is already ciphertext.

Best 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.

Share the link—not the private key

Create a browser-encrypted PrivateNote with short expiry and burn-after-reading. Or encrypt from the VS Code extension, CLI, or Chrome extension so the PEM never lands in Slack as plaintext.