HighSecrets & credentialsBLWK-SSH-012

SSH private key is not passphrase-protected

What this means

Your SSH key ‹path› has no passphrase. It works like a password that is written down: anyone or any program that copies this one file can log in to every server and Git host that trusts it, with nothing else needed.

How to fix it

Lock the key with a passphrase. It takes a minute and your servers need no changes.

1. In the Bulwark app, open this issue and use “Add a passphrase”. In a terminal, run ssh-keygen -p -f ‹path›.
2. To avoid typing it all the time, load the key once per session with ssh-add ‹path›.
3. Delete keys for machines you no longer use.

Stronger options: keep keys in a password manager's SSH agent (Bitwarden, 1Password, KeePassXC), or use a hardware key that cannot be copied at all (ssh-keygen -t ed25519-sk with a YubiKey).

Bulwark can do this for you

In the app, open the issue and use “Add a passphrase”. From a terminal: bulwark ssh protect.

Check it yourself

Run a scan and look for BLWK-SSH-012 in the results:

bulwark scan

Installed the standalone CLI package instead of the app? The command is bulwarkctl.

How Bulwark decides

Bulwark reads ssh_private_keys and reports this check when:

encrypted == false and encryption_known == true

If a value can't be read, Bulwark reports the check as undetermined rather than passing it. View the rule source.

References

• CIS Benchmark 5.2
• MITRE ATT&CK T1552.004
• MITRE ATT&CK T1078

Related checks

• A long-lived AWS access key is stored on disk · BLWK-CRED-001
• Git stores passwords and tokens in plain text · BLWK-CRED-002
• Docker registry logins are stored in the config file · BLWK-CRED-003
• A credential file can be read by other users · BLWK-CRED-004
• SSH private key passphrase status could not be determined · BLWK-SSH-013
• A secret is exposed in AI assistant context · BLWK-AI-001