Use ssh-agent and Hardware-Backed Keys

ssh-agent holds an unlocked private key in a local process so that an SSH client can use it without asking for the passphrase on every connection. It is a convenience boundary, not a vault: a process with access to the agent socket may ask the agent to sign data. Limit which keys are loaded, set lifetimes, and avoid forwarding the agent to hosts you do not fully trust.

Use a short-lived agent identity

Many desktop environments start an agent automatically. On a minimal shell, use the platform’s service manager where available. An explicit, temporary shell agent is version-portable:

eval "$(ssh-agent -s)"
ssh-add -t 1h ~/.ssh/id_ed25519_work
ssh-add -l

The ssh-add command prompts for the key’s passphrase without putting it in shell history. -t 1h expires this loaded identity after one hour; select a shorter lifetime for a sensitive task. Confirm that the listed fingerprint is the expected public key, and do not paste agent output containing identifying details into a public issue.

# Remove one identity by its exact private-key path.
ssh-add -d ~/.ssh/id_ed25519_work

# At the end of a disposable shell, remove all identities from that agent.
ssh-add -D
eval "$(ssh-agent -k)"

Use ssh-add -d when the key path is known. ssh-add -D removes every identity from that agent, which may disrupt other sessions, so use it only when that impact is understood. An agent lifetime does not revoke a public key already authorized on a server; retire the server-side key when the key is lost or no longer approved.

Do not forward an agent by default

Agent forwarding makes the local agent socket available through a remote host. The private key is not copied, but a compromised account on the intermediate host may request signatures while the forwarded socket is reachable. It can therefore use the user’s authority to access other servers. Keep the client default explicit:

Host *
    ForwardAgent no

Prefer ProxyJump when a bastion is only a network path; it connects through the jump host without exposing the local agent to that host:

Host internal.example
    HostName internal.example
    ProxyJump bastion.example
    ForwardAgent no

If a narrowly scoped workflow genuinely requires forwarding, use a dedicated, short-lived key with restricted server-side authorization, a short agent lifetime, and an exact host stanza. Connect with ssh -A only for that documented case, never as a global alias. On OpenSSH versions that support it, ssh-add -c can require confirmation for each use; test the local desktop prompt and recovery procedure before relying on it.

Use a FIDO security key where supported

OpenSSH can use FIDO/U2F security keys through the ed25519-sk and ecdsa-sk key types. The FIDO authenticator performs the signing operation and normally requires presence (a touch); a PIN or user-verification policy may add another control. This reduces the value of a copied laptop key. It does not replace host-key verification, account authorization, or a recovery plan, and support depends on an OpenSSH build with the necessary libfido2 support and a compatible authenticator.

ssh -V
ssh -Q key

If the output lists ssh-ed25519-sk, create a key after confirming that the security key is the intended device:

umask 077
ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_sk_work -C "admin-fido-2026"

The command may request a touch and authenticator PIN. Keep the generated public key for enrollment, protect the local key file, and register a second authenticator or another approved recovery key before depending on the first one. Resident-key options such as -O resident are useful only when the organization understands discovery and recovery; use the installed OpenSSH manual and authenticator policy rather than copying options from a different version.

Some servers, operating systems, or security policies do not support security-key algorithms. In that case, use a protected Ed25519 software key rather than weakening the server to a legacy algorithm. Hardware-backed keys still have public authorization records that must be removed when a device is lost, retired, or no longer approved.

Review the complete boundary

  • Verify the host key before the first login and keep StrictHostKeyChecking at the site’s approved setting; do not suppress changed-key warnings.
  • Load only the key needed for the task, use a finite lifetime, and inspect ssh-add -l before a privileged session.
  • Keep ForwardAgent no unless a reviewed, host-specific exception is necessary. Prefer ProxyJump for bastion routing.
  • Maintain two tested recovery paths, such as a second hardware authenticator and a separately protected administrative key. Do not store both recovery keys with the same device or account.
  • Remove retired public keys from servers and record the event. Destroy or return hardware according to the organization’s approved process.

Sequence navigation

Previous: Create and Protect SSH Keys · Next: Build a Reliable SSH Client Configuration · Return to the beginning

References