Safe SSH key handoff

Exchange public material

The recipient should generate the key pair on a trusted device and send only the public key. Verify its fingerprint through a known channel before authorization. The private key should never leave the device where it was generated and should be protected by a passphrase or hardware-backed storage.

Constrain authorization

Associate the public key with a named user rather than a shared operating-system account. Restrict source networks, commands, forwarding, environment variables, and agent use where the workflow allows. Use separate keys for separate environments so a development compromise does not automatically unlock production.

Modern SSH certificates can improve scale: a trusted authority signs short-lived user keys, hosts trust the authority, and access expires automatically. Protect the signing system carefully because it becomes a high-value control point.

Bootstrap without creating permanence

If an initial password or temporary key is unavoidable, make it single-purpose and short-lived. Confirm the new individual key works in a separate session before removing bootstrap access. Keep an authorized recovery path so a typo does not lock out every administrator.

Audit and retire

Track an owner, purpose, approval, and expiry for every authorized key. Remove access when a person changes role or a device is lost, and review dormant keys regularly. When private-key exposure is suspected, remove its authorization everywhere; deleting a local file cannot invalidate copies.

SSH access is strongest when authentication, operating-system authorization, network boundaries, and session logging reinforce one another rather than depending on an untracked file.

Sources and review basis

This guide is maintained as defensive-security education. The editorial team reviews its recommendations against current implementation experience and these authoritative references:

• OWASP Secrets Management Cheat Sheet
• OWASP Cryptographic Storage Cheat Sheet