How to Secure SSH: Defending Against Brute-Force Attacks

The Secure Shell (SSH) protocol serves as the standard interface for remote administrative access to corporate Linux servers, cloud infrastructure, and network appliances. Because of its administrative privileges, port 22 is under continuous targeting from automated botnets deploying brute-force credential attacks, dictionary attacks, and deceptive tactic scanning tools.
Leaving the OpenSSH server daemon in its default configuration exposure represents a severe operational risk that can lead to complete host compromise and subsequent lateral movement across internal network segments.

To defend corporate access points, systems engineers must enforce a hardened, multi-layered OpenSSH server security baseline. The following technical guide details the configuration requirements to prevent unauthorized authentication loops and eliminate service visibility.

OpenSSH Infrastructure Comparison Matrix

Technical Security Vector	Default OpenSSH Configuration	Hardened Production Blueprint
Authentication Core	Text-based passwords permitted	Mandatory asymmetric cryptographic key pairs
Cipher Suite Suite	Legacy, vulnerable algorithms allowed	Modern cryptographic primitives exclusively
Network Visibility	Port 22 exposes daemon version strings	Alternative port binding with protocol obfuscation
Administrative Access	Direct remote superuser login active	Disallowed; isolation via unprivileged accounts
Connection Limits	Unlimited persistent terminal connections	Enforced time-outs and strict connection caps

---

Technical Hardening Architecture

All modifications to the OpenSSH server configuration must execute within the primary daemon file located strictly at /etc/ssh/sshd_config. Before modifying parameters, create a verified backup copy via cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.

Step 1: Enforcing Asymmetric Cryptographic Authentication

Text-based passwords are inherently vulnerable to dictionary attacks and credential stuffing. The absolute baseline requirement is transitioning the authentication layer to cryptographic key pairs.

1. Open /etc/ssh/sshd_config inside an administrative text editor.
2. Locate and modify the parameter to eliminate text password authentication entirely:
   PasswordAuthentication no
3. Ensure that empty password entries are explicitly blocked:
   PermitEmptyPasswords no
4. Enable public key ingestion validation:
   PubkeyAuthentication yes

Generate your endpoint connection keys using modern, secure cryptographic primitives like Ed25519 (ssh-keygen -t ed25519), which offer high cryptographic resistance with low performance overhead, discarding legacy RSA keys under 2048 bits.

Step 2: Restricting Remote Administrative Ingress

The primary superuser account (root) must never be accessible directly across public or external network structures.

1. Locate the root access parameter and update it to:
   PermitRootLogin no
2. Implement strict user whitelisting. Explicitly specify the exact individual unprivileged user accounts or system groups authorized to request SSH connections by appending an access control list at the bottom of the configuration file:
   AllowUsers sysadmin_alpha engineer_bravo
AllowGroups network_ops

Any inbound connection attempt initiated by a user account or group omitted from these strings will be instantly dropped at the initial handshake layer before authentication takes place.

Step 3: Hardening the Cryptographic Cipher Suite

Default OpenSSH setups frequently allow legacy key exchange algorithms and ciphers to maintain compatibility with outdated clients, exposing sessions to decryption and man-in-the-middle manipulation.
Restrict the active cryptographic negotiation block to modern, resilient algorithms by appending these explicit definitions:

KexAlgorithms curve25519-sha256,[email protected],diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]

This configuration enforces modern Authenticated Encryption with Associated Data (AEAD) ciphers and cryptographically resilient Elliptic Curve Diffie-Hellman (ECDH) key exchanges.

Step 4: De-escalating Network Port Visibility

Standard automated scanning tools exclusively target default network markers. Moving the service interface acts as a layer of basic obfuscation.

1. Modify the listening interface parameter from default port 22 to a custom high-range ephemeral destination:
   Port 22022
2. Restrict interface binding by mapping the service strictly to the internal corporate management network IP rather than all local interfaces (0.0.0.0):
   ListenAddress 192.168.10.15

Ensure that your server perimeter firewall (such as nftables, iptables, or cloud security groups) is updated to reflect this modification before restarting the daemon, dropping any inbound port 22 traffic automatically.

Step 5: Implementing Access Automation Limits and Timeouts

Unmanaged active connections expose system resources to denial-of-service conditions and terminal hijacking security flaws.

• Set a low automated drop limit for idle terminals:
  ClientAliveInterval 300
ClientAliveCountMax 0
  This configuration commands the daemon to drop any connection that remains inactive for exactly five minutes.
• Restrict the concurrency execution window for unauthenticated sessions to prevent automated brute-force multi-threading:
  MaxStartups 2:30:10
MaxAuthTries 3

Step 6: Validating and Restructuring the Daemon

Never restart the active SSH service without verifying the configuration syntax, as typographical errors can cause immediate lockouts from remote cloud hosts.

1. Run the test command string to audit changes:
   sshd -t
2. If the validation returns zero text output, the configuration syntax is correct. Execute the reload command:
   systemctl restart sshd
3. Always maintain your current active terminal session open while opening a secondary, independent terminal window to verify successful public-key authentication over the new custom port parameter before disconnecting.

---