SSH private key passphrase status could not be determined
What this means
The file at ‹path› (format: ‹key format›) is a private key, but its encryption header could not be parsed, so Bulwark cannot confirm whether it is passphrase-protected. Rather than guess — and risk reporting a plaintext key as safe — it is surfaced here for you to check by hand. A healthy key does not normally hit this state, so the file may be truncated, corrupted, or in a format this version doesn't fully recognize.
How to fix it
Inspect the key directly: ssh-keygen -y -f ‹path› will prompt for a passphrase if one is set (and error out plainly if the file is malformed). If it is unprotected, add a passphrase with ssh-keygen -p -f ‹path›. If the file is corrupt or not actually a key you use, remove or restore it.
Check it yourself
Run a scan and look for BLWK-SSH-013 in the results:
bulwark scanInstalled 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:
encryption_known == falseIf 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
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 is not passphrase-protected ·
BLWK-SSH-012 - A secret is exposed in AI assistant context ·
BLWK-AI-001