All posts

ssh

SSH Keys on a VPS: A Safer Way to Log In Than Passwords

SSH key login replaces easy-to-guess server passwords with a paired lock-and-key system that is safer and easier to live with once you understand it.

  • ssh
  • security
  • login
A private SSH key sends a green arrow to a locked VPS server while a password pill is crossed out.

You want to log in to your server without leaving the front door protected by a password that bots can guess all day.

That is the basic problem SSH keys solve. They make server login feel less like typing a shared secret into a keypad, and more like using a physical key that only exists on your own computer.

Why password login is the weak front door

SSH means Secure Shell. It is the usual way to open a private command-line session on your server from your laptop.

When SSH accepts passwords, anyone on the internet can try to log in. They do not need to know you. They do not need to visit your website. They can simply knock on the SSH door and try common usernames and passwords over and over.

Most of those attempts are automated. Picture a stranger walking down a street, trying every front door handle. Now picture a robot doing it thousands of times per hour, across thousands of addresses.

A strong password helps. A firewall helps too, and it is worth understanding the basics in how to set up a firewall on your server. But password login still leaves you with a secret that can be guessed, reused, leaked, copied, or typed into the wrong place.

SSH keys change the shape of the risk.

What an SSH key actually is

An SSH key comes as a pair.

One part is public. You can put it on the server. It is like a lock you are happy to install on a door.

The other part is private. You keep it on your own computer. It is like the only key that fits that lock.

The public part cannot be used to recreate the private part. That is the important bit. If someone sees the public key, they still cannot log in as you. The server can use it to check whether your private key matches, without your private key ever being sent across the internet.

This is different from a password. With a password, the thing you type is the thing that proves who you are. If it leaks, it can be replayed. With an SSH key, your computer proves it has the private key, but does not hand the private key over.

Many people also protect the private key with a passphrase. That means if someone steals your laptop file, they still need another secret before they can use it. Think of it as putting your house key inside a small safe.

What changes when you set up SSH key login

Setting up SSH key login usually means three things happen.

First, you create a key pair on your own computer. Your private key stays there. Your public key is the part meant to be shared.

Second, the public key is added to the right user account on the server. From then on, the server knows: “If someone can prove they hold the matching private key, let them in as this user.”

Third, once you have tested that key login works, password login can be turned off. This is the part that removes a large class of attacks. Bots can keep guessing passwords, but the door no longer accepts passwords as proof.

The order matters. Do not remove password access before confirming your key works in a new login session. Otherwise, you can lock yourself out of your own server, which is the server equivalent of closing the door and realizing the key is still on the kitchen table.

If you are still at the “what should I do first?” stage, our guide to beginner first steps on a new server gives the wider context around login, updates, domains, and basic safety.

The mistakes that make keys feel scary

SSH keys are safer than passwords, but they are not magic. Most trouble comes from losing track of which key belongs where.

You might create a key on an old laptop, add it to the server, then replace the laptop six months later. If that was your only working key and password login is disabled, you have a recovery problem.

You might copy a private key into a chat message, a shared folder, or a project repository by mistake. That turns a private key into a not-so-private key. Public keys are fine to share. Private keys are not.

You might also give every project and every person the same access. That is convenient at first, but messy later. When someone leaves, or when a laptop is lost, you want to remove one key without wondering what else depends on it.

This is why server security is not only about being strict. It is about staying organized. Backups matter for the same reason: the day something goes wrong is not the day you want to discover what you forgot to document. If you have not already, read how to back up your server and restore it.

The shortcut

Server Manager helps by keeping access understandable instead of turning it into a pile of half-remembered terminal changes.

The outcome is simple: you are less likely to leave password login open because you were afraid of breaking access, less likely to forget which key belongs to which person or machine, and less likely to lose the thread months later when you need to change something.

The real benefit is not that SSH keys become clever. It is that the setup stays legible. You can see what exists, understand why it exists, and avoid the common failure modes: a locked-out server, an old laptop still trusted, or a private key treated like a normal file.

The win: a quieter login door

SSH keys give your server a calmer front door.

Instead of asking the whole internet to guess the right password, your server asks for proof that only your own machine should be able to provide. Once password login is off and your keys are kept tidy, random guessing becomes far less useful.

You still need care. Keep your private key private. Protect it with a passphrase. Keep a recovery path. Remove keys you no longer use.

But the main win is clear: you can log in without leaving password guessing as the easiest attack to try.