Overview
SSH is the standard way to administer Linux remotely — and because it grants shell access, it is a prime target. Hardening SSH is one of the most important host-security tasks. This lesson covers key SSH hardening concepts.
Learning objectives
- Identify high-impact SSH hardening measures.
- Explain key-based authentication versus passwords.
- Describe where SSH server settings live.
Core concept
SSH server behavior is configured in /etc/ssh/sshd_config. High-impact hardening measures include:
- Disable root login —
PermitRootLogin no, so attackers cannot target the all-powerful root account directly. - Prefer key-based authentication over passwords — keys resist brute-forcing; optionally set
PasswordAuthentication no. - Limit who can log in — restrict to specific users/groups (
AllowUsers/AllowGroups). - Change or protect exposure — consider limiting SSH to trusted networks (via firewall) rather than exposing it broadly.
- Reload the service after changes for them to take effect.
How it works
SSH keys use public-key cryptography: you place your public key on the server (~/.ssh/authorized_keys) and keep the private key secret (permissions 600). Login then requires possession of the private key rather than a guessable password, which defeats password brute-forcing. Disabling root login forces attackers to first compromise a normal account and then escalate, adding a hurdle and improving accountability. Restricting allowed users and network exposure further shrinks who can even attempt to connect.
Practical example
Hardening /etc/ssh/sshd_config might set:
PermitRootLogin no
PasswordAuthentication no
AllowGroups ssh-users
Then the admin reloads SSH. Now only members of ssh-users may connect, only with a valid key (no password guessing possible), and never directly as root. Combined with a firewall rule limiting SSH to the admin network, the service is far less exposed than a default configuration.
Cybersecurity relevance
SSH is one of the most frequently attacked services — internet-facing SSH sees constant automated password brute-force attempts. Hardening it (keys not passwords, no root login, restricted users, limited exposure) neutralizes the most common attacks and is a near-universal recommendation. Weak SSH configuration (root login allowed, password auth exposed to the internet) is a classic finding. Protecting private keys with correct permissions is equally essential, tying back to the permissions module.
Common mistakes
- Allowing direct root login or exposing password authentication to the internet, inviting brute-force.
- Poorly protected private keys (wrong permissions), which SSH may reject and which risk key theft.
- Forgetting to reload SSH after editing
sshd_config, so changes do not apply.
Key takeaways
- SSH server settings live in
/etc/ssh/sshd_config; high-impact hardening includes disabling root login, preferring key-based auth, and limiting allowed users and exposure. - Key-based authentication (public key on server, private key kept secret at
600) defeats password brute-forcing. - SSH is heavily targeted; hardening it and protecting private keys neutralizes the most common remote attacks and is a standard recommendation.
Check your understanding
- Why is key-based authentication more resistant to attack than password authentication for SSH?
- What does setting
PermitRootLogin noaccomplish from a security standpoint?