Todos os artigos

ssh

SSH keys vs passwords on a VPS: log in the right way

A plain-English guide to why SSH keys are safer than passwords, what can go wrong, and how to keep server access understandable over time.

  • ssh
  • security
  • login
An SSH key connects securely to a VPS while password login is shown as a weaker, dotted path.

You just want to log in without turning your server into an easy target or locking yourself out by accident.

Short version: use SSH keys for normal server login, not passwords. An SSH key is a matched pair: a private key stays on your computer, and a public key sits on the server, so the server can recognize you without you typing a reusable secret across the internet.

What are SSH keys?

SSH, short for Secure Shell, is the usual way to get a private command-line doorway into your server. Think of it like a locked side door for maintenance.

A password is like a shared phrase. If someone learns it, they can try the same phrase from anywhere.

An SSH key is more like a lock and a unique physical key. The public key on the server is the lock. The private key on your laptop is the only thing that fits it. You do not send the private key to the server when you log in; your computer proves it has the key without handing it over.

That difference matters. A stolen password can be used immediately. A public key copied from the server is not enough to log in.

Why are SSH keys safer than passwords?

Passwords are easy to attack because computers can guess them quickly. Bots scan the internet all day looking for servers that accept SSH password login. They try common usernames, leaked passwords, and simple patterns.

SSH keys are much harder to guess. A good key is too large for practical guessing, so attackers usually move on to easier doors.

Keys also make good habits easier. You can give each person or device its own key. If an old laptop is lost, you remove that one public key from the server instead of changing a shared password that everyone knows.

For a safer baseline, SSH keys work best alongside other basics: a firewall that only opens what you need, regular updates, and backups you can actually restore. If you are still shaping the first layer of defense, start with your firewall too: /blog/set-up-a-firewall-on-your-server.

Which login method should you use?

For a server you care about, SSH keys should be the default. Password login is useful during first setup or as a temporary recovery path, but leaving it open forever is like keeping a spare house key under the mat.

Login methodBest forMain riskPractical advice
Password loginTemporary setup, emergency fallbackBots can guess or reuse stolen passwordsAvoid using it as your normal login method
SSH key loginDaily server accessLosing the private key or setting it up wrongUse it as the normal way in, and keep a recovery plan

The usual safe pattern is simple: set up SSH key login, test it in a second terminal window, then reduce or disable password login once you know the key works. Do not close your only working session until you have confirmed the new one works.

If multiple people need access, avoid sharing one password or one private key. Give each person their own key. That way access is a list you can read later, not a mystery drawer full of old copies.

What can go wrong when you set up SSH keys?

The most common failure is the scary but fixable error string: Permission denied (publickey). It usually means the server did not accept the key your computer offered.

Sometimes the wrong public key was added to the server. Sometimes your SSH client is using a different private key than you expected. Sometimes the key is correct, but it belongs to a different user account on the server.

Another common problem is permissions. In plain English, the server may refuse to trust a key file if the related folders are too open. SSH is picky on purpose: if everyone can edit the key list, the lock is not really a lock.

You can also lock yourself out by turning off password login before testing key login. That is the server version of closing the front door, then realizing your keys are still on the kitchen table.

And remember: SSH keys do not fix every access problem. If a firewall blocks the SSH port, if the server is down, or if the network path is broken, a perfect key still cannot get in. When login fails and you are not sure why, logs are often the next clue: /blog/how-to-read-server-logs-when-something-breaks.

FAQ

Can I use both SSH keys and passwords? Yes, but keys should be your normal login method. Password login is best kept temporary or tightly limited.

Should I add a passphrase to my private key? Yes, if you can. A passphrase protects the private key if your computer is lost or copied.

Can I use the same SSH key on many servers? You can, but separate keys are cleaner. If one key needs to be retired, you know exactly what it affected.

**What does Permission denied (publickey) mean?** It means the server only accepted key-based login, but none of the keys offered by your computer matched what the server trusts.

The shortcut

Server Manager helps you avoid the messy parts that usually make SSH access confusing: password login left open longer than intended, keys attached to the wrong user, and access rules that nobody understands three months later.

The real benefit is not skipping security. It is keeping the setup readable. You can see who should have access, avoid one person’s old laptop becoming a silent risk, and keep server entry from turning into a pile of half-remembered manual changes.

That also helps when something breaks. Instead of guessing whether the problem is a wrong key, an expired habit, or a blocked doorway, the access story stays clear enough to reason about.

Good SSH access should feel boring: the right people get in, attackers have less to try, and future-you can still understand how the door is locked.