What Is an SSH Key?

Logging into a remote server with just a password works until someone guesses it, phishes it, or runs it through a brute-force script. An SSH key removes that risk by replacing the password with a cryptographic key pair that is effectively impossible to fake.

SSH (Secure Shell) is the protocol administrators and developers use to log into remote servers, move files, and run commands over an encrypted connection. An SSH key is the credential that protocol relies on instead of, or alongside, a password: a mathematically linked pair of files, one public and one private, that together prove who you are without ever sending a secret across the network.

An SSH key pair consists of two files:

• A private key, which stays on your local machine and is never shared.

• A public key, which you copy to any server you want to access.

When you connect, the server uses the public key to issue a cryptographic challenge that only the matching private key can answer. Your machine solves the challenge locally and sends back proof, not the key itself. The server checks that proof against the public key it already has on file and grants access. The private key never travels across the network, which is what makes this approach fundamentally more resistant to interception than a password.

This is the same public-key cryptography behind SSL/TLS certificates and most of modern PKI: a key pair where one half authenticates and the other verifies, and the private half never needs to leave the device that holds it.

• Resistant to brute-force and credential-stuffing attacks. A password only has to be guessed or leaked once. A properly generated SSH private key is not something an attacker can feasibly reconstruct from the public key.

• No shared secret to intercept. The private key never crosses the network, so there is nothing for an attacker on the wire to capture, unlike a password typed over a compromised connection.

• Supports automation. Scripts, CI/CD pipelines, and cron jobs can authenticate without a human typing a password, using a dedicated key scoped to one task.

• Revocable per device. Lose a laptop? Remove that one public key from the server’s authorized list instead of resetting a password everyone else also uses.

SSH supports a handful of key algorithms, and the choice affects both security and performance:

• ED25519: the current recommended default. Shorter keys, faster signing, and resistant to the implementation mistakes that have affected older algorithms.

• RSA: the long-standing standard, still widely supported. 4096-bit RSA keys remain secure, though they are larger and slower to generate and use than ED25519.

• ECDSA: elliptic-curve based, smaller and faster than RSA, less commonly recommended today than ED25519.

Most current servers and clients support all three. ED25519 is the right default unless a specific system requires otherwise.

On Linux or macOS, generate a new key pair from a terminal:

This creates two files: a private key (id_ed25519) and a public key (id_ed25519.pub). Set a passphrase when prompted. The passphrase encrypts the private key file itself, so a stolen laptop does not hand over a usable credential along with it.

To put the public key on a server, use ssh-copy-id:

Or copy the contents of the .pub file manually into the server’s ~/.ssh/authorized_keys file.

Once the public key is in place, the server can be configured to disable password logins entirely. For the full hardening sequence, including disabling root login, restricting algorithms, and adding logging, see SSL.com’s guide to securing your SSH configuration.

Both rely on public-key cryptography, and both use a key pair to prove identity without transmitting a secret, but they solve different problems. An SSH key is a bare key pair you generate yourself and manually place on each server you trust. It authenticates a person or a machine to one specific system, and nothing vouches for it beyond the fact that you put it there.

An SSL/TLS certificate adds a third party to that picture: a Certificate Authority signs the public key and binds it to a verified identity, such as a domain or an organization, that any browser or client can check without having met you before. An SSH key answers “is this the same key I trusted last time,” while a certificate answers “has a trusted third party verified who holds this key.” Managing SSH keys across dozens or hundreds of servers runs into the same lifecycle challenge certificate management already addresses: knowing which keys exist, who holds them, and when to revoke one.

An SSH key pair replaces a password with something far harder to compromise: a private key that never leaves your machine, and a public key that only confirms access; it never grants it by itself. Generate one with ssh-keygen -t ed25519, copy the public half to the server with ssh-copy-id, and turn off password logins once it is working.

Still have questions about how SSH keys work, which type to use, and how to generate one? Contact our team below: