SSH Hardening Skill

Secure SSH access to VPS servers by implementing industry-standard hardening practices.

What This Skill Does

This skill helps AI agents harden SSH configuration on VPS servers. SSH is the primary entry point for server management, making it a critical attack vector. Proper SSH hardening prevents unauthorized access, brute-force attacks, and credential theft.

Key capabilities:

Create non-root users with sudo privileges
Generate and configure SSH key authentication
Disable password-based authentication
Disable root login over SSH
Configure security settings in sshd_config
Test configuration before applying

When to Use

Use this skill when you need to:

Set up a new VPS server with secure SSH access
Replace password authentication with SSH keys
Disable root login for security compliance
Harden an existing server against brute-force attacks
Fix security audit findings related to SSH
Implement principle of least privilege

Critical understanding: Root can do anything. One typo, one compromised session, and your entire system is gone. Passwords can be guessed. SSH keys can't be brute-forced in any practical timeframe.

Prerequisites

Root or existing sudo user access to the server
SSH access to the server (keep current session open!)
SSH client on local machine (ssh, ssh-keygen, ssh-copy-id)
Terminal access to local machine

SSH Hardening Steps

Step 1: Create Non-Root User

CRITICAL: Complete this step and test before disabling root login!

Create a new user for daily operations:

# Create user (replace 'deployer' with desired username)
sudo adduser deployer

Enter a strong password when prompted.

Add user to sudo group:

sudo usermod -aG sudo deployer

Test sudo access before proceeding:

# Switch to new user
su - deployer

# Test sudo
sudo whoami
# Should output: root

# Exit back to original user
exit

Step 2: Generate SSH Key Pair (Local Machine)

On your local machine (not the server), generate an SSH key:

ssh-keygen -t ed25519 -C "your-email@example.com"

Key type explained:

ed25519 - Modern, secure, fast (recommended)
Alternative: rsa -b 4096 for older systems

When prompted:

Press Enter to save to default location (~/.ssh/id_ed25519)
Enter a strong passphrase (recommended) or leave empty

Step 3: Copy SSH Key to Server

From your local machine, copy the public key to the server:

ssh-copy-id deployer@your-server-ip

Enter the user's password when prompted.

Manual alternative (if ssh-copy-id is unavailable):

# On local machine, display public key
cat ~/.ssh/id_ed25519.pub

# On server, as the new user
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
# Paste the public key, save and exit
chmod 600 ~/.ssh/authorized_keys

Step 4: Test SSH Key Authentication

CRITICAL: Test in a NEW terminal window, keep existing session open!

ssh deployer@your-server-ip

You should connect without entering a password (or only your SSH key passphrase).

If connection fails, DO NOT proceed to Step 5! Debug the issue first.

Step 5: Harden SSH Configuration

WARNING: Make these changes carefully. Test in a new terminal before closing existing sessions!

Edit SSH daemon configuration:

sudo nano /etc/ssh/sshd_config

Update or add these settings:

# Disable root login
PermitRootLogin no

# Disable password authentication
PasswordAuthentication no

# Disable empty passwords
PermitEmptyPasswords no

# Limit authentication attempts
MaxAuthTries 3

# Allow only specific users (optional but recommended)
AllowUsers deployer

# Use only SSH protocol 2
Protocol 2

# Disable X11 forwarding (unless needed)
X11Forwarding no

# Set login grace time
LoginGraceTime 60

# Disable host-based authentication
HostbasedAuthentication no

Optional advanced settings:

# Change default port (security through obscurity, optional)
# Port 2222

# Disable agent forwarding (unless needed)
# AllowAgentForwarding no

# Disable TCP forwarding (unless needed)
# AllowTcpForwarding no

# Set idle timeout
# ClientAliveInterval 300
# ClientAliveCountMax 2

Step 6: Test Configuration

Test the configuration file for syntax errors:

sudo sshd -t

No output means the configuration is valid.

Step 7: Restart SSH Service

CRITICAL: Test in a new terminal BEFORE restarting!

# Test connection in NEW terminal first
ssh deployer@your-server-ip

# If successful, restart SSH (in original terminal)
sudo systemctl restart sshd

Verification:

sudo systemctl status sshd

Step 8: Verify Root Login is Disabled

Try to connect as root (should fail):

ssh root@your-server-ip

Expected result: Permission denied (publickey)

Configuration Reference

AllowUsers vs AllowGroups

Restrict SSH access to specific users or groups:

# Option 1: Specific users
AllowUsers deployer admin

# Option 2: Users in specific group
AllowGroups sshusers

Port Changes

Changing the default SSH port (22) reduces noise from automated scanners:

Port 2222

Remember to:

Update firewall rules before restarting SSH
Use the new port when connecting: ssh -p 2222 user@host

Key-Based Authentication Only

Ensure these settings work together:

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

Security Best Practices

Always test before closing sessions - Keep one session open until verified
Use SSH key passphrases - Adds another layer of security
Limit user access - Use AllowUsers or AllowGroups
Monitor authentication logs - Check /var/log/auth.log regularly
Use fail2ban - Add automated banning for repeated failed attempts
Regular key rotation - Periodically generate new keys
Disable unused features - X11Forwarding, TCP forwarding, etc.

Troubleshooting

Locked Out of Server

Prevention is key:

Always keep one session open when making changes
Test in a new terminal before closing existing sessions
Have console access via hosting provider's control panel

Recovery:

Use hosting provider's console/VNC access
Revert changes to /etc/ssh/sshd_config
Restart sshd service

SSH Key Not Working

# Check file permissions on server
ls -la ~/.ssh/
# Should show:
# drwx------ .ssh/
# -rw------- authorized_keys

# Fix permissions if needed
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

# Check SSH logs
sudo tail -f /var/log/auth.log

Connection Refused After Changes

# Check SSH service status
sudo systemctl status sshd

# View recent errors
sudo journalctl -u sshd -n 50

# Test configuration
sudo sshd -t

Common Mistakes to Avoid

❌ Closing all SSH sessions before testing new configuration
❌ Disabling password auth before setting up SSH keys
❌ Not testing sudo access for new user
❌ Typos in sshd_config causing service failure
❌ Forgetting to restart sshd after changes
❌ Not updating firewall when changing SSH port

Additional Resources

See references/sshd-config.md for complete sshd_config reference.

See scripts/setup-ssh-hardening.sh for automated setup script.

Related Skills

firewall-configuration - Restrict SSH port access
fail2ban-setup - Auto-ban brute-force attempts
auto-updates - Keep SSH patched against vulnerabilities