The Fortress Gate: SSH Hardening
·TechSoftware Development

The Fortress Gate: SSH Hardening

Lock down your primary entry point. Master advanced SSH security configurations. Learn to disable password authentication, implement 2FA, change default ports, and use 'Match' blocks for per-user security policies. Understand the logic of sshd_config.

SSH Hardening: Locking the Perimeter

The Secure Shell (SSH) is the most powerful tool in your arsenal, but it is also the primary target for every hacker on the planet. If an attacker gains SSH access to your server, the game is over.

A "Standard" SSH installation is secure-ish, but a "Master" installation is a fortress. In this lesson, we will move beyond simple connections and learn to harden the sshd_config to professional standards.


2. The Three Commandments of SSH Security

I. No Passwords Allowed

Passwords can be guessed, phished, or brute-forced. SSH Keys (public/private pairs) are effectively impossible to crack.

# In /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes

II. No Root Login

If someone is trying to break in, they are usually trying to break in as root. Force everyone to log in as a normal user first and then use sudo.

PermitRootLogin no

III. Change the Default Port

Most automated bots only scan Port 22. Changing your port to something like 2222 or 49152 won't stop a dedicated hacker, but it will eliminate 99% of the manual log noise.

Port 2222

3. Advanced Matching: The 'Match' Block

What if you want to allow passwords for users on your local office network, but force the same users to use Keys when they are at home? You use Match Blocks.

# Default: No passwords
PasswordAuthentication no

# Exception: If coming from the office IP 1.2.3.4, allow passwords
Match Address 1.2.3.4
    PasswordAuthentication yes

4. Multi-Factor Authentication (MFA)

You can add an extra layer of security using Google Authenticator or a hardware key (YubiKey). Even if a hacker steals your SSH Key, they still can't get in without the code from your phone.

  1. Install libpam-google-authenticator.
  2. Run google-authenticator as your user.
  3. Update SSH to require both:
AuthenticationMethods publickey,keyboard-interactive

5. Practical: The "Connection Banner"

Professional servers often display a legal warning when someone connects. This helps in a court of law if you ever have to prosecute an intruder.

# Edit /etc/issue.net
"THIS SYSTEM IS FOR AUTHORIZED USERS ONLY. ALL ACTIVITY IS LOGGED."

# Enable in sshd_config
Banner /etc/issue.net

6. Example: An SSH Security Auditor (Python)

How do you know if your team accidentally turned password auth back on? Here is a Python script that audits the sshd_config file for "Bad" settings.

import os

def audit_sshd_config(config_path="/etc/ssh/sshd_config"):
    """
    Looks for dangerous settings in the SSH configuration.
    """
    dangerous_settings = {
        "PermitRootLogin": "yes",
        "PasswordAuthentication": "yes",
        "PermitEmptyPasswords": "yes",
    }
    
    warnings = 0
    print(f"--- SSH Security Audit: {config_path} ---")
    
    if not os.path.exists(config_path):
        print("Config file not found.")
        return

    with open(config_path, "r") as f:
        content = f.read()
        
    for key, bad_val in dangerous_settings.items():
        # Look for the key and value (ignoring comments)
        if f"{key} {bad_val}" in content and not f"# {key}" in content:
            print(f"[!!!] DANGER: {key} is set to {bad_val}!")
            warnings += 1
            
    if warnings == 0:
        print("[OK] No high-risk settings detected.")

if __name__ == "__main__":
    audit_sshd_config()

7. Professional Tip: Use 'AllowUsers'

Instead of worrying about every user on the system, specifically list the only people allowed to log in via SSH. If a user isn't on this list, they can't even get to the password prompt.

AllowUsers sudeep admin_maria dev_team

8. Summary

SSH hardening is your first line of defense.

  • Key-only authentication is the single best security move you can make.
  • Root login should always be disabled.
  • Match blocks allow for flexible, context-aware security.
  • 2FA provides peace of mind for high-value targets.
  • Banner and Port changes reduce noise and add legal weight.

In the next lesson, we will look at the second pillar of security: The sudo Logic—Mastering /etc/sudoers.

Quiz Questions

  1. Why is PermitRootLogin no considered a mandatory security step?
  2. What happens if you lose your SSH private key when PasswordAuthentication is set to no?
  3. How does a "Match" block differ from a standard configuration line in sshd_config?

Continue to Lesson 2: The sudo Logic—Mastering /etc/sudoers and visudo.

Subscribe to our newsletter

Get the latest posts delivered right to your inbox.

Subscribe on LinkedIn