No password to type and no secret crossing the wire. An SSH key turns a login into a matched pair of files, one guarded on your own machine and one waiting on the server, and this guide explains how the pair works and how to use it safely.
An SSH key is a pair of matched files that logs you into a server without a password. One half, the private key, stays on your own computer and never leaves it. The other half, the public key, sits on the server. When you connect, your computer proves it holds the private half, and the server lets you in. No password gets typed, and no secret travels across the network.
Think of a padlock and its key. You can hand out copies of the padlock to anyone, because a padlock alone opens nothing. The one key that fits it stays in your pocket. SSH keys work the same way, except the math behind them means nobody can copy your key just by studying the padlock. This guide answers the questions behind the search: what is an SSH key, how does it log you in, which type should you create, and how do you use one without weakening it.
| The pair at a glance | |
|---|---|
| Private key | A secret file on your computer, such as ~/.ssh/id_ed25519. Never share it. |
| Public key | The matching file with a .pub ending. Safe to copy onto servers and services. |
| Where the server keeps it | One line per key in ~/.ssh/authorized_keys on the server. |
| How it logs you in | Your computer signs a challenge with the private key. The server checks the signature. |
| Biggest risk | A stolen private key with no passphrase works at once, like a copied house key. |
What is an SSH key, in plain words
Start with SSH itself. SSH, short for Secure Shell, is the standard way to log into another computer over a network and run commands as if you were sitting at its keyboard. System administrators use it to run servers, developers use it to reach code hosting such as GitHub, and tools use it quietly in the background for file transfers. The connection is encrypted, so nobody listening in can read what passes between the two machines.
An SSH key is the credential that connection checks. Instead of a password, which is a secret you and the server both know, an SSH key is a pair of files created together by one of the standard public key algorithms. Public key cryptography, the math behind the pair, has a strange and useful property: the two halves match only each other, and seeing the public half tells you nothing practical about the private half. Deriving one from the other would take longer than anyone can wait.
The OpenSSH manual sums the split up in one line: the server knows the public key, and only the user knows the private key. That split is the whole design. The public key can sit on a hundred servers and appear in public without weakening anything. The private key file is the single thing to guard, and the rest of this guide treats it that way.
How the login works: a signature, not a secret
A password login hands the server a secret and asks it to compare. A key login never hands over a secret at all. What is an SSH key doing at login, then? Working as a signature stamp. The full exchange, described in the OpenSSH manual for the ssh client, runs in three plain steps.
First, your SSH program connects and tells the server which public key it wants to use. The server checks its authorized_keys file, the list of public keys permitted to log in, and confirms your key is on it. Second, your computer signs data tied to this session using the private key. Only the holder of that private key can produce the signature. Third, the server verifies the signature with the public key it stores. A valid signature proves you hold the matching private key, and the login succeeds.
Notice what an eavesdropper collects from watching this: a signature that works for one session and nothing else. There is no password to replay tomorrow and no private key in transit to steal. The same public and private key idea, scaled up with certificates that attach names and expiry dates to keys, becomes public key infrastructure, the system behind the padlock in your browser.
Why keys beat passwords, and the one catch
Keys win on three counts. First, there is nothing reusable to steal. A server stores only public keys, so a leaked server database hands attackers a pile of padlocks, not a pile of keys. A phished or guessed password, by contrast, works from anywhere until someone changes it. Second, a key is machine made and hundreds of characters long, far beyond anything a person would type or a guessing program can work through in practice. Third, keys make automation safe: a backup script or a deploy tool can log in on its own, with no password saved in a file for someone to find later.
GitHub shows the everyday version of that third point. With an SSH key added to your account, you connect and push code without supplying your username and a token at every visit, because the key does the proving quietly in the background.
Now the catch, and it matters. What is an SSH key worth to a thief? Everything, if it has no passphrase. A private key file with no passphrase protection works the moment someone copies it. The thief does not need your password, your laptop or your permission, just the file. Stolen key files are a real way attackers keep access to servers long after a breach.
The fix is built into the tools. When you create a key, you can set a passphrase, and OpenSSH then encrypts the private key file on disk with 128-bit AES. A copied file stays useless until the thief also learns the passphrase, which buys you time to remove the key from every server. Treat the passphrase as part of the key itself: a key without one is a house key left under the mat.
The key types, and which one to create
The algorithm is the recipe the pair was made with, and the current tools give you a short menu. The ssh-keygen manual lists the types it can create today: Ed25519, ECDSA, RSA, and hardware held variants marked with -sk. One old name is missing from that list, and its absence is the story, as the table shows.
| Key type | Size | Verdict |
|---|---|---|
| Ed25519 | Fixed size, short keys | The modern default. Create this one unless you have a specific reason not to. |
| ECDSA | 256, 384 or 521 bits | A solid alternative that some workplaces and older standards still prefer. |
| RSA | 3072 bits by default, 4096 for extra margin | The oldest type and still the most widely accepted. Use it when old software rejects Ed25519. |
| DSA | Retired | Gone. Current OpenSSH does not offer it at all, and no new key should use it. |
For most readers the choice takes ten seconds: Ed25519. It is fast, its keys are short, and there is no size setting to get wrong because the length is fixed. GitHub’s official guide starts with Ed25519 too, and keeps RSA at 4096 bits as the fallback for older systems. RSA still earns its place in one situation, talking to old servers and network gear that never learned the newer algorithms. Choose 3072 bits at least, since that is the size OpenSSH itself now creates by default. If your workplace wants the key to live on a physical device instead of a file, the -sk types keep the private half on a hardware security key that you plug in to approve each use.
How to create and use an SSH key
The whole setup takes a few minutes, and every tool you need already ships with Windows, macOS and Linux as part of OpenSSH. GitHub’s step by step guide to generating a key walks the same path, and it works for far more than GitHub.
Step 1: generate the pair. Open a terminal and run ssh-keygen with the Ed25519 type and your email as a label, as the diagram shows. The tool writes two files into the .ssh folder in your home directory: id_ed25519, the private key, and id_ed25519.pub, the public key.
Step 2: set a passphrase. The tool asks during creation. Pick one you can remember and type, because you will need it whenever the key is used, at least until the agent below takes over.
Step 3: install the public half. On a server you administer, the ssh-copy-id tool copies your public key into that account’s authorized_keys file in one step. On a service such as GitHub, you paste the public key into the SSH keys section of your account settings. In both cases only the .pub file ever leaves your machine.
Step 4: let ssh-agent carry it. The ssh-agent is a small helper that holds your decrypted keys in memory for the session. You type the passphrase once, add the key with ssh-add, and every later login in that session signs automatically. From then on, plain ssh to your server just works, with no prompt and no password.
One boundary is worth knowing. An SSH key protects the login itself: it proves who is connecting. It does not hide the fact that a connection exists or where it goes, which is why teams often reach the server through virtual private networks as well, so the login screen is not even visible from the open internet.
Habits that keep SSH keys safe
Four habits separate a safe key setup from a risky one. First, one key pair per device. Create a separate pair on your laptop, your desktop and any phone or tablet you connect from, and never copy a private key between machines. Second, rotate keys the way you would rotate a password: create a fresh pair, install the new public key, test the login, then delete the old line. Third, when a device is lost, sold or retired, remove its public key from authorized_keys on every server and from every service account. That one deleted line ends its access everywhere it was listed. Fourth, look at your authorized_keys files now and then. On servers you run, an unknown line there deserves the same attention as a hardware alert such as a platform event trap: it is a finding to investigate, not clutter to ignore.
Services help when you let them. GitHub’s SSH overview recommends reviewing your key list regularly and revoking any key that is invalid or compromised, and GitHub deletes keys that sit unused for a year as a safety precaution. None of this needs deep system knowledge or special software. The tools run on the same systems whose inner core we explain in our guide to what a kernel is, and the habits take minutes to build.
Conclusion
So, what is an SSH key? A pair of files that splits a login secret into a half you guard and a half you share. The private key stays home and signs, the public key sits on the server and checks, and no password or reusable secret ever crosses the network. Create an Ed25519 key, lock it with a passphrase, give every device its own pair, and remove keys the moment a device leaves your hands. Do those four things and the strongest login method in everyday computing stays exactly that.
Frequently asked questions
What is an SSH key in simple words?
An SSH key is a matched pair of files that proves who you are to a server. The private key stays on your computer and the public key sits on the server. At login your computer signs a challenge with the private key, the server checks the signature, and no password or secret crosses the network.
Are SSH keys safer than passwords?
Yes, in most setups. Nothing reusable crosses the network, the server stores no secret an attacker can steal and replay, and the key itself is far too long to guess. The one condition is that the private key file must stay protected, ideally with a passphrase, because an unprotected stolen copy works at once.
Which SSH key type should I create?
Create an Ed25519 key. It is the modern default in the OpenSSH tools and in GitHub’s guide, it has a fixed key size, and every current system accepts it. Use RSA at 3072 or 4096 bits only when old software cannot handle Ed25519.
Written by
Ahmad Jajja
Ahmad covers AI, chips and the companies behind them. He tests every claim in his stories against the source it came from.
Reviewed by
Danish Mustafa
Danish reviews laptops, phones and home tech over weeks of real use, and fact-checks the numbers in our AI coverage.