An SSH key passphrase protects the file, not the route

A backup drive from a former laptop still contains an SSH private key, and someone asks whether the VPN protects it. It does not, and it never did. The VPN protects a path between two networks; the passphrase protects the file; the agent protects a running session. Three different mechanisms, three different failure modes, and a stolen copy only cares about the first two.

The passphrase belongs to the file

An SSH key passphrase encrypts the private key material at rest. It is not the account password sent to the server, and it is not the credential used to join the VPN. Confusing them leads to changes that do not address the exposure.

OpenSSH's ssh-keygen manual covers passphrase handling, including the -p switch that sets a new passphrase on a key that already exists.

For an existing key the command shape is simple, and it rewrites the file:

ssh-keygen -p -f ~/.ssh/id_ed25519

Use the key owner's approved maintenance and recovery process, because this is a write, not an inspection. Do not publish the private file or put a real passphrase on a shared command line. A passphrase change does not re-encrypt a copy that was taken earlier. Keep the old copy's location in the ticket so the owner can decide whether to destroy it.

A copy outlives the laptop and the tunnel

Once a key file has been copied, the laptop's live VPN connection no longer says anything about it. What matters is how well the file itself is protected, and which servers still trust the matching public key.

Changing the passphrase on the current file does not touch the copy, and it does not remove the same public key from authorized_keys on a server. Revocation and re-encryption are separate actions.

So treat a leaked private key as an identity event, not a network event. Remove or replace the accepted key through the servers and the enrollment process that own it. Stopping the VPN limits one route at one moment; it is not revocation.

Unlocking moves the secret into an agent

An agent holds decrypted identities for later authentication, so the user does not retype the passphrase for every connection. That is a usability feature with a security boundary of its own.

ssh-agent can cap how long an identity stays loaded through its -t option, and a per-identity setting may override that cap. Choose the policy for the agent you actually run instead of assuming a VPN disconnect forgets every loaded key.

A process that gets compromised after the key is unlocked is a different problem than a stolen encrypted file. Forwarding the agent to another host delegates authentication capability without copying the key file, so enable it only for an approved need.

List what the agent currently holds before and after a change:

ssh-add -l

Unattended jobs need their own plan

A scheduled job cannot answer a prompt. It needs an approved machine-credential arrangement, and keeping the unlocking secret in the same directory as the key, readable by the same account, does not create a second boundary.

Work with the service owner on supported secret delivery or hardware-backed operation, and cover renewal, failure, and recovery. Wanting a human at the keyboard changes what failure looks like compared with a host that boots with nobody watching.

Keep the server's host-identity check and its account restrictions as well. A VPN route gives you a private path; it does not prove that every SSH listener you can reach is the host you intended. Record the listener and the host key fingerprint in the same inventory as the key itself.

Verify the boundaries separately

Test each boundary with its own question. Does the file open without the passphrase? Does the agent still hold the identity after a disconnect? Does the server still accept the public key?

Two commands answer the first and third:

ssh-keygen -y -f ~/.ssh/id_ed25519
ssh -v [email protected]

Record file protection, allowed key use, and server-side removal as three separate line items. A tunnel, a passphrase, and an agent each guard a different piece of the relationship, and only one of them is about the network.