What an SSH Key Is and When You Actually Need One
Short answer
An SSH key is a pair of files: a private key that stays on your computer and a public key you give to a server. The server challenges you, your computer proves it holds the private half, and no password is sent. You need one for a web host, a remote server, or GitHub — not for anything an ordinary computer does day to day.
On this page
Most people meet SSH keys because something demanded one. A web host’s documentation, a GitHub push that refused a password, a developer telling you to “send your public key”. The term sounds like it belongs to system administration, and the explanation usually assumes you already know.
The underlying idea is simple, and the honest answer for a lot of readers is that you do not need one and are reading this because a service mentioned it.
What it is
An SSH key is not a single thing. It is two files generated together.
- The private key. Stays on your computer, never leaves it, never gets sent anywhere. This file is your identity.
- The public key. A short text string you can hand out freely. You paste it into a server, a hosting panel, or GitHub.
They are mathematically linked. The private key can produce signatures the public key can verify, but the public key cannot produce them and cannot be reversed into the private one.
Signing in works like this: the server sends a random challenge, your computer signs it with the private key, and the server checks that signature against the public key it already holds. Nothing secret crosses the network.
That is the whole advantage, and it is a real one:
- Nothing to intercept, because no secret is transmitted.
- Nothing to leak, because the server only stores public keys.
- Nothing to guess, because the key is far too long to brute-force.
- Nothing to phish, because there is no password for you to type into the wrong place.
It is the same mechanism as passkeys, which arrived twenty-odd years later for websites. Passkeys hide the key handling behind your fingerprint, whereas SSH leaves the files visible, which is why it feels harder.
When you need one
| Situation | Need a key? |
|---|---|
| Pushing code to GitHub or GitLab | Yes, or a token |
| Connecting to a VPS or cloud server | Yes, usually mandatory now |
| SSH or SFTP into a web host | Often, sometimes optional |
| A Raspberry Pi or home server | Recommended |
| A NAS with remote access enabled | Recommended |
| Normal computer use, email, browsing | No |
| Logging into websites | No |
The bottom two rows cover most people. SSH is for connecting to a machine’s command line over a network, and if you are not doing that, there is nothing here for you.
The situation where a non-developer genuinely runs into this is self-hosting something small — a Pi running a media server, a NAS exposed for remote access, or a cheap VPS running a hobby site. In all three, opening SSH to the internet with password authentication means automated scanners will find it within hours and begin guessing. Key-only authentication ends that category of attack outright, because there is nothing to guess.
Making one
The tooling is built into Windows 10 and 11, macOS and Linux. Open Terminal, or PowerShell on Windows.
ssh-keygen -t ed25519 -C "laptop-2026"Three prompts follow:
Where to save it. Press Enter to accept the default, which puts the pair in
.ssh inside your home folder. Only change this if you are managing several
keys and know why.
A passphrase. Set one. It encrypts the private key file, so a copied file is not immediately usable by whoever copied it. Your operating system’s keychain will remember it, so you type it rarely.
Confirm it. Lose this passphrase and the key is unusable; generate a new pair rather than hunting for a recovery route, because there is not one.
You now have two files. id_ed25519 is private and never leaves the machine.
id_ed25519.pub is public and is what you paste into services.
The ed25519 type is the current default recommendation, being shorter than
older RSA keys and strong. Use RSA with at least 4096 bits only if a service
explicitly requires it.
Giving the public key to a service
Open the .pub file in any text editor and copy the whole single line, starting
with ssh-ed25519 and ending with the comment you set.
- GitHub or GitLab: Settings → SSH and GPG keys → New SSH key.
- A hosting control panel: usually under SSH Access or Security.
- A server you control: append the line to
~/.ssh/authorized_keyson that server, usingssh-copy-id user@hostif available, which does it correctly.
Do not paste the private key. It is the file without .pub, it begins with
-----BEGIN OPENSSH PRIVATE KEY-----, and anyone who has it can sign in as you
anywhere that key is registered. If you ever send it by mistake, generate a new
pair and remove the old public key from every service.
The things that go wrong
“Permission denied (publickey).” The server does not have your public key,
or has a different one. Check you pasted the .pub file, the whole line, with
no line breaks introduced by the editor.
Wrong file permissions. SSH refuses to use a private key that other users on
the machine can read. On macOS and Linux, chmod 600 on the private key and
chmod 700 on the .ssh folder. Windows rarely hits this.
The passphrase prompt on every connection. Add the key to your agent:
ssh-add ~/.ssh/id_ed25519 on macOS and Linux, or start the OpenSSH
Authentication Agent service on Windows.
A new laptop. Generate a fresh key on it and add that public key to your services. Copying private keys between machines is possible and is worse practice, because it removes your ability to revoke one machine’s access independently.
The honest limitation
An SSH key is only as protected as the computer holding it. Malware with access to your files can take the private key, and if it is unprotected by a passphrase that key works immediately. A passphrase and a running SSH agent narrow the window considerably but do not close it.
There is also no central revocation. A key remains valid on every server it was
added to until someone removes it from each one, and keys from old laptops
accumulate in authorized_keys files for years. If you run a server, reading
that file once a year is five minutes well spent — it is the SSH equivalent of
checking which devices are signed into your account.
Realistic expectations
Generating a key and adding it to GitHub takes about five minutes, and after that you stop thinking about it entirely. For a server you expose to the internet, switching to key-only authentication is the single highest-value change available, and it removes password guessing as a threat completely.
If none of those apply to you, the useful conclusion is that you do not need an SSH key. The equivalent protection for ordinary accounts is a strong unique password with a second factor on top, which achieves the same goal with none of the file handling.