Setting up a new Virtual Private Server (VPS) is exciting. But if you skip the SSH key security checklist, your server could get hacked in minutes. A VPS is a computer you rent online to run websites, apps, or games. SSH (Secure Shell) is how you control it. This guide walks you through every step. Even if you are new to servers, you can do it.
This SSH key security checklist covers everything. From generating your first key to rotating it every 90 days. Follow each phase in order. By the end, your VPS will be as safe as a bank vault.
Quick Start – Essential SSH Key Security Checks
Before we start the deep dive, here is the fast version. Keep this handy. This quick SSH key security checklist covers the top actions:
- Generate an Ed25519 SSH key pair
- Set a strong passphrase on your private key
- Create a non-root user on your VPS
- Copy your public key to the server
- Turn off password login in sshd_config
- Disable root login over SSH
- Change the SSH port from 22
- Set up a firewall (UFW) to block bad traffic
- Install Fail2Ban to stop brute-force attacks
- Keep logs and rotate keys every 90 days
If you only read one part, read this. Now let us go deep into each phase.
Phase 1: Pre-Deployment Preparation
Before you touch the VPS, do this work on your local machine. Good prep saves headaches later.
Generate SSH Keys with Best Practices
Open a terminal. On Windows, use PowerShell or Windows Terminal. Type this command:
ssh-keygen -t ed25519 -C "your_email@example.com"
This creates two files in ~/.ssh/:
- id_ed25519 — your private key (SECRET, never share this)
- id_ed25519.pub — your public key (goes on the VPS)
Press Enter to save at the default path. Then set a passphrase (more on this in Phase 1.3).
Choose the Right Key Type (Ed25519 vs RSA-4096)
Ed25519 is the best choice for new VPS setups in 2026. It is fast, short, and very secure. RSA works too, but needs a 4096-bit key to match Ed25519’s safety. Only pick RSA if you must work with very old hardware.
| Key Type | Speed | Key Size | Best For |
|---|---|---|---|
| Ed25519 | Very fast | Short | New VPS setups |
| RSA-4096 | Slower | Long | Old systems only |
Set Strong Passphrases for Private Keys
A passphrase is a password for your private key. It adds a second lock. Without it, anyone who steals your laptop can log into your VPS.
Good passphrases:
- Are long (15+ characters)
- Mix words, numbers, and symbols
- Are not in any password list
Store it in a password manager like Bitwarden or 1Password. Never memorize only, or write it on paper near your keyboard.
Secure Key Storage and Backup Strategy
Your SSH key security checklist must include backup. Encrypt your private key and store the backup in two places:
- A USB drive in a safe or locker
- An encrypted cloud folder (use Veracrypt or Cryptomator)
Never email keys. Never upload them to GitHub. Treat them like your house key.
Phase 2: Initial VPS Setup and Key Deployment
First Login and Non-Root User Creation
Most VPS providers email you the root password. Log in once with SSH:
ssh root@your_server_ip
Type the password. Then right away, create a regular user:
adduser myuser
Give it a strong password. Then grant it sudo rights:
usermod -aG sudo myuser
This is a key part of the VPS SSH key security checklist — never work as root.
Deploy SSH Public Key to VPS
From your local machine, copy your public key to the new user:
ssh-copy-id myuser@your_server_ip
Or do it by hand:
ssh myuser@your_server_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Paste your public key when asked. Press Ctrl+D to end.
Verify Key Authentication Works
Test the key login:
ssh myuser@your_server_ip
You should enter without a password. If it asks for a password, stop. Go back and fix the key step.
Test from Multiple Machines and Locations
Before locking things down, try SSH from:
- Your laptop at home
- Your phone with a Termux app
- A second PC
Each machine needs its own SSH key pair. The VPS SSH key security checklist must include every device you will use.
Phase 3: Core SSH Hardening Configuration
Disable Password Authentication in sshd_config
Edit the SSH config file:
sudo nano /etc/ssh/sshd_config
Find (or add) these lines:
PasswordAuthentication noKbdInteractiveAuthentication no
Save with Ctrl+O, then Enter, then Ctrl+X.
Disable Root Login Completely
In the same file, change:
PermitRootLogin no
This means even if someone gets the root password, they cannot log in over SSH. Huge win for VPS SSH key security checklist.
Change Default SSH Port
Port 22 is the default. Bots scan it first. Change to a high port between 10000 and 65535:
Port 54321
Add the new port to your firewall before logging out.
Configure Session Timeout Settings
Add these for idle timeout:
ClientAliveInterval 300ClientAliveCountMax 2LoginGraceTime 30MaxAuthTries 3
This kills idle connections and blocks slow attacks.
Restart SSH Service and Verify Changes
sudo systemctl restart sshd
Do NOT close your current session. Open a new terminal and test:
ssh -p 54321 myuser@your_server_ip
If the new port works, you can close the old session.
Phase 4: Verification and Testing Phase
Test SSH Key Login Without Root Access
Try to log in as root:
ssh -p 54321 root@your_server_ip
It should fail. If it works, check sshd_config again.
Verify Password Authentication is Disabled
Force a password test:
ssh -o PubkeyAuthentication=no -p 54321 myuser@your_server_ip
It should reject the password, even if you type it right.
Check for Unauthorized Keys in authorized_keys
Look at the keys allowed:
cat ~/.ssh/authorized_keys
Every line is one public key. You should recognize each one. Anything strange — delete it.
Run Security Scan with nmap
From your local machine:
nmap -p 54321 your_server_ip
It should show the SSH port open and nothing else strange.
Phase 5: Advanced Security Layers
Install and Configure Fail2ban
Fail2ban blocks IPs that try too many wrong keys.
sudo apt install fail2ban
Create a local config:
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Edit /etc/fail2ban/jail.local and add:
[sshd]enabled = trueport = 54321maxretry = 3findtime = 600bantime = 3600
Restart: sudo systemctl restart fail2ban
Set Up UFW Firewall Rules
UFW is a simple firewall for Linux:
sudo apt install ufwsudo ufw default deny incomingsudo ufw default allow outgoingsudo ufw allow 54321/tcpsudo ufw allow 80/tcpsudo ufw allow 443/tcpsudo ufw enable
This is a must-have part of any SSH key security checklist.
Configure SSH Agent Forwarding Security
SSH agent forwarding is useful but risky. In sshd_config:
AllowAgentForwarding no
Only set to yes when you truly need it.
Enable Login Alerts and Monitoring
Install mailutils to get email alerts:
sudo apt install mailutils
Set up a script using /etc/ssh/sshrc that emails you on every login.
Phase 6: Team and Multi-User SSH Key Management
Add Multiple Users with Separate SSH Keys
For every teammate, create a user: sudo adduser teammate
Have them send you their public key. Add it to their own authorized_keys file. Never share keys between users.
Implement Sudo Access Controls
Edit /etc/sudoers using sudo visudo:
- Only trusted users get
(ALL : ALL) ALL - Others get limited commands
Track and Audit All Authorized Keys
Run a search once a week:
sudo find / -name "authorized_keys" -type f 2>/dev/null
Check each file. Remove old ones.
Establish Key Revocation Procedures
When someone leaves:
- Remove their public key from authorized_keys
- Delete the user if not needed:
sudo deluser --remove-home username - Rotate keys for any shared keys
- Review logs for their last login
Phase 7: Ongoing Maintenance and Key Rotation
Schedule Regular SSH Key Rotation (90 days)
Keys can leak. Rotate them every 90 days. Set a calendar reminder.
Procedure for Rotating Keys Without Downtime
- Generate a new SSH key pair on your local machine
- Add the new public key to authorized_keys (keep the old too)
- Test the new key:
ssh -i ~/.ssh/id_ed25519_new -p 54321 myuser@your_server_ip - Once working, remove the old key from authorized_keys
- Delete the old private key file
This lets you switch keys without locking yourself out.
Monitor SSH Login Attempts and Logs
Check the auth log often:
sudo tail -f /var/log/auth.log
Look for failed logins from unknown IPs. Use grep to find patterns:
sudo grep "Failed password" /var/log/auth.log | wc -l
Day 30 Security Review Checklist
- Review all users and SSH keys
- Check Fail2ban ban list (
sudo fail2ban-client status sshd) - Confirm firewall rules are intact
- Update the system (
sudo apt update && sudo apt upgrade) - Test backup restore of keys
Troubleshooting Common SSH Key Issues
Recovering from SSH Lockout Scenarios
Locked out? Most VPS panels have a web console. Use it to log in and fix your sshd_config.
Fixing Permission Errors (chmod 600, 700)
SSH will refuse keys with wrong permissions. Fix them on the VPS:
chmod 700 ~/.sshchmod 600 ~/.ssh/authorized_keyschmod 644 ~/.ssh/authorized_keys.pub
Debugging Connection Refused Errors
Check these:
- Is the port right in your command?
- Is UFW allowing it?
sudo ufw status - Is sshd running?
sudo systemctl status sshd - Use verbose mode:
ssh -vvv -p 54321 myuser@your_server_ip
What to Do When Keys Are Compromised
If you think your private key is stolen:
- Log in with a different key
- Remove the bad key from authorized_keys
- Generate a new key pair
- Check login logs for abuse
- Change any other passwords used on the VPS
FAQ: SSH Key Security for VPS
How Often Should I Rotate SSH Keys?
Every 90 days for personal VPS servers. Every 30 days for shared or high-risk projects. Rotation is a must in any SSH key security checklist.
Is Ed25519 Better than RSA for VPS?
Yes. Ed25519 is faster, smaller, and avoids some RSA math weaknesses. Pick Ed25519 unless a legacy system needs RSA.
Can I Use SSH Keys with Multiple VPS Providers?
Absolutely. The same public key can sit in the authorized_keys file on DigitalOcean, Linode, AWS, or any other VPS. Just keep the private key on your local machine.
What If I Lose My Private Key?
Use your encrypted backup on the USB or cloud drive. If you have no backup, you are locked out. Use the VPS provider’s web console to log in and add a new key, then delete the lost one.
Do I Need to Change SSH Port?
It is not a huge security win, but it blocks lazy botnet scans. A custom port + strong keys + Fail2ban is the best combo.
Final Verification Checklist and Next Steps
Here is your master SSH key security checklist for a new VPS. Tick each item off:
| # | Task | Status |
|---|---|---|
| 1 | Ed25519 key generated with passphrase | ☐ |
| 2 | Key backed up in two encrypted places | ☐ |
| 3 | Non-root user created on VPS | ☐ |
| 4 | Public key deployed and tested | ☐ |
| 5 | Password login disabled | ☐ |
| 6 | Root login over SSH disabled | ☐ |
| 7 | SSH port changed | ☐ |
| 8 | UFW firewall on, only needed ports open | ☐ |
| 9 | Fail2ban running on SSH port | ☐ |
| 10 | Calendar reminders set for 30- and 90-day reviews | ☐ |
Your next steps:
- Apply this SSH key security checklist to every VPS you own.
- Add two-factor authentication (2FA) on top of keys for extra safety.
- Read the man pages:
man sshandman sshd_config. - Join a community (like r/selfhosted) to learn more server tips.
A strong SSH key setup is the single best thing you can do for your new VPS. It beats passwords, beats hope, and beats luck. Follow this checklist. Stay safe. Happy hosting.