SSH Security Best Practices

SSH Security Best Practices

The default SSH configuration on a fresh Ubuntu install is functional but not hardened. Password authentication over SSH exposes your server to brute-force attacks — any server with port 22 open to the internet will receive thousands of login attempts daily. The hardening checklist below addresses the most impactful security settings. The golden rule: always test configuration changes before closing your current session.

Disable password authentication

# BEFORE disabling password auth:
# 1. Ensure you have key-based auth working AND tested
# 2. Ensure at least one user has keys in authorized_keys
# 3. Keep your current SSH session open while testing

sudo nano /etc/ssh/sshd_config

# Set these values:
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no    # Or keep yes but set PasswordAuthentication no

# Test config syntax
sudo sshd -t

# Apply (keeps existing sessions — opens a NEW terminal to test before closing this one)
sudo systemctl reload ssh

# Test login with keys from a NEW terminal window
# If successful, close the old session

⚠️ WARNING: Do NOT close your existing SSH session until you have verified that key-based login works from a SEPARATE terminal window. If you misconfigure and key auth fails, you will be locked out. Always have console access (cloud vendor console, IPMI) as a backup before disabling password auth on a remote server.

Disable root login

# In /etc/ssh/sshd_config:

# Option 1: Disable root SSH entirely (best practice)
PermitRootLogin no

# Option 2: Allow root only with keys (no password)
PermitRootLogin prohibit-password    # Ubuntu default

# Rationale: root is the obvious target for brute force.
# Log in as a regular user, then sudo — creates an audit trail
# and prevents direct root compromise via SSH brute force.

Restrict which users can log in

# Allow only specific users:
AllowUsers irfan deploy ansible

# Allow only users in specific groups:
AllowGroups sshusers admins

# Deny specific users:
DenyUsers legacy-user temp-user

# Deny specific groups:
DenyGroups noSSH

# The evaluation order: DenyUsers → AllowUsers → DenyGroups → AllowGroups
# A user matching DenyUsers is always denied regardless of other rules

Idle timeout and auth settings

# In /etc/ssh/sshd_config:

# Disconnect idle sessions after 15 minutes of inactivity
ClientAliveInterval 300    # Send keepalive every 5 minutes
ClientAliveCountMax 3      # Disconnect after 3 missed keepalives (15min total)

# Limit authentication attempts before disconnecting
MaxAuthTries 3             # Only 3 attempts per connection

# Disconnect if login not completed within 30 seconds
LoginGraceTime 30

# Limit simultaneous unauthenticated connections (prevents parallelized brute force)
MaxStartups 10:30:60       # 10 unauthenticated: start refusing 30%, max 60 connections

Testing sshd configuration safely

# Rule: ALWAYS test sshd config before reloading

# Step 1: Check syntax
sudo sshd -t

# Step 2: Run a second sshd on a different port (without replacing the running one)
sudo sshd -p 2222 -f /etc/ssh/sshd_config -D &

# Step 3: Test the new config from another terminal
ssh -p 2222 user@server

# Step 4: If it works, reload the real sshd
sudo systemctl reload ssh

# Step 5: Kill the test sshd
sudo pkill -f "sshd -p 2222"

Conclusion

The minimal SSH hardening checklist: (1) disable password authentication, (2) disable root login, (3) add AllowUsers to restrict who can log in, (4) set ClientAliveInterval and MaxAuthTries. These four changes eliminate the vast majority of SSH attack vectors. Always run sudo sshd -t after editing sshd_config and test from a separate terminal before closing your current session. A locked-out production server is worse than a misconfigured one.