SSH keys in a nutshell
SSH keys replace passwords for logging into servers, pushing to Git hosts and running deployment pipelines. A key pair has
two halves: the private key, which never leaves your machine, and the public key, which
you copy to ~/.ssh/authorized_keys on a server or paste into GitHub, GitLab or your CI provider. When you
connect, the server challenges your client to prove it holds the private key without ever transmitting it.
Choosing a key type
- Ed25519 is the modern default: 256-bit keys that are fast, compact (the public key fits on one short line) and resistant to many implementation pitfalls.
- RSA offers the widest compatibility with legacy systems and network appliances. Use 3072 or 4096 bits; 2048 is the bare minimum today.
- ECDSA (NIST P-256, P-384, P-521) is sometimes required by compliance frameworks such as FIPS.
The private key can be exported in the OpenSSH format used by modern ssh clients or as
PEM (PKCS#8) for libraries and tools that expect it. Adding a passphrase encrypts the private key file,
so a stolen copy is useless without it.
Using your new key
chmod 600 ~/.ssh/id_ed25519 # private keys must not be readable by others
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server
ssh -i ~/.ssh/id_ed25519 user@server
The SHA256 fingerprint shown next to the key is what ssh-keygen -lf prints and what servers display on first
connection, so you can confirm you installed the right key.
Security and privacy
Keys are generated on our server with the audited cryptography library, held only in memory for the request
and returned over HTTPS with caching disabled; nothing is logged or stored. Because any key generated outside your own
machine has, by definition, existed elsewhere, we recommend this tool for development, testing, CI fixtures and learning.
For long-lived production access, run ssh-keygen -t ed25519 locally.