SSH is how you reach nearly every Linux server, which makes it the front door attackers try first. A server exposed to the internet will see automated login attempts within a short time, which is normal background noise rather than a targeted attack. The goal of hardening is to make that noise harmless and to ensure that if someone does try seriously, the door is solid. This checklist walks through the changes that matter most, in a safe order.

Before You Change Anything

Changing SSH settings on a remote machine risks locking yourself out. Protect against that:

1. Keep your current session open throughout the process.
2. Make a copy of the existing configuration file before editing.
3. Test configuration syntax before reloading the service.
4. Open a second session to confirm you can still log in before closing the first.
5. Know your fallback, such as the provider’s web console, in case something goes wrong.

Settings and defaults vary between distributions and OpenSSH versions, so check the current manual page for your installed version.

Use Key-Based Authentication

Passwords can be guessed, reused and phished. Public key authentication ties login to a private key you hold, which is much harder to attack remotely. Generate a key pair on your own machine with a modern algorithm, protect the private key with a passphrase and install only the public key on the server. Confirm key login works before disabling password login.

Once keys work, turn off password authentication in the daemon configuration. This removes the entire class of password-guessing attacks. Keep in mind that every authorized key is a credential: remove keys when people leave, and avoid sharing one private key among several users.

Restrict Who Can Log In

• Disable direct root login. Have administrators log in with personal accounts and use sudo, so actions are attributable.
• Limit allowed users or groups with the daemon’s allow directives, so a newly created service account cannot log in over SSH by accident.
• Limit authentication attempts and idle sessions to reduce abuse and forgotten open sessions.
• Disable features you do not use, such as agent forwarding or X11 forwarding for servers where they have no purpose.

Treat agent forwarding with caution, since a compromised server can misuse a forwarded agent while your session is active. Jump hosts, using the client’s proxy options, are often a safer alternative.

Reduce Exposure

Hardening the daemon is only half the story. Reduce who can reach it:

• Use a firewall to restrict SSH to known addresses or to a VPN or bastion host where practical.
• If administrators connect from changing addresses, consider a VPN rather than leaving the port open to the world.
• Moving SSH to a non-standard port reduces log noise from automated scanning, but it is not a real security control. Treat it as cosmetic, not as protection.
• Consider tools that temporarily block addresses after repeated failures. They help with noise and brute-force attempts, though they should be one layer among several, and you must make sure they cannot lock out your own team.

Multi-factor authentication for SSH is available through various mechanisms, and is worth considering for high-value servers. Evaluate how it affects automation and emergency access before enforcing it.

The Checklist

Item	Goal	How to verify
Key-based login working	Strong authentication	Log in from a second session
Password login disabled	Stop password guessing	Attempt a password login and confirm refusal
Root login disabled	Attributable administration	Attempt root login and confirm refusal
Allowed users or groups set	Limit who can connect	Test with a non-listed account
Firewall limits access	Reduce exposure	Test from an unlisted network location
Idle and attempt limits set	Reduce abuse	Review the effective configuration
Unused features disabled	Smaller attack surface	Dump effective settings and review
Keys reviewed and pruned	No stale credentials	Compare authorized keys with current staff
Logs monitored	Detect unusual activity	Confirm alerts on unusual login patterns

A Hypothetical Example

Picture a small team whose server accepts password logins for several shared accounts, including root. Logs show thousands of failed attempts daily. They work through the checklist. They first create personal accounts and install each person’s public key, then test from a second terminal. They disable password and root login, add an allow list covering the administrators group, and restrict the firewall to their office and VPN addresses.

Afterward, the log noise nearly disappears, and a review of authorized keys reveals two belonging to people who left the team long ago. They remove them. The whole change takes an afternoon, and because they kept an open session and a backup of the configuration, nobody lost access at any point.

Verify and Maintain

After changes, review the effective configuration rather than just the file, since defaults and include files can override what you expect. Many versions of the daemon can print the active settings in test mode. Audit authorized keys periodically, rotate keys after staff changes and keep OpenSSH updated as part of your patch routine. Watch authentication logs for patterns such as logins at odd hours or from unfamiliar locations. If you manage many servers, configuration management ensures the same hardened settings apply everywhere and stay that way.

Security requirements and recommended algorithms evolve, and compliance obligations vary by jurisdiction and industry, so consult current vendor guidance and qualified professionals when your environment is regulated.

Frequently Asked Questions

Is changing the SSH port worth it? It reduces log clutter from scanners but does not stop a determined attacker. Do it only in addition to real controls such as keys and firewalling.

Are passphrases on keys necessary? They are strongly recommended, since they protect the key if your device is lost or copied. Use an agent to avoid retyping them constantly.

What if I lock myself out? Use your provider’s console or rescue mode to restore the previous configuration. This is why you keep a backup copy and a second session during changes.

Should service accounts and automation use SSH keys too? Yes, ideally dedicated keys with limited permissions, restricted commands where possible, and a clear owner so they can be rotated.

Do I still need a firewall if SSH is hardened? Yes. Layered defense means a flaw in one control does not expose everything, and limiting reachability reduces your risk from future vulnerabilities.

Next Step

Review your SSH daemon’s effective configuration today and compare it with the checklist. Fix one item at a time, testing from a second session after each, starting with disabling password login once key access is confirmed.