What Is an SSH Key?

Written by Danish Mustafa · Reviewed by Umar Abbas · July 11, 2026

An SSH key is a pair of long, random codes that lets you log in to a remote computer without typing a password. SSH stands for Secure Shell, which is a protocol, meaning an agreed set of rules, for connecting to another computer over a network in an encrypted way, so nobody listening in the middle can read what passes between you. Developers use SSH daily to reach servers, which are powerful computers that run websites and apps, and to push code to services such as GitHub, which is a platform where teams store and share code. Instead of proving who you are with a password you memorized, you prove it with a secret file that only your computer holds, and that change alone removes a whole family of password attacks.

Passwords fail in familiar ways. People reuse them across sites, choose short ones they can remember, and type them into fake login pages built by criminals. A stolen password from one breach can open many accounts, and a guessed password can open a server that was never meant to face the internet. A key pair avoids those traps because the secret is not a word you remember or type, it is a long random value stored in a file, and it never travels across the network during login. This guide explains the pair in plain language, shows how a login check works without sending the secret, walks through generating and installing a key safely, and covers what to do when a key leaks, so you can switch with confidence.

You do not need to be a systems expert to use keys well. If you can open a terminal, which is a text window where you type commands to the computer, and copy one line of text to a server, you can set up key login in a few minutes. The rest of this guide keeps the jargon beside a plain explanation every time it appears, so a beginner can follow the steps and an experienced reader can still use it as a checklist. For the official background, GitHub's guide to SSH authentication explains the same ideas from the side of the service you log in to, and the OpenSSH manual covers the tools themselves.

A Key Pair: One Secret, One Shareable Half

Every SSH key comes as a pair with two linked halves. The private key is the secret half. It stays on your own computer, ideally protected by a passphrase, which is a longer password that locks the key file itself, and you never send it to anyone, not even to the server you log in to. The public key is the shareable half. You can place it on every server you trust, paste it into your GitHub settings, and even print it on a slide, because on its own it cannot log anyone in. The two halves are linked by mathematics: anything locked with one half can only be unlocked with the other, and the server uses that link to test whether you hold the private half without ever asking you to show it.

A helpful analogy is a padlock and its key. Imagine you hand out open padlocks to every server you trust, and you keep the only key that opens them. A server that wants to check your identity locks a random challenge message with your padlock and sends it back to you. Only your key can open that locked message, so when you return the opened challenge, the server knows you hold the key, even though the key itself never left your computer. In real SSH, the math is more complex than a padlock, and it uses large numbers rather than metal shapes, but the trust idea is the same: the public half can lock and verify, while only the private half can unlock and prove. That split is why losing a public key costs nothing, while losing a private key costs everything.

Key pairs come in types, which are different mathematical methods for making the pair, and the type name tells you which method was used. Ed25519 is the modern default most guides recommend, because its keys are short, fast, and strong, and it works on current servers and services. RSA is an older method that still works everywhere, but its keys are much longer for the same strength, and very old RSA keys with short lengths should be replaced. ECDSA is another method that uses elliptic curve mathematics, which is a compact way of doing the same job, but it needs careful random number generation, so most beginners should simply choose Ed25519 and move on. The type matters far less than the habits around the key: protect the private half, share only the public half, and replace keys you no longer trust.

How An SSH Login Check Works

Walk through a login to see why the secret never travels. First, your computer connects to the server and the two sides agree on an encrypted channel, so everything after that point is scrambled to outsiders. Next, the server looks up the public keys stored for your account, usually in a file called authorized_keys, which is simply a list of public keys allowed to log in as that user. The server then sends your computer a challenge, which is a random piece of data locked in a way that only the matching private key can handle. Your computer uses the private key to answer the challenge, the server checks the answer against the public key, and if it matches, you are in, all without the private key ever crossing the network.

That design defeats two attacks that plague passwords. A fake server cannot steal your key by asking for it, because your computer never sends the key, it only answers a challenge tied to that specific connection. A listener on the network cannot replay an old login, because each challenge is fresh and random, so a recorded answer from yesterday will not match today's challenge. Phishing, which is a fake message that tricks you into typing a password into a false site, also loses its power here, because there is no password to type and no login page to fake. The remaining risks shift to the endpoints: someone who steals your laptop, or copies your private key file, can impersonate you, which is why device locks, passphrases, and quick revocation, which means removing a key from servers so it stops working, matter so much.

How To Generate And Install A Key

Generating a key takes one command on most computers. On macOS, Linux, and modern Windows, open a terminal and run ssh-keygen with the Ed25519 type and your email as a label, for example ssh-keygen -t ed25519 -C "[email protected]". The tool will ask where to save the key, and the default location, a hidden folder called .ssh in your home directory, is the right choice for most people. It will then ask for a passphrase. Choose a strong one you can remember, or store it in a password manager, because the passphrase is what protects the key if someone copies the file. The tool then creates two files: id_ed25519, which is your private key and must stay secret, and id_ed25519.pub, which is your public key and is safe to share.

Next, place the public key on each server or service you use. For a server, the ssh-copy-id command copies your public key to the server's authorized_keys file in one step, after which you can test the login and it should let you in without asking for the server password. For GitHub, copy the contents of the .pub file, never the private file, and paste it into the SSH keys section of your account settings, then test with the command GitHub documents. For other services, look for a setting named SSH keys or Deploy keys, which are keys that grant read only access for automated jobs. Once key login works, and only once it works, consider turning off password login on your own servers, because that closes the door that password guessing attacks knock on. Keep a backup of the private key in a safe place, such as an encrypted USB drive or a password manager that supports file storage, so losing a laptop does not lock you out of every server at once.

Test carefully before you close other doors. Open a second terminal window and log in with the key while your first session is still open, so a mistake cannot lock you out. Check that the server still accepts the key after a reboot, and confirm that automated jobs, such as code deployments, which are the steps that publish new code to a server, still run. If a job breaks, it probably uses its own key or its own account, and you should fix that job's key rather than reopening password login for everyone. Teams that manage many servers should give each person their own key, never share one private key among a team, because a shared key cannot be revoked for one person without breaking access for all the others. Our guide to how version control systems organize team code shows where SSH keys fit into daily development work.

Using Keys Safely Every Day

Daily safety comes down to three habits: lock the private key, limit where it lives, and use an agent wisely. Locking means a strong passphrase on every private key, plus a locked screen and full disk encryption, which is a setting that scrambles everything on the drive so a stolen laptop yields nothing readable, on the computer that holds the key. Limiting means keeping private keys only on devices you control, never on shared computers, never in cloud folders that sync to machines you do not own, and never inside code repositories, which are the folders where project code and history live. A private key committed to a repository by accident should be treated as leaked at once, even if the repository is private, because copies spread fast and access logs rarely tell the full story.

An SSH agent is a small helper program that holds your unlocked private key in memory for a session, so you type the passphrase once and then log in many times without retyping it. The agent never writes the key to disk while it runs, and it answers challenges on your behalf for each connection you approve. That convenience is worth it on your own machine, but it needs care on shared or remote machines: forwarding an agent to a server you do not fully trust can let that server use your key for other connections while you are logged in. A safer rule is to forward agents only to machines you administer, and to prefer a dedicated jump host, which is a single hardened server that acts as the only entry point to a private network, for reaching internal systems. For background on agent behavior, the OpenSSH manual documents the agent and its options in full.

Permissions are the quiet detail that trips up beginners. On Unix-like systems, your .ssh folder should be readable only by you, and the private key file should be readable only by you as well, because SSH will refuse to use a private key that other users can read, and that refusal is a safety feature, not a bug. If SSH complains about permissions, fix them with the chmod command to owner only access rather than copying the key somewhere looser. On Windows, the same idea applies through file ownership and access controls, and modern OpenSSH on Windows enforces similar checks. Treat any tutorial that tells you to make a private key world readable as a warning sign, and find a better tutorial instead, because that advice trades a small convenience now for a wide open door later.

A stolen key is often only useful after malware reaches the machine, so computer virus prevention belongs in the same routine as key care.

What To Do If A Private Key Leaks

Act as if a leaked private key is already in use, because you cannot prove it is not. First, remove the matching public key from every server and service where you placed it, starting with the most sensitive systems, so the leaked key stops working everywhere. Next, generate a fresh key pair, protect it with a new passphrase, and install the new public key in place of the old one. Then change any passwords or tokens that lived on the same device or in the same repository, because an attacker who copied one secret may have copied others. Finally, check server logs, which are records of who logged in and when, for logins from unfamiliar addresses or at odd hours, and tell your team or provider promptly so they can watch for further misuse.

Speed matters more than embarrassment here. Many leaks happen through ordinary mistakes, such as pasting the wrong file into a chat window, committing a key to a public repository, or leaving a laptop unlocked in a shared space, and teams that report fast contain the damage while teams that hide the leak give attackers days of quiet access. If the leak involved a work system, follow your incident process and preserve evidence, such as the repository history or the message where the key appeared, before you delete it, because investigators may need to know how far it spread. For personal projects, the same order applies at smaller scale: revoke, replace, rotate related secrets, and review logs, then write down what went wrong so the same mistake does not repeat. The same discipline applies to other secrets in development, as our guide on keeping confidential data out of development tools explains.

Keys In Teams And Automated Jobs

Teams scale key use with a few clear rules. Each person gets their own key pair, each server keeps a list of who may log in, and removing a person means removing their public key from that list, which is instant and does not disturb anyone else. Managers should review those lists when people change roles or leave, because a forgotten key is a forgotten door. For automated jobs, use a dedicated key pair that belongs to the job, not to a person, and give it the smallest access the job needs, such as read only access to one repository. That separation means a leaked job key affects one pipeline, which is an automated chain of build and deploy steps, rather than a person's whole access, and rotating it is a routine task rather than an emergency.

Certificates offer a more advanced option for larger teams, and they build on the same public key ideas as the certificate systems that secure websites, which our guide to how certificate trust chains secure the web explains in plain language. With SSH certificates, a central authority signs short lived certificates that grant access for hours or days, so teams stop managing long lists of public keys and instead trust the authority's signature. That setup takes more work to build, but it pays off when staff change often or when servers number in the hundreds. Smaller teams rarely need it, and a well kept authorized_keys list plus prompt revocation will serve them well for years. Choose the system that matches your size, and revisit the choice when growth makes the manual list painful.

Common Mistakes And How To Avoid Them

The most common mistake is sharing the wrong file. Private and public files sit side by side, their names differ by only four characters, and a tired copy paste can send the secret instead of the shareable half. Always check the file name before you paste: files ending in .pub are public, files without that ending are private, and a public key always starts with a label such as ssh-ed25519 followed by a long string. The second mistake is skipping the passphrase for convenience. A key without a passphrase works smoothly, but anyone who copies the file owns your access, while a passphrase buys you time to revoke the key before it can be used. The third mistake is keeping old keys forever. Review your keys once or twice a year, delete keys for devices you sold or services you stopped using, and generate fresh pairs when you switch computers, because a clean key list is easier to reason about in an emergency.

Another frequent mistake is treating keys as a replacement for all other security. Keys improve login security, but they do not patch software, back up data, or stop a malicious program already running on your computer. Keep updates automatic, keep backups tested, and keep server software current, so a strong login does not sit on top of a weak system. If you run servers for clients, document your key practices in plain language, including how keys are issued, how they are revoked, and who reviews access, because clients trust providers who can explain their controls without jargon. Our custom software development services follow that same habit of documented, least privilege access for every system we build and maintain.

Conclusion

An SSH key pair replaces a typed password with a secret that never crosses the network: the private key stays on your computer and answers challenges, while the public key sits on servers you trust and verifies those answers. Generate an Ed25519 pair, protect it with a strong passphrase, install only the public half, test before you disable password login, and use an agent carefully on machines you control. If a private key leaks, revoke it everywhere, replace it with a fresh pair, rotate related secrets, and check the logs without delay. Done that way, keys make daily logins both faster and far harder to steal than any password you could memorize.

Frequently Asked Questions

Relevant blogs

Back to all blog guides · Back to Cybersecurity and Networking guides · Explore Custom Software Development Services