SSH Client and Key Management Hardening

Authored by:

Dickson Wu

SEAL

Reviewed by:

matta

The Red Guild | SEAL

Piña

Summary

🔑 Key Takeaway for SSH Client and Key Management Hardening: Use dedicated SSH keys for distinct purposes, prefer Ed25519 for new software keys, use hardware-backed *-sk keys for higher-risk access where practical, protect keys with passphrases, keep agent forwarding off by default, and maintain a simple revoke-and-reissue plan for lost devices or role changes.

SSH is often the path from a developer laptop into code hosting, CI/CD, bastions, and production infrastructure. Treat SSH keys as privileged access.

For Individuals

These steps apply to developers, operators, admins, and contributors who use SSH from a local workstation.

Setup Checklist

Passphrases and Local Protection

• Use a passphrase on every human-held software key
• Avoid leaving sensitive keys loaded into an agent indefinitely
• Prefer confirmation or time-limited agent loading for sensitive keys
• Do not store private keys in cloud notes, chat, or shared drives
• Avoid copying the same private key between multiple laptops or admin workstations

~/.ssh/config Hygiene

Keep ~/.ssh/config explicit and purpose-specific so your SSH client offers only the intended key to each service.

• Use per-host entries with IdentityFile and IdentitiesOnly yes
• Keep ForwardAgent no unless there is a reviewed exception
• Use stricter host verification for bastions and production hosts than for low-risk systems

Agent Forwarding and Remote Risk

Treat agent forwarding as an exception, not a default workflow.

• Keep ForwardAgent no by default
• Never use Host * with ForwardAgent yes
• Prefer ProxyJump, a bastion pattern, or a purpose-specific key on the intermediary host instead

Agent forwarding lets a remote system use your loaded identities for as long as the session is live, so it is a poor default for weakly trusted systems.

Host Verification and known_hosts

Do not normalize StrictHostKeyChecking no or "just click through" behavior for host key changes.

• Verify important host fingerprints from official documentation when available
• Use accept-new only where trust-on-first-use is acceptable for the environment
• Use yes for bastions, production systems, and other high-sensitivity hosts
• Do not rely on accept-new for first contact with high-sensitivity systems
• Preseed known_hosts for CI and automation from a trusted source instead of discovering keys live in the job
• Investigate unexpected host key changes instead of bypassing the warning

File Permissions and Device Hygiene

• On Unix-like systems, use chmod 700 ~/.ssh
• Use chmod 600 for private keys and for ~/.ssh/config
• On Windows, keep private keys readable only by your user account and administrators

If a laptop is lost, stolen, or suspected compromised, assume the SSH material on it may also need to be revoked and reissued.

For Admins

These practices apply to administrators responsible for issuing, reviewing, rotating, and revoking SSH access across a team.

Program Checklist

Git Hosting, CI/CD, and Automation

• Human users should have account-level SSH keys with clear labels
• CI/CD and deployment systems should use dedicated automation credentials, not a developer's personal laptop key
• Review deploy keys carefully because they are often long-lived and easy to forget
• Revoke and reissue keys promptly after device loss, offboarding, or suspected compromise

Higher-Maturity Option: SSH Certificates

For larger teams or higher-sensitivity environments, consider using SSH certificates instead of managing long-lived authorized keys on each target system.

With SSH certificates, a trusted internal certificate authority (CA) signs user or host keys for a limited period of time. This can make access management easier by allowing teams to:

• Issue short-lived SSH access without distributing permanent keys to every host
• Centralize approval, expiration, and revocation workflows
• Reduce the operational burden of updating authorized_keys across many systems
• Tie SSH access more closely to role, device, or incident-response requirements

SSH certificates introduce their own operational complexity and should be implemented carefully, but they are worth evaluating for organizations that need stronger central control over SSH access.

Web3-Specific Operational Rules

Use these rules consistently:

1. Do not use the same SSH key for Git hosting, deploy systems, and production administration.
2. Treat bastion, production, and incident-response SSH access as privileged and higher assurance.
3. Keep agent forwarding off unless there is a reviewed exception.
4. Investigate host key changes before reconnecting to important systems.
5. Revoke and replace SSH keys immediately after device loss or admin-role changes.
6. Keep automation credentials separate from human workstation credentials.

Further Reading

• NIST IR 7966: Security of Interactive and Automated Access Management Using Secure Shell (SSH)
• OpenBSD ssh_config(5)
• OpenBSD ssh-keygen(1)
• OpenBSD ssh-add(1)
• GitHub: Generating a New SSH Key and Adding It to the SSH Agent
• GitHub: Reviewing Your SSH Keys
• GitHub: GitHub's SSH Key Fingerprints
• GitLab: SSH Keys
• GitLab: Using SSH Keys with GitLab CI/CD
• Microsoft Learn: OpenSSH Key Management on Windows