Skip to content
hostcomplex

SSH Keys Explained

Maarten Soetens 3 min read

How a Key Pair Proves Your Identity

SSH keys are a pair of linked files, a public key and a private key, that prove your identity to an SSH server without sending a password. The public key goes on the server, while the private key stays secret on your own computer.

When you connect, the server sends a challenge that only the holder of the private key can answer. Your client signs the challenge with the private key, and the server checks that signature against the public key it has on file. The private key itself never crosses the network.

Key pairs are created with a key generator included in SSH software. Current key types include Ed25519 and RSA, and the type and length affect strength. A key pair works only where its public half has been installed, so each server you access needs the matching public key.

Where the Public Key Lives on the Server

On the server, accepted public keys are listed in a file named authorized_keys, kept in the hidden .ssh folder of the user's home directory. Each line holds one public key, and the server checks each incoming key login against those lines. Removing a line revokes that key without affecting other keys or passwords.

Because this file grants access, its ownership and permissions matter. OpenSSH checks that other users cannot write to these files and folders, and it refuses to use them if they are too open. The same idea of restricting access by ownership is explained in the article on file permissions.

Why Keys Are Safer Than Passwords

A password is a secret that you type and the server checks, and it can be guessed, phished or captured. Automated attacks try large lists of common passwords against exposed login pages. A key pair removes most of that risk, because the private key is a long random value that never leaves your computer and cannot practically be guessed.

A passphrase adds a second layer. It encrypts the private key file on your computer, so a stolen copy is not immediately usable. The trade-off is that you enter the passphrase when you use the key, unless a local SSH agent keeps the key unlocked for your session. Key-based login is also how many SFTP clients authenticate.

Keys are not risk-free. A copied, unprotected private key gives full access, so storing it safely matters as much as protecting a password. Keys also need to be removed from the server when a person leaves or a device is lost, which is why the list of installed keys should be reviewed regularly.

Frequently asked questions

Can One SSH Key Work on Several Servers?

Yes. The same public key can be placed in the authorized_keys file on several servers. However, a single key shared across many machines means that one compromised private key exposes all of them. Many administrators use separate keys for each device or purpose to limit that risk.

What Happens If I Lose My SSH Private Key?

The private key cannot be recovered from the server, because the server holds only the public half. Access that depended on that key is lost, so you need another working key or account, or your host's own recovery process, to install a new public key. Keeping a secure backup of private keys avoids this problem.

  • Two-Factor Authentication

    Two factor authentication hosting adds a second check to control panel, domain and CMS logins. Learn which methods are strongest and why 2FA helps.

  • What Is an A Record?

    What is an A record? Learn how this DNS record maps a hostname to an IPv4 address, why domains use several A records and the root and www pattern.

  • Billing and Automation Platforms

    What is WHMCS? Learn how this commercial billing and automation platform helps hosts sell plans, collect payments and create accounts automatically.