How to Securely Share SSH Keys and Certificates with Your Team

"Just send me the SSH key on Slack." Every development team has heard this. Server access is urgent, a new team member needs to set up their environment, deployment is minutes away and someone is missing the key.

But this one request can be the start of a serious security incident.

Why SSH Key Sharing Is Especially Dangerous

SSH keys are not like regular passwords. They grant complete access to a server.

Factor	Password	SSH Key
Scope	Specific account	Entire server
Impact if leaked	That account	All data on the server
Ease of rotation	Change instantly	Regenerate key + update all servers
2FA support	Available	Key itself is the authentication

A leaked SSH key exposes every file, every database, every piece of code on the server. This is fundamentally different from a single password leak.

When Teams Need to Share SSH Keys

Realistically, there are legitimate reasons for sharing.

• Shared server access: Staging or production servers the whole team needs
• Deploy keys: Keys used in CI/CD pipelines
• SSL certificates: Certificate renewal when responsibilities change
• API secrets: Authentication credentials for third-party integrations
• Database credentials: Emergency incident response

Dangerous Sharing Methods

1. Slack or Discord DMs

Chat history is permanently stored on servers. Anyone can search for "ssh" or "key" to find previously shared keys. Even accounts of former employees retain the history.

2. Email

Permanently archived on mail servers and uncontrollable once forwarded. A single mail server breach exposes every key ever sent.

3. Shared Google Drive or Notion

Granular access control is difficult. When files sync, local copies remain on devices. Recovering all copies when someone leaves the team is practically impossible.

4. Committed to a Git Repository

The most dangerous method. Keys persist forever in Git history. Even deleted files can be recovered from history. If the repo is public, the key is exposed globally.

Secure Sharing Methods

Method 1: LOCK.PUB Secret Memo (Best for One-Time Transfers)

The most practical solution when you need to transfer a key once.

1. Create a secret memo on LOCK.PUB
2. Paste the SSH key or certificate content
3. Set a strong password
4. Set the shortest expiration possible (1-4 hours)
5. Send the link via Slack, share the password by phone
6. After the recipient saves the key locally, the link expires

Benefits:

• The key is not stored in plaintext on any persistent server
• Inaccessible after expiration
• No key plaintext in chat history

Method 2: Secrets Managers (For Larger Teams)

Use dedicated tools like HashiCorp Vault, AWS Secrets Manager, or Google Secret Manager.

• Access control and audit logs included
• Automated key rotation possible
• Cost and setup complexity are downsides

Method 3: SSH Certificate Authority (Long-Term Solution)

Instead of shared keys, run an SSH CA that issues individual certificates to each user.

• Eliminates the need for key sharing entirely
• Per-user access management
• Higher initial setup cost

Method 4: Per-User Keys (Most Recommended)

When possible, issue individual keys instead of sharing one key across the team.

Principle: Shared key < Individual keys
Shared key leaked → Entire team affected
Individual key leaked → Only that user affected

Checklist When You Must Share

If per-user keys are not an option and sharing is unavoidable, follow this checklist.

Before Transfer

• Have you set the minimum permission scope for the key?
• Would a read-only key be sufficient?
• Can you apply IP restrictions?

During Transfer

• Are you sending the key and password through different channels?
• Have you set the shortest practical expiration?
• Can the sender delete the original after the recipient confirms?

After Transfer

• Confirm the recipient has stored the key securely
• Verify the shared link/memo has expired
• Monitor key usage logs

Key Rotation Schedule

Regular key rotation limits the validity window of any compromised key.

Key Type	Recommended Rotation
Production server keys	90 days
Deploy keys	90 days
SSL certificates	At each renewal
API secrets	90 days
Development/staging keys	180 days

Security Checklist for DevOps Teams

• Are individual SSH keys used for all servers?
• If shared keys exist, are IP restrictions configured?
• Are departing employees' keys immediately deactivated?
• Is a key rotation schedule in place?
• Have SSH keys ever been committed to a Git repo?
• Are any keys stored in plaintext in chat history?
• Is an expiring channel used for secret transfers?

Summary

SSH keys and certificates are the backbone of server security. Sending them over Slack DM or email is like pinning your house key to a public bulletin board. Issue per-user keys when possible. When sharing is unavoidable, use a secret memo with the shortest possible expiration.

Create a secret memo now to securely transfer SSH keys.

Create a Secret Memo