Why should private SSH keys never be shared or transmitted across team members?

A private SSH key is mathematically tied to an individual's cryptographic identity. Sharing private keys destroys audit accountability, prevents selective access revocation, and creates single points of failure across multiple engineer workstations.

What is the correct protocol for granting a developer SSH access to a server?

The developer generates a public/private key pair (e.g. Ed25519) on their own local machine, keeps their private key secret, and shares only their public key (id_ed25519.pub) with the server administrator to append to ~/.ssh/authorized_keys.

When is a secure one-time link useful in SSH and server administration workflows?

One-time links are ideal for securely delivering initial temporary root/sudo passwords, emergency break-glass credentials, or key passphrases without putting them into Slack channels or ticket systems.

What should you do immediately if a private SSH key is accidentally committed or shared?

Treat the key as fully compromised: immediately remove the corresponding public key from ~/.ssh/authorized_keys across all servers, generate a brand new keypair, and rotate any credentials that used that key.

What is the difference between Ed25519 and RSA SSH keys?

Ed25519 is an Edwards-curve cryptographic algorithm providing superior security, performance, and resistance to side-channel attacks compared to legacy RSA algorithms. It is the modern industry standard for SSH keys.

Can Paste & Purge read server credentials or tokens transmitted through its links?

No. Secrets are encrypted locally in your browser with AES-256-GCM using Web Crypto APIs. The decryption key exists only in the URL hash fragment (#), which web browsers never transmit to the server.

DevOps Cryptography Guide

How to Share SSH Keys and Private Keys Safely

Published by Paste & Purge · Engineering Best Practices · 9 min read

Secure Shell (SSH) is the standard protocol for managing remote Linux servers, executing automated deployment pipelines, and authenticating with Git code repositories. Authentication relies on asymmetric cryptographic key pairs: a public key and a private key.

Because private keys grant root-level server access and bypass interactive passwords, improper handling or transmission of key material represents one of the most critical security vulnerabilities in modern DevOps.

Public Key (.pub)

Safe to share openly. Placed on destination servers in ~/.ssh/authorized_keys to verify incoming connections.

Private Key (No extension)

Extremely sensitive cryptographic secret. Proves identity to the server. Should never be shared when an alternative workflow is possible.

The Golden Rule: Provision a New Key Instead of Sharing a Private Key

In standard engineering workflows, you should rarely need to send a private key to another person. The industry-standard approach is:

Have the recipient generate their own key pair locally: ssh-keygen -t ed25519 -C "developer@company.com"
The recipient transmits only their public key (id_ed25519.pub) to you.
You append their public key to the target server's authorized_keys file.
When access is no longer required, simply delete their public key line from the server.

When Private Key Transmission Might Occur

While provisioning individual keys is the gold standard, specific operational scenarios sometimes require temporary transmission of private cryptographic material:

Shared CI/CD Service Account Deploy Keys

Transferring an automated build deploy key to a new deployment runner or air-gapped server environment.

Server Migration & Host Key Transfers

Migrating legacy servers where preserving existing SSH host keys is necessary to avoid host key fingerprint mismatch warnings.

Client-Supplied Staging Certificates & Keys

A client providing a dedicated temporary access certificate for an isolated staging environment during a time-sensitive emergency.

Safe Handling Checklist for Private Keys

1. Always Encrypt with a Passphrase

Never use unencrypted private keys. If a private key lacks a passphrase, add one before sharing using: ssh-keygen -p -f ~/.ssh/id_ed25519.

2. Enforce Strict Permissions (chmod 600)

Once downloaded, the recipient must lock down file permissions: chmod 600 ~/.ssh/id_ed25519 and chmod 700 ~/.ssh.

3. Use One-Time Client-Side Encrypted Transmission

Never paste private key blocks into Slack, Jira, or email. Transmit via a single-view, client-side encrypted Paste & Purge link with a secondary passphrase.

Critical Mistakes to Avoid

✕Never commit private keys or .pem files to Git repositories (even private repos).
✕Never paste private keys into unencrypted helpdesk tickets or project management cards.
✕Do not share personal developer private keys; provision distinct keys for each engineer.
✕Never assume deleting a secret link revokes server access; always manage authorized_keys.

Frequently Asked Questions

Transmit Developer Secrets Without Plaintext Traces

Create client-side encrypted, 1-view secret links for temporary tokens, configurations, and sensitive key material. Keep your chat logs and email archives clean.