How to harden SSH on your server

SSH is the front door to your server, and right now every bot on the internet knows where to knock.

Short version: to harden SSH, use SSH keys instead of passwords, stop direct root login, limit who can connect, protect port 22 with a firewall, and keep a second way back in while you test. The goal is not to make login complicated; it is to make guessing, brute-forcing, and accidental exposure much harder.

Why does SSH need hardening?

SSH, short for Secure Shell, is the normal way to remotely control a server. If your website is the shop window, SSH is the staff entrance around the back.

The problem is that attackers do not need to know you personally. Automated bots scan the internet for servers with SSH open, usually on port 22, then try common usernames and passwords over and over. You may see this in logs as repeated failed attempts for names like root, admin, ubuntu, or test.

OpenSSH, the most common SSH server software, is solid. The weak spot is usually the setup around it: password login left on, root login allowed, old keys nobody remembers, or a firewall that leaves too much exposed.

Hardening SSH means reducing the number of easy guesses. Think of it like replacing a cheap front-door lock, removing the spare key under the mat, and adding a porch light. You are not building a bunker. You are removing the obvious openings.

What should you change first?

Start with the changes that reduce risk without making the server mysterious.

The biggest improvement is moving from password login to SSH key login. A password is something a bot can guess. An SSH key is more like a long, unique physical key that lives on your computer. The server only lets you in if your private key matches the public key it already trusts.

You should also stop direct root login. The root user is the all-powerful account on a Linux server. If attackers can try logging in as root, they already know the username and only need to guess the lock. A safer pattern is to log in as a normal user, then use admin rights only when needed.

Here is the plain-English priority list:

If you are still setting up the basics, it helps to pair SSH hardening with a firewall. The ideas connect closely: SSH controls who can enter, while the firewall controls which doors exist at all. We explain that layer in plain terms in how to set up a firewall on your server.

Is it safe to disable password login and root login?

Yes, but only after you prove your safer path works.

This is the part where people lock themselves out. They turn off passwords, close the terminal, and only then discover their SSH key was saved on another laptop. Hardening SSH should feel like changing a lock while the door is still open, not slamming it shut and hoping you have the right key.

Before disabling password login, open a second SSH session and test key-based login there. Keep your current session alive. If the new session works, you have evidence that the server recognizes your key.

Before disabling root, make sure your normal user can perform admin tasks. The common pattern is a regular user with sudo, which means “run this specific action with administrator rights.” That way, day-to-day login is less dangerous, but you can still manage the server when needed.

Also think about where your private key lives. If it is only on one laptop and that laptop dies, your server may be fine but unreachable. Keep recovery in mind. A backup plan is part of security, not a separate chore. For the bigger picture, see how to back up your server — and actually be able to restore it.

Should you change the SSH port or use fail2ban?

Changing the SSH port can reduce noise, but it is not real protection by itself.

Port 22 is the default SSH port, so bots check it constantly. Moving SSH to another port is like moving your staff entrance from the front alley to the side street. Fewer people rattle the handle, but anyone who finds the door still needs to face the lock.

That means changing the port can be useful for cleaner logs, but it should not replace keys, disabled password login, and a firewall.

fail2ban is more practical. It watches login attempts and temporarily blocks addresses that fail too often. Think of it as a bouncer who notices someone trying the wrong key twenty times. It will not fix weak access rules, but it can slow down noisy brute-force attempts.

The safest mindset is layered:

• SSH keys so passwords cannot be guessed.
• No direct root login so attackers cannot target the master account.
• Firewall rules so only intended access is exposed.
• Rate limiting or fail2ban so repeated failures get pushed away.
• Clear notes so you remember what you changed.

That last point matters more than beginners expect. A hardened setup that nobody understands becomes fragile later, especially when you rotate keys, replace a laptop, or bring another person into the project.

FAQ

What is the most important SSH hardening step? Use SSH keys and disable password login once key login is confirmed. That removes the easiest brute-force target.

**Should I disable root SSH login?** Yes, in most cases. Log in as a normal user and use admin rights only when needed.

Is changing port 22 enough? No. It reduces random noise, but it does not replace strong authentication or a firewall.

Can I lock myself out while hardening SSH? Yes. Keep an existing session open, test a second login, and make sure you have a recovery path before turning off password access.

The shortcut

Server Manager helps by keeping the shape of your server understandable as it changes. The useful outcome is not “more settings”; it is knowing which access path exists, which doors are meant to be open, and what changed later when something stops working.

That matters for the exact failure modes SSH hardening can create: password login disabled before keys are tested, direct root access removed without a working admin user, firewall rules that block your own access, or a setup that makes sense today but becomes unreadable six months from now.

The real benefit is that your server stays legible. You can harden access without turning the machine into a black box you are afraid to touch.

What does hardened SSH feel like when it is done?

A hardened SSH setup is boring in the best way.

You can still get in when you need to. Bots can still knock, but password guessing no longer helps them. The root account is not sitting at the entrance. The firewall is not leaving extra doors open. And when you come back later, the setup still makes sense.

That is the win: fewer obvious risks, less log noise, and a server you can manage without wondering whether the next security change will lock you out.