What an SSH key is and how it works
SSH key authentication uses a pair of keys instead of a password: private key (on the user) and public key (on the server). When the user tries to connect, the server sends a random challenge. The client signs it with the private key and returns it. The server verifies the signature with the public key and, if valid, grants access.
This mechanism is safer than passwords because the private key never travels over the network. Brute force is practically impossible โ finding a 4096-bit RSA or Ed25519 key takes millions of years. But the risk comes from people: a poorly stored private key breaks all defenses.
Key algorithms and sizes
Today the most recommended algorithm is Ed25519. It is new, fast, short (256 bits), yet provides RSA-3072 level security. If RSA must be used for older systems, at least 4096 bits is required. DSA and RSA-1024 are now considered weak and must be retired.
In Sayt.uz practice all new keys are Ed25519, old RSA-2048 keys are regenerated within 90 days. The generation command is simple: ssh-keygen -t ed25519 -C "work-email@sayt.uz". The comment (-C) helps identify the key owner and is useful for auditing.
Passphrase โ an extra protection layer
If the private key file is stolen, the attacker can log into the server immediately. A passphrase is an additional password used to encrypt the key. Even if the file is stolen, without the passphrase the key is useless. The passphrase must be strong (16+ characters) and stored in a password manager.
Many users find typing a passphrase inconvenient. But with ssh-agent it is entered once and kept in memory for the session. Sayt.uz rules: passphrase is mandatory for all production keys and recommended for dev environments too.
ssh-agent and key management
ssh-agent is a background service that temporarily holds decrypted keys in memory. This avoids re-entering the passphrase every time. Keys are loaded into the agent with ssh-add and removed when the session ends.
Important detail: ssh-agent forwarding can be dangerous. If you connect to a remote server and from there jump to another, the intermediate server can access your agent memory. The solution is to use ProxyJump (-J) or bastion host connections instead of agent forwarding.
Key rotation and audit
Keys need to be rotated periodically: personal work keys once a year, production server keys every 6 months. For automated systems (CI/CD, deploy bot) every 90 days. The old key is immediately removed from authorized_keys on the server.
Audit matters: which keys exist on each server and who owns them must be tracked in a registry. With Ansible or Terraform, authorized_keys is managed automatically and unwanted keys are removed at once. Login attempts are written to /var/log/auth.log and anomalies are sent to SIEM.
Sayt.uz practice
SSH policy at Sayt.uz: all keys Ed25519, passphrase mandatory, PasswordAuthentication=no on servers, no root login, connections only via bastion, every connection confirmed with two-factor (Duo). Authorized_keys managed by Ansible with changes tracked in git. Key rotation every 6 months, monthly audit report.