Linux Server Security Setup & SSH Hardening

The Problem

SSH left on default settings is one of the most scanned, most attacked services on the internet — password auth, root login and the default port are an open invitation for brute-force attempts.

About this problem

SSH on its default port with password authentication enabled is one of the most consistently attacked services on the internet — not targeted attacks, just constant automated scanning trying common usernames and passwords against every public IP. Root login being enabled makes a successful guess far more damaging than it needs to be.

This usually comes up as a hardening pass on a server that's been running for a while on defaults, or after noticing a flood of failed login attempts in the auth log.

What's Included

• Switching to key-based SSH authentication and disabling password login
• Disabling root login over SSH
• Changing the SSH port and configuring Fail2Ban
• General firewall review and tightening

What's NOT Included

• Recovering access if you lose your SSH key afterwards (back up your key!)
• Full compliance-grade security auditing
• Fixing an already-compromised server (see incident response)

How It Works

1. Review current SSH configuration (port, root login, password auth) and existing auth log activity.
2. Set up and confirm SSH key-based authentication works before disabling anything.
3. Disable root login over SSH and password authentication once key access is confirmed.
4. Change the SSH port and configure Fail2Ban for the new port.
5. Review broader firewall rules to confirm only intended services remain exposed.

In practice: you buy the service, send over whatever access or details the job needs, I investigate and do the work, and you confirm it's resolved before we call it done.

Frequently Asked Questions

Does changing the SSH port actually improve security?

It significantly reduces automated scanning noise (most bots only check the default port), though it's a layer alongside key-based auth and Fail2Ban, not a replacement for them.

Is it safe to disable root SSH login?

Yes, and it's standard practice — you still have full root access via sudo from a regular user account, just not directly over SSH as root.

How do I know if my server is being attacked via SSH?

The auth log (/var/log/auth.log on Debian/Ubuntu) shows failed login attempts — a constant stream of these from varying IPs is normal background noise on any public server without hardening.

What's the risk of SSH password authentication?

Passwords can be brute-forced given enough attempts, while a properly generated SSH key effectively can't be — disabling password auth removes that attack vector entirely.

Can I still use SSH keys if I change the default port?

Yes, completely independent settings — key-based authentication works the same regardless of which port SSH listens on.

Should every server have Fail2Ban installed?

It's a sensible baseline for any internet-facing server, catching and blocking brute-force attempts automatically rather than relying on firewall rules alone.