NNEON//FORGE← Vault
SECURITY / BEGINNER / +150 XP

SSH is your front door. Harden it.

Most servers get breached through the front door. Lock yours before you need to.

Most servers get breached through the front door. SSH is the front door. It is the most exposed service on most servers, the most targeted by attackers, and the most neglected by administrators. The default SSH configuration is a welcome mat for brute-force attacks.

Hardening SSH is not optional. It is the minimum viable security. If you have a server on the internet with SSH open and password authentication enabled, you are being scanned right now. The bots do not sleep. The attacks do not stop. The question is not if you will be targeted — it is when.

THE DEEP DIVE

The Hardening Checklist

# /etc/ssh/sshd_config — hardened configuration

# Authentication
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30

# Access control
AllowUsers deploy admin
AllowGroups ssh-users

# Protocol
Protocol 2
X11Forwarding no
PermitEmptyPasswords no

# Cryptography (modern only)
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
HostKeyAlgorithms ssh-ed25519

# Logging
LogLevel VERBOSE
SyslogFacility AUTH

# Connection
ClientAliveInterval 300
ClientAliveCountMax 2
MaxSessions 3
MaxStartups 10:30:60

Fail2ban as the First Line

Fail2ban monitors SSH log files for failed authentication attempts. When it detects a brute-force attack, it bans the source IP address. The default configuration is too lenient — it allows 5 attempts in 10 minutes. That is 5 attempts too many.

Configure fail2ban to ban after 3 attempts in 1 minute. Set the ban time to 1 hour for first offenses, 24 hours for repeat offenders. Use the aggressive jail configuration for high-value servers.

PRINCIPLES

  1. Password authentication is a liability. Use key-based authentication exclusively.
  2. Root login via SSH is never necessary. Use a regular user and sudo.
  3. The default SSH configuration is designed for compatibility, not security.
  4. SSH keys are credentials. Protect them like passwords. Use passphrases.
  5. Log everything. SSH logs are the first evidence in a breach investigation.

IN PRACTICE

Key-Based Auth Setup

Generate an Ed25519 key pair. Copy the public key to the server. Disable password authentication. The private key never leaves your machine. The server never sees a password. Brute-force attacks become impossible.

SSH Certificate Authority

For large infrastructure, use SSH certificates instead of authorized_keys. The CA signs short-lived certificates. Revocation is instant. No need to manage hundreds of public keys across servers.

LIVE SIGNALS

These items surfaced from the intelligence pipeline at generation time.

  • CVE-1999-0095 — The debug command in Sendmail is enabled, allowing attackers to execute commands as root. (NVD / CVE)
  • CVE-1999-1471 — Buffer overflow in passwd in BSD based operating systems 4.3 and earlier allows local users to gain root privileges by specifying a long shell or GECOS field. (NVD / CVE)
  • CVE-1999-1122 — Vulnerability in restore in SunOS 4.0.3 and earlier allows local users to gain privileges. (NVD / CVE)
  • CVE-1999-1506 — Vulnerability in SMI Sendmail 4.0 and earlier, on SunOS up to 4.0.3, allows remote attackers to access user bin. (NVD / CVE)
  • CVE-1999-0084 — Certain NFS servers allow users to use mknod to gain privileges by creating a writable kmem device and setting the UID to 0. (NVD / CVE)

ANTIPATTERNS

  • Using RSA keys smaller than 4096 bits. Ed25519 is faster and more secure.
  • Sharing SSH keys between team members. Each person gets their own key.
  • Disabling SSH logging to reduce disk usage. Logs are evidence.
  • Using port 22 and hoping attackers will not find it. Change the port as a basic measure.

CHECKLIST

  • Password authentication is disabled
  • Root login is disabled
  • Only specific users/groups are allowed to connect
  • SSH keys use Ed25519 or RSA-4096
  • Fail2ban or equivalent is configured
  • SSH logs are monitored and alerting is configured

YOUR MOVE

Audit your SSH configuration right now. Run sshd -T | grep -E 'passwordauthentication|permitrootlogin|maxauthtries'. If any of these are not what you expect, fix them.