SSH Key Authentication and Server Hardening

SSH password authentication is convenient, but it’s also the single most attacked surface on any internet-facing server. Bots try millions of password combinations per day against every public SSH port. Switching to SSH key authentication — and disabling password login entirely — eliminates the entire attack class. This guide walks through key generation, installation on iWebVault, and the additional hardening that should follow.

Why SSH keys are dramatically better than passwords

• No brute-force surface. Even a long password is technically guessable; a 4096-bit RSA key is not. The math is unforgiving.
• No password reuse risk. If a service you use gets breached and exposes your password, attackers may try that password on your SSH. With keys, there’s no password to leak.
• Convenient once set up. No typing passwords. Multiple servers, one key.
• Auditable. Each key has a fingerprint. You can revoke one key without changing anything else.

Generating a key pair

On your local computer (Mac, Linux, or Windows with WSL/Git Bash):

ssh-keygen -t ed25519 -C "your_email@example.com"

Why ed25519 (not RSA): smaller key files, faster, equally secure. Modern OpenSSH supports it universally.

The tool prompts:

• “Enter file in which to save the key” — press Enter to accept default (~/.ssh/id_ed25519).
• “Enter passphrase” — use a passphrase. This encrypts your private key — if your laptop is stolen, the thief can’t use the key without it. Use ssh-agent so you don’t have to type the passphrase every connection.

Two files are created:

• ~/.ssh/id_ed25519 — private key. Never share, never copy off the device.
• ~/.ssh/id_ed25519.pub — public key. Safe to share, this is what you put on servers.

Installing your key on cPanel (shared hosting)

1. Display your public key locally: cat ~/.ssh/id_ed25519.pub. Copy the entire output (starts with ssh-ed25519, ends with your email).
2. cPanel → Security → SSH Access.
3. Manage SSH Keys → Import Key.
4. Key Name: anything memorable (e.g. “MacBook 2026”).
5. Paste the entire public key content into the Public Key box.
6. Leave Private Key empty (you’re importing only the public side).
7. Click Import.
8. Back at SSH Access → Manage next to the new key → Authorize.

Test from your local terminal:

ssh -p 2222 yourcpaneluser@yourdomain.com

(iWebVault’s SSH port is 2222, not the default 22. Check the SSH Access page for the exact port if it differs.) You should connect without password prompt — only the key passphrase if you set one.

Installing your key on a VPS (root SSH)

For VPS customers with full root access:

1. SSH in with password initially: ssh root@your-vps-ip.
2. Create .ssh directory if missing: mkdir -p ~/.ssh && chmod 700 ~/.ssh.
3. Add your public key:

echo "ssh-ed25519 AAAAC3Nz...your-key... your_email@example.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Open a NEW terminal window (keep the original open as a safety net) and test: ssh root@your-vps-ip. Should log in via key.

If it works, you’re ready to disable password login.

Disabling SSH password login (VPS only)

Critical: only do this after verifying your key works. If you disable passwords before key auth is confirmed, you lock yourself out.

1. Edit /etc/ssh/sshd_config: nano /etc/ssh/sshd_config
2. Find PasswordAuthentication yes → change to PasswordAuthentication no
3. Find PermitRootLogin yes → change to PermitRootLogin prohibit-password (allows root via key, not password)
4. Save and exit (Ctrl+O, Ctrl+X in nano).
5. Reload SSH: systemctl reload sshd

Test from another window before closing your original session. If something’s broken, fix it via the still-open original session.

Additional SSH hardening

Change the SSH port (optional)

Reduces noise in logs from bots scanning port 22. Doesn’t add real security against targeted attackers (port scans find any port quickly) but cuts the brute-force attempts to almost zero.

In sshd_config: change Port 22 to Port 22222 (or any port 1024-65535). Don’t forget to open the new port in your firewall before reloading SSH, or you’ll be locked out.

Install fail2ban

Bans IPs after repeated failed login attempts. On a VPS:

apt install fail2ban
systemctl enable fail2ban
systemctl start fail2ban

(Default config is sane — bans after 5 failed attempts for 10 minutes. Adjust /etc/fail2ban/jail.local if you want longer bans or different thresholds.)

On shared hosting, fail2ban runs server-wide already — you don’t manage it personally.

Restrict by IP (if you have a static one)

In sshd_config, add:

AllowUsers root@1.2.3.4 root@1.2.3.5

Only those IPs can log in as root. Useful if you administer from one or two fixed locations. Not practical if you travel and need to admin from random networks.

Managing keys across devices

• One key per device, not one key shared across all your machines. Loss of one device → revoke one key, others still work.
• Name keys descriptively in the comment field: “MacBook Pro 2026”, “Home Desktop”, “Work Laptop”.
• Audit periodically. SSH Access page → list of authorized keys. Remove keys for devices you no longer use.
• Never email private keys. Never put them in cloud storage. They live on the device that generated them.

Common SSH issues

“Permission denied (publickey)”. Server requires keys but yours isn’t installed or isn’t authorized. On cPanel, check the key is shown and marked Authorized. On VPS, check ~/.ssh/authorized_keys on the server and its permissions (chmod 600).

“Permission denied (publickey,password)”. Server accepts either, but your key didn’t match. Check your local ~/.ssh/id_ed25519.pub against what’s on the server. Match must be exact.

“Wrong port” errors. iWebVault uses port 2222 on shared cPanel, not 22. Use -p 2222 in the SSH command.

“I’m locked out of my VPS.” Use the VPS provider’s web console (KVM/VNC) to log in directly, fix SSH config, restore access. Always test SSH key auth from a second terminal before closing your working session.

“Want to use the same key from multiple computers.” Don’t. Generate a key on each. Add all public keys to the server’s authorized_keys. Separation = better security.

What’s next

• Securing a freshly-provisioned VPS: VPS day-1 hardening.
• Firewall configuration: CSF brute-force protection.
• 2FA for client area: Two-factor authentication.

SSH key authentication is the lowest-effort, highest-impact security improvement on any internet-facing server. Spend twenty minutes once. Forget about brute-force attacks forever.