Connecting and Configuring SSH on a VPS: The Complete Security Guide

Secure shell (SSH) access is the cornerstone of professional server management. Whether you're deploying a WordPress site, pushing code via Git, or administering custom applications, SSH gives you an encrypted, authenticated tunnel directly into your server. This comprehensive guide walks you through every step — from your first connection to hardening your setup against real-world attacks — so you can manage your VPS Hosting environment with confidence.

Why SSH Security Matters

Every publicly accessible server faces a constant barrage of automated brute-force attempts. Within minutes of a VPS going live, bots begin scanning port 22 and trying common username/password combinations. A poorly secured SSH configuration is one of the most common entry points for attackers.

The good news: a few deliberate configuration changes dramatically reduce your attack surface. Combined with reliable infrastructure — such as NVMe-backed storage and built-in DDoS protection — a properly hardened SSH setup gives you a fast, resilient, and genuinely secure management channel.

If you haven't yet chosen a hosting environment, consider exploring VPS Hosting plans that include full root access, dedicated resources, and the flexibility to implement every security measure covered in this guide.

Prerequisites

Before you begin, confirm you have the following in place:

> Tip: If you're managing multiple servers or need a graphical interface alongside SSH, check out VPS Control Panels for options like cPanel, Plesk, and DirectAdmin that complement command-line access.

Connecting to Your VPS via SSH

On Linux or macOS

Open your terminal and run:

ssh username@your_server_ip

Replace username with your actual username (commonly root for a fresh VPS) and your_server_ip with your server's public IP address.

Example:

ssh root@203.0.113.45

First-time connection prompt:

The authenticity of host '203.0.113.45 (203.0.113.45)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Type yes and press Enter. This adds the server's host key to your ~/.ssh/known_hosts file. On subsequent connections, SSH will verify this fingerprint automatically — if it ever changes unexpectedly, treat it as a potential security incident.

Enter your password when prompted.

On Windows Using PuTTY

1. Download and open PuTTY from putty.org.
2. In the Host Name (or IP address) field, enter your server's IP address.
3. Confirm Port is set to 22 and Connection type is SSH.
4. Click Open.
5. Accept the host key fingerprint when prompted.
6. Enter your username and password.

> Windows 10/11 alternative: Windows Terminal and PowerShell both include a native OpenSSH client. You can use the exact same ssh username@your_server_ip syntax as Linux/macOS — no third-party tools required.

Hardening SSH: Step-by-Step Configuration

All SSH behavior is controlled by a single configuration file:

/etc/ssh/sshd_config

Open it with elevated privileges:

sudo nano /etc/ssh/sshd_config

Work through each hardening step below. After making all changes, you will restart the service once — covered in the next section.

Step 1: Change the Default SSH Port

Port 22 is the first port bots scan. Moving SSH to a non-standard port eliminates the vast majority of automated noise in your logs.

Locate this line:

#Port 22

Change it to a port of your choice (use a number between 1024 and 65535 that isn't used by another service):

Port 2222

Remove the # to uncomment the line. Save with CTRL+X, then Y, then Enter.

> Important: Before restarting SSH, ensure your firewall allows the new port. See the firewall note below.

Update your firewall (UFW example):

sudo ufw allow 2222/tcp
sudo ufw deny 22/tcp
sudo ufw reload

Update your firewall (firewalld example):

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

Step 2: Disable Root Login

Allowing direct root login over SSH is a significant security risk. Instead, log in as a regular user and escalate privileges with sudo when needed.

In sshd_config, find:

PermitRootLogin yes

Change it to:

PermitRootLogin no

Before disabling root login, make sure you have a non-root user with sudo privileges:

# Create a new user
adduser adminuser

# Grant sudo privileges
usermod -aG sudo adminuser

Test that this user can log in and run sudo commands *before* you disable root login and restart SSH.

Step 3: Disable Password Authentication (After Setting Up Keys)

Once SSH key authentication is configured (next section), disable password-based login entirely to eliminate brute-force risk:

PasswordAuthentication no

Also ensure these related directives are set:

ChallengeResponseAuthentication no
UsePAM no

Step 4: Additional Recommended Directives

Add or verify these settings in sshd_config for a comprehensive hardening baseline:

# Limit authentication attempts per connection
MaxAuthTries 3

# Disconnect idle sessions after 5 minutes
ClientAliveInterval 300
ClientAliveCountMax 2

# Disable empty passwords
PermitEmptyPasswords no

# Restrict SSH to specific users (replace 'adminuser' with your username)
AllowUsers adminuser

# Use only strong protocol version
Protocol 2

# Disable X11 forwarding if not needed
X11Forwarding no

Setting Up SSH Key Authentication

SSH key authentication replaces passwords with a cryptographic key pair: a private key that stays on your local machine and a public key that lives on the server. Even if an attacker knows your username, they cannot authenticate without your private key.

Step 1: Generate an SSH Key Pair (on Your Local Machine)

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

> Why Ed25519? It's faster and more secure than the older RSA algorithm. If your system requires RSA for compatibility, use ssh-keygen -t rsa -b 4096 instead.

You'll be prompted to choose a save location (default ~/.ssh/id_ed25519 is fine) and set a passphrase. Always set a passphrase — it encrypts your private key so that physical access to your machine doesn't automatically compromise your servers.

Output:

Your identification has been saved in /home/you/.ssh/id_ed25519
Your public key has been saved in /home/you/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx your_email@example.com

Step 2: Copy the Public Key to Your VPS

The easiest method uses ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@your_server_ip

This command:

1. Connects to your server using password authentication.
2. Creates ~/.ssh/authorized_keys on the server if it doesn't exist.
3. Appends your public key to that file.
4. Sets correct permissions automatically.

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

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

# On your server, add it manually
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "paste-your-public-key-here" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Step 3: Verify Key-Based Login Before Disabling Passwords

Do not disable password authentication until you have confirmed key-based login works. Open a new terminal window and test:

ssh -i ~/.ssh/id_ed25519 username@your_server_ip -p 2222

If you connect successfully without being asked for a password (only your key passphrase, if set), proceed to disable PasswordAuthentication in sshd_config.

Restarting and Verifying the SSH Service

After saving all changes to sshd_config, validate the configuration syntax before restarting:

sudo sshd -t

If no errors are returned, restart the SSH daemon:

sudo systemctl restart sshd

Check that the service started successfully:

sudo systemctl status sshd

You should see Active: active (running) in the output.

> Critical safety tip: Keep your current SSH session open while testing the new configuration in a separate window. If something goes wrong, your existing session remains active and you can revert the changes.

Testing Your Secure Configuration

Test 1: Connect on the New Port with Your Key

From your local machine:

ssh username@your_server_ip -p 2222

Expected result: You are logged in using your SSH key (prompted for your key passphrase if you set one, but not your server password).

Test 2: Confirm Root Login Is Blocked

ssh root@your_server_ip -p 2222

Expected result:

Permission denied (publickey).

or

root@your_server_ip: Permission denied

Test 3: Confirm Password Authentication Is Disabled

ssh username@your_server_ip -p 2222 -o PubkeyAuthentication=no

Expected result:

Permission denied (publickey).

If password authentication were still enabled, you'd be prompted for a password instead.

Additional Hardening: Fail2Ban

Fail2Ban monitors log files and automatically bans IP addresses that show signs of malicious activity — such as repeated failed SSH login attempts. It's an essential complement to the SSH hardening steps above.

Install Fail2Ban

Ubuntu/Debian:

sudo apt update && sudo apt install fail2ban -y

CentOS/AlmaLinux/RHEL:

sudo dnf install epel-release -y
sudo dnf install fail2ban -y

Configure Fail2Ban for SSH

Create a local override file (never edit the default jail.conf directly):

sudo nano /etc/fail2ban/jail.local

Add the following:

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5

[sshd]
enabled  = true
port     = 2222
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s

Adjust port to match your custom SSH port. Save, then enable and start Fail2Ban:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Check active bans and jail status:

sudo fail2ban-client status sshd

Backing Up Your SSH Keys and Configuration

A locked-out server is a serious problem. Follow these practices to avoid it:

• Back up your private key to an encrypted password manager or offline storage.
• Store a copy of sshd_config before making changes: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
• Use your hosting provider's out-of-band console (VNC/KVM access via the control panel) as a fallback if you lose SSH access.
• Document your custom port — it's easy to forget 2222 when you're switching between servers.

Pairing SSH with the Right Hosting Infrastructure

A secure SSH configuration is only as strong as the infrastructure beneath it. Consider these complementary services:

• Dedicated Servers — For workloads requiring maximum performance and complete hardware isolation, dedicated servers give you full control over both the physical and software layers, including SSH configuration.
• SSL Certificates — Secure the web-facing side of your applications with trusted SSL/TLS certificates, complementing SSH security for your server's backend.
• Domain Registration — Register and manage your domain alongside your hosting, making it easier to configure DNS-based access controls and server hostnames.

Conclusion

A properly configured SSH setup is one of the highest-impact security improvements you can make to any Linux server. To summarize what you've implemented:

These measures work together to create a layered defense — each one meaningful on its own, and significantly stronger in combination.

Whether you're running a single WordPress site or managing a fleet of application servers, starting with a hardened SSH configuration puts you in control. Pair it with reliable VPS Hosting infrastructure, keep your keys backed up, and you'll have a secure, professional server environment built to last.