SSH hardening is the systematic configuration of a Secure Shell server, almost always OpenSSH’s sshd, so that remote administrative access accepts only the minimum set of users, authentication methods and algorithms required. In Linux security it is one of the first tasks on any internet-facing host, because the SSH daemon is usually the only privileged remote entry point and is scanned continuously by automated attackers.
Hardening does not replace patching or monitoring. It narrows who can log in, how they prove identity, from where, and with which cryptography, and it limits the damage a stolen credential can cause. Most of the work happens in /etc/ssh/sshd_config and its drop-in directory, supported by host firewalls, PAM and log-based tools such as Fail2ban.
How SSH hardening reduces risk on Linux
SSH hardening reduces risk by removing the weak paths an attacker would try first: password guessing, direct root login, outdated algorithms and unrestricted network reachability. On a default Linux installation, sshd often accepts passwords, listens on all interfaces and allows any local account with a valid shell to authenticate.
The sshd daemon reads its settings at startup, and on recent distributions the main file includes /etc/ssh/sshd_config.d/*.conf. Because the first value obtained for a keyword wins, a drop-in file loaded early can silently override the main file. The effective configuration should therefore always be confirmed with sshd -T, which prints the merged result, rather than by reading one file.
Hardening works in layers that fail independently. A firewall rule limits who can reach port 22, key-only authentication defeats password spraying, AllowGroups restricts which accounts are eligible, and rate limiting slows anything that slips through. No single setting is decisive; the combination is what makes the service resistant to automated attacks.
Core sshd_config directives and recommended values
The following table lists the directives that carry the most weight in a hardened configuration, with the values most baselines recommend and the reason behind each.
| Directive | Hardened value | Effect |
|---|---|---|
| PermitRootLogin | no (or prohibit-password) | Forces administrators to log in as named users and escalate with sudo |
| PasswordAuthentication | no | Removes password guessing as an attack path |
| KbdInteractiveAuthentication | no (unless used for MFA) | Closes the second password-style prompt path |
| PubkeyAuthentication | yes | Enables key-based logins |
| AllowGroups | A dedicated group such as sshusers | Limits login to explicitly approved accounts |
| MaxAuthTries | 3 to 4 | Ends a connection after a few failed attempts |
| LoginGraceTime | 20 to 30 seconds | Drops unauthenticated connections quickly |
| X11Forwarding | no | Disables an unneeded forwarding channel |
| AllowTcpForwarding | no, or local for bastions | Prevents the server from becoming a tunnel |
| ClientAliveInterval / ClientAliveCountMax | 300 / 2 | Closes idle or dead sessions |
| LogLevel | VERBOSE | Records the key fingerprint used for each login |
Setting LogLevel to VERBOSE is often overlooked, yet it is the only way to know which key, and therefore which person or automation, opened a session. Without it, an incident review can show only the account name.
Authentication methods and their strength
The authentication method is the single most important hardening decision, because it determines what an attacker must steal or guess. The comparison below orders the common methods from weakest to strongest.
| Method | What an attacker needs | Main weakness | Typical use |
|---|---|---|---|
| Password | A guessed or reused password | Brute force and credential stuffing | Avoid on exposed hosts |
| Password plus TOTP via PAM | Password and current code | Phishing in real time | Legacy environments |
| Public key (Ed25519) | The private key file and its passphrase | Key theft from a workstation | Standard baseline |
| FIDO2 security key (ed25519-sk) | Physical token and touch | Loss of the token | Administrators of critical systems |
| SSH certificates | A key signed by the internal CA | Compromise of the CA key | Large fleets with short-lived access |
Ed25519 keys are the current default choice: short, fast and free of the parameter pitfalls of older types. RSA remains acceptable at 3072 bits or more, while DSA is disabled in modern OpenSSH. Hardware-backed keys of type ed25519-sk require a physical touch, which defeats malware that copies key files silently.
For larger estates, SSH certificates signed by an internal certificate authority solve the hardest operational problem: revoking access. A certificate valid for 8 to 24 hours expires on its own, whereas a forgotten line in authorized_keys can grant access for years.
Cryptographic algorithm selection
Algorithm hardening restricts sshd to modern key exchange, cipher and MAC algorithms so that a downgrade to a weak option is impossible. Current OpenSSH releases already prefer strong defaults, so explicit lists matter mainly on older systems or under compliance requirements.
| Category | Configuration keyword | Preferred choices | Remove |
|---|---|---|---|
| Key exchange | KexAlgorithms | sntrup761x25519-sha512, mlkem768x25519-sha256, curve25519-sha256 | diffie-hellman-group1-sha1, group14-sha1 |
| Ciphers | Ciphers | chacha20-poly1305, aes256-gcm, aes128-gcm | CBC modes, 3des-cbc, arcfour |
| MACs | MACs | hmac-sha2-512-etm, hmac-sha2-256-etm | hmac-md5, hmac-sha1, non-ETM variants |
| Host keys | HostKey | ssh_host_ed25519_key, RSA 3072+ | ssh_host_dsa_key, small RSA keys |
The hybrid post-quantum key exchanges combine a classical curve with a lattice-based scheme to protect recorded traffic against future decryption. A frequent mistake is copying an old cipher list from a guide, which can disable these newer defaults and actually weaken the server.
Network exposure and complementary controls
Limiting who can reach the SSH port at all is usually more effective than any sshd setting. Typical measures are a host firewall that allows port 22 only from management networks or a VPN, a single hardened bastion host in front of internal servers, and binding sshd to a management interface with ListenAddress.
Several neighboring Linux security tools reinforce SSH hardening without replacing it. Fail2ban bans addresses after repeated failures, auditd records privileged commands executed after login, and SELinux or AppArmor confine what the daemon itself can access. Moving SSH to a non-standard port reduces log noise but is not a security control, because port scanners find it within minutes.
- Use firewall allowlists or a VPN as the first barrier.
- Route administrative access through a bastion with session logging.
- Rate-limit new connections with nftables or Fail2ban.
- Keep OpenSSH patched through the distribution, for example with unattended-upgrades.
Common mistakes and how to avoid lockouts
Most SSH hardening incidents are self-inflicted lockouts or silent misconfigurations, not clever attacks. The table pairs frequent errors with their symptoms and fixes.
| Mistake | Symptom | Fix |
|---|---|---|
| Disabling passwords before deploying keys | Administrators locked out | Test a key login in a second session before reloading |
| Drop-in file overrides main config | Passwords still accepted | Check the merged result with sshd -T |
| Wrong permissions on ~/.ssh | Keys silently rejected | Set 700 on the directory and 600 on authorized_keys |
| Unprotected private keys | Stolen key gives full access | Require passphrases or hardware keys |
| Stale entries in authorized_keys | Former staff retain access | Review keys regularly or use certificates |
The safe procedure is to validate syntax with sshd -t, keep an existing session open, reload the service and confirm a fresh login works before closing the original connection. On cloud servers, an out-of-band console should be confirmed as available beforehand.
Understanding it simply
SSH is the remote door administrators use to manage a Linux server. SSH hardening means fitting that door with better locks and deciding exactly who receives a key. Instead of a password that anyone could guess, each person carries a unique digital key, and only people on an approved list may even try the door.
It also means checking that the lock mechanism itself is modern and that the door is not visible from every street. The goal is simple: make unauthorized entry impractical while keeping access easy for the people who genuinely need it.
Applied in practice
A small company runs twelve Linux web servers with SSH open to the internet, and the logs show thousands of failed password attempts per day. The operations team first distributes Ed25519 keys to its four administrators and confirms each key login works, then disables password authentication and root login in a drop-in file and verifies the merged settings with sshd -T.
Next, the team creates an sshusers group, restricts logins with AllowGroups, sets LogLevel to VERBOSE and limits port 22 in the firewall to the office VPN range. Within a day, failed attempts in the logs drop to nearly zero, because the servers are no longer reachable from the open internet, and every remaining login is traceable to a specific administrator’s key.