SSH Hardening: Secure Remote Access for Linux Servers

SSH is the most important management protocol for Linux servers. Every internet-facing server gets scanned by automated bots within minutes of going live — brute-force attacks, credential stuffing, and targeted exploits against outdated SSH versions are daily occurrences. A default SSH configuration with password authentication and root login enabled is as inviting as an unlocked front door. SSH hardening is not optional — it is a requirement for every production server.

Setting Up SSH Key Authentication

The first and most important step: replace passwords with SSH keys. Ed25519 is the current standard — faster, more secure, and with shorter keys than RSA:

# Generate an Ed25519 key pair
ssh-keygen -t ed25519 -C "admin@example.com"

# Copy the public key to the server
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server.example.com

Once the key is deployed, password authentication can be disabled. This immediately renders brute-force password attacks useless.

Hardening sshd_config

The central configuration file /etc/ssh/sshd_config determines the security level of the SSH service. These settings provide a solid baseline:

# /etc/ssh/sshd_config

# Non-standard port (reduces automated scans)
Port 2222

# Protocol 2 only
Protocol 2

# Disable root login
PermitRootLogin no

# Disable password authentication
PasswordAuthentication no
ChallengeResponseAuthentication no

# Limit authentication attempts
MaxAuthTries 3
MaxSessions 3

# Restrict access to specific users/groups
AllowUsers deploy admin
AllowGroups ssh-users

# Disconnect idle sessions
ClientAliveInterval 300
ClientAliveCountMax 2

# Disable unnecessary features
X11Forwarding no
AllowTcpForwarding no
PermitTunnel no

# Enforce strong cryptography
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

# Display warning banner
Banner /etc/ssh/banner

After every change, validate the configuration and restart the service:

# Check configuration for syntax errors
sshd -t

# Restart SSH service
systemctl restart sshd

Default vs. Hardened SSH Configuration

Setting	Default	Hardened
Port	22	2222 (or other non-standard port)
PermitRootLogin	yes	no
PasswordAuthentication	yes	no
MaxAuthTries	6	3
X11Forwarding	yes	no
ClientAliveInterval	0 (disabled)	300
AllowUsers / AllowGroups	All	Explicit whitelist
KexAlgorithms	All (including weak)	Modern algorithms only
AllowTcpForwarding	yes	no

Setting Up fail2ban

fail2ban monitors SSH logs and automatically bans IP addresses after multiple failed login attempts:

# Install fail2ban
apt install fail2ban

# Create local configuration (preserved during updates)
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Configure the SSH jail:

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

# Start and enable fail2ban
systemctl enable --now fail2ban

# Check status
fail2ban-client status sshd

As a lightweight alternative, sshguard detects attack patterns automatically and requires less configuration than fail2ban.

SSH Jump Hosts and Bastion Servers

In professional environments, internal servers should not be directly reachable from the internet. A jump host (bastion server) serves as the single point of entry:

# Connect through a jump host
ssh -J bastion.example.com user@internal-server

# Permanent configuration in ~/.ssh/config
Host internal-*
    ProxyJump bastion.example.com
    User deploy

Host bastion.example.com
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

The advantage: only one server needs to be exposed to the internet and hardened. All internal servers accept SSH connections exclusively from the bastion host — the attack surface is drastically reduced.

SSH Certificates Instead of authorized_keys

With many servers, distributing public keys becomes unmanageable. SSH certificates solve this problem: a central Certificate Authority (CA) signs user keys, and servers trust the CA:

# Create CA key (one-time setup)
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "SSH CA"

# Sign a user key (valid for 90 days)
ssh-keygen -s /etc/ssh/ca_key -I admin@example.com -n deploy -V +90d user_key.pub

On the servers, only the CA needs to be configured:

# In /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub

No more manual key distribution, centralized revocation, automatic expiry — SSH certificates are the scalable approach for larger environments.

Two-Factor Authentication with Google Authenticator

For maximum security, SSH can be combined with TOTP-based 2FA — key plus one-time password:

# Install the PAM module
apt install libpam-google-authenticator

# Set up as user
google-authenticator

Configure PAM and sshd:

# Add to /etc/pam.d/sshd:
auth required pam_google_authenticator.so

# In /etc/ssh/sshd_config:
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

After restarting sshd, every login requires both the SSH key and the current TOTP code from the authenticator app.

Auditing SSH with ssh-audit

The open-source tool ssh-audit analyses the SSH configuration and evaluates algorithms, key lengths, and known vulnerabilities:

# Install and run ssh-audit
pip install ssh-audit
ssh-audit server.example.com

ssh-audit displays colour-coded results showing which algorithms are secure, deprecated, or insecure. After hardening, the scan should show only green entries. Regular scans ensure the configuration remains intact after updates.

Port Knocking

Port knocking hides the SSH port completely behind the firewall. Only a specific sequence of connection attempts on closed ports temporarily opens SSH access:

# Install knockd
apt install knockd

# /etc/knockd.conf
[openSSH]
    sequence = 7000,8000,9000
    seq_timeout = 10
    command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 2222 -j ACCEPT
    tcpflags = syn

[closeSSH]
    sequence = 9000,8000,7000
    seq_timeout = 10
    command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 2222 -j ACCEPT
    tcpflags = syn

Port knocking is not a replacement for proper authentication, but it is an effective additional barrier against port scanners and automated attacks.

SSH Monitoring with DATAZONE Control

Hardening is not a one-time project — configurations drift, new vulnerabilities are discovered, and attack patterns evolve. DATAZONE Control monitors SSH-related parameters continuously:

• Failed login attempts detected and alerted in real time
• sshd_config changes tracked — unexpected deviations from the desired state reported immediately
• SSH key rotation monitored — expiring certificates and keys identified in advance
• Active SSH sessions monitored — unusual connection times or sources detected

The combination of hardened configuration and continuous monitoring closes the gap between one-time setup and ongoing protection.

Frequently Asked Questions

Is changing the port enough protection?

No. A non-standard port significantly reduces automated scans and log noise, but offers no real protection. A targeted attacker finds open ports in seconds. Changing the port is a useful addition, but not a substitute for key authentication and a hardened configuration.

What if I lock myself out?

Before every change: keep an existing SSH session open and test in a second session. For cloud servers, the provider’s console offers emergency access. Always validate configuration changes with sshd -t first.

How often should I rotate SSH keys?

Regular SSH keys have no technical expiry — annual rotation is good practice. SSH certificates should be issued with a 90-day validity to limit the risk of compromised keys.

---

Looking to secure your Linux servers professionally? Contact us — we implement SSH hardening, set up bastion servers, and monitor your infrastructure with DATAZONE Control.