SSH Keys
debt(d5/e3/b3/t3)
Closest to 'specialist tool catches it' (d5). The detection_hints list lynis and ssh-audit as the tools that catch misconfigurations such as password authentication still enabled, weak RSA key sizes, missing passphrases, and root login permitted. These are specialist security audit tools rather than default linters or compilers, and the issues are silent in production unless someone actively runs these tools.
Closest to 'simple parameterised fix' (e3). The quick_fix is well-defined: run ssh-keygen -t ed25519, set PasswordAuthentication no in sshd_config, and enforce key-based auth. This is a small, focused set of changes within one configuration file and one key generation step — no cross-cutting refactor required, but it is more than a single one-line patch because it touches key generation, sshd_config, and authorized_keys distribution.
Closest to 'localised tax' (b3). SSH key management applies to the CLI/server access context. Once correctly configured (Ed25519 keys, disabled password auth, passphrases with ssh-agent), the ongoing burden is modest — mainly onboarding new developers or rotating keys. It doesn't pervade application code or shape architectural decisions broadly.
Closest to 'minor surprise' (t3). The canonical misconception per the metadata is that sharing a public key is a security risk — it isn't; public keys are designed to be shared. This is a single, well-known edge-case misunderstanding rather than a deep conceptual trap. Competent developers generally learn this quickly, making it a minor rather than serious surprise.
Also Known As
TL;DR
Explanation
SSH key authentication uses a private key (kept secret) and a public key (placed in ~/.ssh/authorized_keys on the server). Authentication works by the server sending a challenge encrypted with the public key; only the holder of the private key can decrypt and respond. Ed25519 is the current recommended algorithm — compact, fast, and secure. RSA 4096 is acceptable. Keys should be protected with a passphrase; use ssh-agent to avoid re-entering it.
Common Misconception
Why It Matters
Common Mistakes
- Using RSA 1024 or RSA 2048 — use Ed25519 or RSA 4096 minimum.
- Not setting a passphrase on private keys — an unencrypted key file found anywhere grants full access.
- Not using ssh-agent — repeatedly decrypting the key passphrase manually, or worse, removing the passphrase.
- Leaving password authentication enabled alongside key auth — brute force still possible.
Code Examples
# Insecure SSH setup:
ssh-keygen -t rsa -b 1024 # Too short
# No passphrase set
# /etc/ssh/sshd_config:
PasswordAuthentication yes # Still allows password login# Secure SSH key generation:
ssh-keygen -t ed25519 -C 'deploy@company.com'
# Enter strong passphrase
eval $(ssh-agent)
ssh-add ~/.ssh/id_ed25519 # Cache passphrase for session
# /etc/ssh/sshd_config:
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no