SSH Hardening on Linux: Keys, Configuration, and Brute-Force Resistance

1. Introduction

SSH hardening on Linux comes down to a few high-impact controls: use key-based authentication, disable direct root login and password logins once keys work, limit who may connect with AllowUsers or AllowGroups, turn off forwarding you do not need, and monitor authentication logs. This guide shows how to audit the current state, apply a hardened configuration safely, and detect abuse.

SSH is the administrative front door to a huge number of Linux servers. It provides encrypted remote access, file transfer, tunneling, and automation, which makes it both indispensable and highly attractive to attackers. Strong SSH security depends on configuration, key management, authentication policy, and monitoring together. This article focuses on defensive administration, auditing, and authorized lab work. The objective is to understand the control, identify misconfiguration before it becomes an incident, and build a repeatable hardening process that can be applied across real Linux environments.

2. How It Works

The OpenSSH server reads sshd_config and optional drop-in files, then negotiates cryptographic algorithms and authentication methods with clients. Administrators can control who may log in, whether passwords are accepted, whether root may authenticate directly, and whether forwarding or tunneling features are available. Linux security is layered, so this control should be considered together with identity, filesystem permissions, service configuration, kernel policy, network segmentation, and centralized monitoring. A single command rarely tells the whole story; the effective security posture comes from how these layers interact.

3. The Security Problem

Risk increases when password authentication is exposed to the internet, root login is enabled, old accounts retain authorized_keys entries, private keys are poorly protected, or broad AllowUsers/AllowGroups controls are absent. Agent forwarding and unnecessary TCP forwarding can also extend trust in ways that are difficult to see. These weaknesses are often created gradually by troubleshooting, legacy migrations, vendor installation scripts, or temporary exceptions that later become permanent. A good security review therefore looks not only for obviously dangerous settings, but also for configuration that no longer has a clear owner or business justification.

4. How Attackers Abuse It

Attackers commonly try stolen credentials, reused passwords, exposed private keys, or brute-force attempts. After a foothold, they inspect SSH keys and configuration because one trusted key can open multiple hosts. Persistence may also involve adding a key to authorized_keys. In an authorized assessment, the goal is to demonstrate exposure safely and report the exact condition that creates the risk. In production incident response, avoid making destructive changes before collecting enough context to understand whether the issue is a simple misconfiguration, active abuse, or a persistence mechanism.

5. How to Detect / Enumerate & Audit It

Check the Effective sshd Configuration

sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers|allowgroups|maxauthtries'

What it does: Show effective SSH server settings.

What to look for: Root login, password auth, and weak access controls.

Defensive use: Review the configuration after includes and defaults are resolved.

Find SSH Directives and Drop-in Overrides

grep -R --line-number -E 'PermitRootLogin|PasswordAuthentication|AllowUsers|AllowGroups|AllowTcpForwarding' /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null

What it does: Locate relevant configuration directives.

What to look for: Conflicting drop-ins and permissive overrides.

Defensive use: Make configuration review easier.

Inventory authorized_keys Files

find /home /root -name authorized_keys -type f -ls 2>/dev/null

What it does: Find SSH authorized key files.

What to look for: Unexpected accounts or stale keys.

Defensive use: Audit key-based access.

Review SSH Authentication Logs

journalctl -u ssh --since '24 hours ago' 2>/dev/null || journalctl -u sshd --since '24 hours ago'

What it does: Review recent SSH service logs.

What to look for: Repeated failures, unusual source IPs, and new successful logins.

Defensive use: Support brute-force and incident investigation.

A useful operational habit is to save the output of these checks in a baseline for each server role. A database server, bastion host, developer workstation, and container node will not look identical, so comparison should be against a known-good peer or documented configuration rather than against a generic assumption.

6. How to Audit the Environment

• Disable or strongly restrict direct root SSH access.
• Prefer keys or centrally managed authentication over exposed passwords.
• Inventory authorized keys and remove stale access.
• Restrict SSH to administrative networks or VPNs when possible.
• Review forwarding features and disable those not required.
• Document every exception with an owner, reason, and review date.
• Re-check the control after upgrades because packages and deployment automation can silently change defaults.

7. SSH Hardening Steps

• Set PermitRootLogin to no or an appropriately restricted mode.
• Disable PasswordAuthentication when operationally feasible and key management is mature.
• Use AllowUsers or AllowGroups for administrative scope.
• Protect private keys with strict permissions and passphrases where appropriate.
• Apply rate limiting or a security control such as fail2ban only as an additional layer, not as a replacement for strong authentication.
• Apply changes through configuration management when possible so the desired state is reproducible.
• Test hardening first on a staging host or a disposable snapshot and verify that critical services still function.

Example: A Hardened sshd_config Drop-in

On distributions whose main sshd_config includes /etc/ssh/sshd_config.d/*.conf (current Debian, Ubuntu and Fedora releases do), put your settings in a drop-in file. For most directives sshd uses the first value it reads, so a drop-in included near the top of the main file takes precedence. Always confirm the final result with sshd -T.

# /etc/ssh/sshd_config.d/10-hardening.conf
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey
MaxAuthTries 3
LoginGraceTime 30
AllowGroups ssh-users
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

Apply it in this order so you do not lock yourself out:

# 1. On your workstation: create a key and copy it to the server
ssh-keygen -t ed25519 -a 100
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@server

# 2. On the server: create the group used by AllowGroups and add your admin user
sudo groupadd ssh-users
sudo usermod -aG ssh-users admin

# 3. Validate the syntax, then reload
#    (the service is "ssh" on Debian/Ubuntu and "sshd" on RHEL/Fedora)
sudo sshd -t && sudo systemctl reload ssh

Keep your current session open and test a new login from a second terminal before you log out. If the new login fails, revert the change from the session you still have. If you need MFA for SSH, it is configured through PAM; see our PAM security guide.

8. Detection & Monitoring

• Alert on successful root logins, authentication from new countries or networks, and high failure rates.
• Track modifications to sshd configuration and authorized_keys, for example with auditd watch rules.
• Correlate SSH login events with sudo activity and new persistence artifacts.
• Keep time synchronization reliable so host events can be correlated with firewall, identity, EDR, and SIEM data.
• Send high-value security logs off-host (see journald and rsyslog forwarding) because a fully compromised root account can often alter local evidence.

9. MITRE ATT&CK Mapping

MITRE ATT&CK is most useful here as a common language for detection engineering and incident reporting. The mapping does not mean every misconfiguration is an active attack; it shows which attacker behaviors may become easier when the control is weak.

10. Practical Lab

In an isolated Linux lab or disposable VM:

1. Harden a test SSH server in a VM.
2. Compare sshd -T before and after changing root/password settings.
3. Add and remove a test authorized key.
4. Generate failed and successful logins from another lab host.
5. Review the resulting journal events.
6. Capture screenshots or command output before and after the change so you can prove what the control actually changed.
7. Revert the VM or remove the test configuration when finished.

11. Key Takeaways

• SSH Hardening on Linux should be treated as part of a layered security model, not as an isolated setting.
• Inventory the current state first, because unknown configuration is difficult to secure.
• Prefer least privilege, explicit ownership, and documented exceptions.
• Monitor changes to the control itself; attackers often try to weaken defenses after gaining access.
• Test fixes in a lab and verify the effective runtime state, not only the configuration file.

Continue Learning: Linux Security

This guide is part of our Linux Security series. These guides pair well with SSH hardening:

• Linux file permissions: chmod, chown and umask
• Sudo security on Linux
• SUID and SGID binaries
• PAM security, password policy and MFA
• Linux logging with journald and rsyslog
• auditd rules for security monitoring
• Linux firewalls with nftables
• Linux kernel hardening with sysctl
• Linux incident response triage

Reference: the official OpenSSH sshd_config manual documents every directive used above.