← Back to Defend

Hardening

SSH

SSH is often the primary remote administration channel. Hardening SSH is about strong authentication, tight access control, and safe operational practices so that remote access remains reliable without being an easy entry point.

Learning objectives

What you should be able to do after reading.
  • Configure SSH for strong authentication and limited exposure
  • Reduce brute force risk and tighten who can log in
  • Use modern operational practices for admin access and key handling
  • Validate changes safely and avoid locking yourself out

At a glance

Fast mental model before you dive in.
🧠
Main goals
  • Keys or certificates instead of passwords where possible
  • No direct root login and clear user allow lists
  • Restricted network exposure and rate limiting
  • Logging so you can investigate access attempts
High impact controls
  • Disable PasswordAuthentication if feasible
  • Set PermitRootLogin to no or prohibit password based root login
  • Use AllowUsers or AllowGroups to limit access
  • Use a bastion or VPN instead of exposing SSH publicly
Practical workflow
  • Test changes in a second session before restarting sshd
  • Keep emergency access plans and known good configs
  • Rotate keys and remove access promptly when people leave
  • Monitor auth logs for failed logins and unusual sources

Overview

SSH hardening is less about secret magic settings and more about controlling trust boundaries. Decide who can reach the SSH service, who can authenticate, and what they can do after login.

Key based authentication is usually stronger than passwords because it is not vulnerable to online guessing in the same way. Combining keys with network restrictions and rate limiting drastically reduces brute force risk.

Operational safety matters. Always apply changes while you have a second open session, and validate config syntax before restarting the service.

  • Prefer keys or certificates and disable passwords where possible
  • Disallow direct root login and use sudo for elevation
  • Restrict access by user, group, and source network
  • Log and monitor authentication events
Watch out
Avoid self lockout
Before restarting sshd, keep a second session open and validate configuration syntax. One mistake can cut off remote access.
⚠️

Hardening actions

Each action below is safe on most systems, but always validate in a test session. Not every environment can disable passwords immediately, so treat the list as a progression.

Action What you do Why you do it Security effect
Use SSH keys for authentication Generate per user keys, store private keys securely, and deploy public keys to authorized keys. Keys are resistant to online guessing and can be rotated per user. Reduces credential stuffing and brute force effectiveness.
Disable password authentication where feasible Set PasswordAuthentication to no and ensure all users have working keys first. Passwords are easy to brute force and easy to phish. Eliminates password based brute force as an entry path.
Disable direct root login Set PermitRootLogin to no or at least prohibit password based root login and use sudo for elevation. Root is a high value target and often brute forced. Reduces direct privilege takeover risk.
Restrict who can log in Use AllowUsers or AllowGroups to define explicit allowed identities. A smaller allowed set reduces exposure and simplifies monitoring. Limits access and reduces account abuse risk.
Limit network exposure Bind SSH to management interfaces, use firewall rules, and prefer VPN or a bastion host for internet access. If fewer networks can reach SSH, fewer attackers can test credentials. Large reduction in attack surface.
Enable rate limiting and abuse controls Use tools such as fail2ban or firewall rate limits to slow repeated failures. Attackers rely on high volume guessing. Reduces brute force throughput and noise.
Use modern crypto defaults Keep OpenSSH updated and avoid enabling legacy ciphers or weak key types for compatibility unless required. Legacy crypto options are weaker and increase risk. Improves confidentiality and integrity of sessions.
Log and monitor SSH activity Collect auth logs and alert on repeated failures, new source locations, and admin logons. SSH attacks are visible if you look at the right signals. Improves detection and investigation quality.
Use separate admin accounts Do not use personal accounts for privileged tasks. Use sudo with auditability. It reduces accidental privilege creep and improves accountability. Better traceability and reduced blast radius.
Tip
Change one thing at a time
Do not flip many SSH settings at once. Apply, validate, and document each change so you can roll back safely.
💡

Signals to watch for

Patterns worth investigating further.
📡
  • Repeated authentication failures from many IP addresses
  • Successful logons from new geographies or unusual subnets
  • Unexpected root login attempts or sudo spikes
  • New keys added to authorized keys without a tracked change

DEEP DIVE

▾

Mental model: SSH is your management plane

SSH is not just a login tool, it is a control plane. If SSH fails, your attacker gains the same management reach that your administrators have. That is why SSH hardening should be treated like protecting an API for full system control.

A useful mental model is identity plus channel plus authority. Identity is how you authenticate. Channel is how sessions are established and forwarded. Authority is what the session can do once connected.

SSH hardening succeeds when you make identity strong, make sessions predictable, and make privileged actions auditable. You also need to avoid lockouts, because lockout pressure causes people to weaken configs permanently.

• Reduce who can attempt login, not only who can succeed.

• Reduce what a session can reach, for example by limiting forwarding and limiting admin scope.

• Increase evidence: session logs and clear records of key ownership.

Baseline priorities in sshd configuration

The biggest security gain usually comes from controlling authentication methods and narrowing the set of allowed users. Keys are safer than passwords when managed well, but unmanaged keys can become an invisible backdoor.

Key management has tradeoffs: if you disable password logins, you must be confident in your key lifecycle, including rotation and revocation. Otherwise a stolen private key becomes a long lived credential.

Modern SSH hardening is also about restricting risky features that are convenient but expand reach, such as agent forwarding, TCP forwarding, and unrestricted port tunnels.

Another tradeoff is usability in automation. CI systems and config management need access. The safe pattern is to use separate service accounts, scoped principals, and constrained commands rather than giving broad interactive access.

When you adopt stricter settings, plan a safe rollout so you can confirm access before you close the last door.

A good configuration is one you can explain. If you cannot explain why a directive exists, it will be misused during incident response.

Common traps in SSH hardening

A common failure mode is treating SSH as set and forget. Over time, more keys get added, old accounts stay enabled, and exceptions are made for convenience. The access surface slowly grows.

Another trap is relying on network location only. SSH exposed to internal networks still gets attacked through compromised endpoints, VPN access, and misrouted traffic. Assume attackers can reach internal SSH eventually.

Operational mistakes also matter: admins test changes on the wrong host, forget to reload, or maintain multiple config files that behave differently than expected.

Watch for hidden reachability through forwarding. A user with SSH access can often create tunnels that bypass network controls if forwarding is not constrained.

• Orphaned keys: keys without owners are high risk because you cannot rotate them with confidence.

• Break glass misuse: emergency access that becomes daily access is a predictable path to weak authentication.

Safe rollout and change control

Safe change control for SSH is not bureaucracy, it is how you avoid lockouts and avoid weakening controls under pressure. Always validate new settings in a parallel session before closing your last working session.

Roll out changes in stages. Start with a canary host, then a subset of hosts, then the fleet. If you have a bastion model, apply stricter rules at the bastion first because it is the choke point.

Use explicit allow lists for who can log in and from where. This reduces the chance that an unexpected account or key works silently.

When to relax hardening: sometimes you need temporary password auth for a vendor, or a temporary tunnel for migration. The safe pattern is time boxed access plus monitoring, then automatic reversion.

Document exceptions like you would document firewall rules: scope, owner, expiry, and test steps to confirm removal.

Prefer to relax by narrowing scope instead of weakening globally, for example allow one user from one source network for a short period.

Logging and detection that complements hardening

SSH hardening needs detection to catch what hardening cannot prevent, such as stolen keys or insider misuse. The goal is to make abnormal access visible quickly.

Verification starts with confirming effective configuration, not just what is written in a file. Different includes and match blocks can make two hosts behave differently even if they look similar.

How to verify, and what good looks like:

• Effective config: you can confirm the final evaluated config and it matches your intent

• Access surface: login attempts come from expected networks, and the allowed user list is short

• Auth behavior: password auth is disabled where intended, and key based auth is tied to known owners

• Session evidence: logs show who connected, from where, and what was executed for privileged paths

When to relax this: emergency recovery and initial bootstrap. Document the bootstrap window, keep it short, and ensure the host transitions into the standard baseline automatically.

Treat any permanent relaxation as a risk acceptance. Pair it with compensating controls such as tighter network scope, stronger MFA at a gateway, or session recording.