Skip to main content

Common Misconfiguration

Committed SSH private keys provide unauthorized access to servers and can lead to complete infrastructure compromise.

Vulnerable Example

Secure Example

Detection Patterns

  • RSA Private Key: `-----BEGIN RSA PRIVATE KEY-----`
  • OpenSSH Private Key: `-----BEGIN OPENSSH PRIVATE KEY-----`
  • Generic Private Key: `-----BEGIN PRIVATE KEY-----`
  • DSA Private Key: `-----BEGIN DSA PRIVATE KEY-----`
  • EC Private Key: `-----BEGIN EC PRIVATE KEY-----`

Prevention Best Practices

  1. Never Commit Private Keys: This is the golden rule. Private keys (id_rsa, .pem files) should never be in your Git repository, configuration files, or embedded in scripts. Use .gitignore to prevent accidental commits.
  2. Use SSH Agent Forwarding: For tasks like CI/CD deployments, use SSH agent forwarding. Your local agent manages the key securely, and the remote server can use it without having the key file itself. Be cautious, as agent hijacking is possible in untrusted environments.
  3. Protect Keys with Strong Passphrases: Encrypt your private SSH keys with a strong, unique passphrase. This adds a crucial layer of security if the key file is stolen. Use ssh-keygen -p to add or change a passphrase.
  4. Set Correct File Permissions: Private key files must have strict permissions (chmod 600 ~/.ssh/id_rsa). SSH clients will often refuse to use keys with overly permissive settings (like 644 or 777).
  5. Use Separate Keys: Don’t use the same SSH key for everything. Use different keys for different services, environments (dev vs. prod), and levels of access. This limits the blast radius if one key is compromised. Deploy keys (specific keys for specific repositories) are better than user keys for automation.
  6. Implement Key Rotation: SSH keys, especially those used for automation, should be rotated regularly (e.g., every 90 days). This limits the window of opportunity if a key is compromised silently.
  7. Use Bastion Hosts (Jump Boxes): Do not expose your production servers directly to the internet. Require users and automation to connect through a hardened bastion host first. Access to the bastion should be tightly controlled and monitored.
  8. Enable SSH Key Audit Logging: On servers, configure SSH daemon (sshd) logging to record key fingerprints used for authentication (LogLevel VERBOSE). This helps trace which key was used for potentially malicious access.
  9. Consider SSH Certificates: For larger organizations, SSH certificates (signed by a Certificate Authority) offer advantages over raw keys, including short lifespans, easier revocation, and role-based access without managing authorized_keys on every server.