Send SSH Bastion Access with Short-Lived Keys (No Passwords)

Why a bastion + short-lived keys

A bastion (jump host) centralizes SSH entry. With short-lived keys (or OpenSSH certificates), you avoid long-term shared passwords and can revoke access quickly.

Minimal design

• Per-person accounts on the bastion; no shared logins.
• Key-based auth only; disable password login.
• Short-lived credentials: use expiring keys or OpenSSH certificates signed by a small CA.
• Network guardrails: restrict bastion by IP/VPN; servers accept SSH only from the bastion.

Safe delivery (no email attachments)

• Share only public keys (or a short-lived cert) via a one-time, expiring link and send the access code separately. Basics: The Safe Way to Share Passwords in 2025 (No Email).
• Protect private keys with a strong passphrase. How to make one you’ll remember: Create Strong Passphrases.

Rotation plan

1. Issue new short-lived certs (or keys) on a schedule or when roles change.
2. Remove old entries from authorized_keys on the bastion automatically.
3. Log & alert on unusual access; if suspicious, rotate now. Response: Incident Playbook.

Useful external references

• OpenSSH: ssh-keygen (certs & keys) 🔗
• OpenSSH: sshd_config (bastion hardening) 🔗
• Teleport: Certificate-based SSH (overview) 🔗

Related reading

SSH best practice (keys over passwords): Share SSH Access the Right Way

Secure SFTP handoffs for clients: Secure SFTP/FTP Handoffs for Clients

Developer secrets (.env) delivery: Share API Keys and .env Files (Safely)

Bottom line

Bastion first, passwords never. Use per-user keys or certs that expire, restrict the network path, and rotate routinely.

Secure One-Time Messages - Send confidential messages that self-destruct after being read once. Your privacy is our priority. →.