Back to the blog
Developers

SSH Keys Explained: How They Work and How to Use Them Safely

SSH keys replace guessable passwords with a cryptographic key pair. Learn how public and private keys work, how to generate them and how to protect them.

By Zebra Hosting Cloud

If you manage a server, you will sooner or later be told to "use SSH keys instead of passwords". It is good advice, but it often comes without explanation. This article describes what a key pair actually is, how the server uses it to recognise you, and the handful of habits that keep your keys safe.

What an SSH key pair is

An SSH key pair consists of two mathematically linked files:

  • The private key stays on your computer. It must never be shared, emailed or committed to a repository.
  • The public key is safe to share. You place it on every server you want to access.

When you connect, the server uses your public key to issue a challenge that only the matching private key can answer. Your private key never travels over the network and the server never sees it. That is the key difference from a password, which is sent (in encrypted form) and can be guessed, reused or phished.

Generating a key

On Linux, macOS and recent versions of Windows, OpenSSH includes ssh-keygen. The Ed25519 type is a modern, compact and widely supported default:

ssh-keygen -t ed25519 -C "work-laptop"

You will be asked where to save the key (the default of ~/.ssh/id_ed25519 is fine) and for a passphrase. Set one. The comment after -C is only a label that helps you recognise the key later. If a very old system cannot handle Ed25519, ssh-keygen -t rsa -b 4096 is the usual fallback.

This creates two files: id_ed25519 (private) and id_ed25519.pub (public).

Installing the public key and protecting the private one

Installing the public key

The simplest method is ssh-copy-id, which appends your public key to ~/.ssh/authorized_keys on the server with the correct permissions:

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

If that tool is unavailable, you can paste the contents of the .pub file into ~/.ssh/authorized_keys manually. Permissions matter, because SSH ignores keys in files that others can write to:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Why the passphrase matters

A passphrase encrypts the private key on disk. If your laptop is stolen or malware copies the file, the thief still cannot use the key without the passphrase. To avoid typing it constantly, use an SSH agent, which holds the unlocked key in memory for your session:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

macOS and many Linux desktops can integrate the agent with the system keychain, so you unlock once per login.

Managing several keys and servers

As you collect servers, a client-side config file saves typing. Create ~/.ssh/config:

Host myserver
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519

Now ssh myserver is all you need. Consider using separate keys for separate purposes, for example one for your personal servers and another for a client's, so that revoking one does not affect the other.

Common mistakes

  • Copying the wrong file. Only the .pub file goes to servers. If you ever paste something that begins with -----BEGIN OPENSSH PRIVATE KEY----- into a ticket or chat, treat that key as compromised and replace it.
  • No passphrase. A key without one is effectively a password written on a sticky note.
  • Never cleaning up. When a colleague leaves or a laptop is retired, remove their line from authorized_keys. Each line is one person or device.
  • Sharing one key across a team. You lose the ability to tell who did what or to remove one person without affecting everyone.
  • Ignoring host key warnings. If SSH reports that a server's host key has changed, find out why before you continue. It may be a reinstall, but it may also be interception.

Automation, hardware keys and revoking

Scripts and CI systems also need access, for example to pull from a Git repository. Give each automated job its own dedicated key with the narrowest permissions possible, and keep it out of your personal key set. Many Git hosts support read-only deploy keys that can fetch one repository but cannot push, which limits the damage if the key leaks.

Checking and revoking

To see which fingerprint a key has, run ssh-keygen -lf ~/.ssh/id_ed25519.pub. To remove access, delete the corresponding line from authorized_keys on each server. Because the server holds only public keys, there is nothing secret to rotate on its side; revoking is just removing a line.

Hardware-backed keys

Recent OpenSSH versions (8.2 and later) also support keys stored on a FIDO2 security key, created with ssh-keygen -t ed25519-sk. The private part never leaves the hardware token, and each login needs a physical touch. They are worth considering for administrator accounts on servers that matter.

Backing up and replacing keys

Your private key exists in one place, so losing the laptop can mean losing access. Keep an encrypted copy in your password manager or on an encrypted drive, and always make sure at least two trusted keys can log in to each server, for example your laptop and a backup key stored safely offline. If you have to replace a key, add the new public key first, test it, and only then remove the old line. The knowledge base has more connection tips.

Keys on Zebra Hosting servers

If you run a VPS or dedicated server with us, SSH keys are the recommended way to log in, and the steps above apply on any Linux distribution. Pick a server on the VPS plans page.

More articles