Zero-Public SSH: Hardening Cloud VPS Access with WireGuard Mesh Networks & UFW

Network Diagnostics: When deploying cloud nodes across different VPS providers, diagnose subtle routing and DNS anomalies with our deep dive on edge cases in cloud networking: IPv6 PTR mismatches and dual-stack routing.

The Perpetual Threat of Public Port 22 Exposure

Every cloud server provisioned with a public IPv4 or IPv6 address is subjected to automated internet-wide port scans within seconds of boot. Adversaries and automated botnets continuously probe port 22, executing credential-stuffing dictionaries, brute-forcing common usernames (root, ubuntu, admin), and searching for zero-day vulnerabilities in OpenSSH daemons (such as the recent regreSSHion race condition CVE-2024-6387).

While industry-standard countermeasures (such as disabling password authentication, using Ed25519 cryptographic keys, changing default SSH ports to non-standard ports like 2222, and installing Fail2ban) mitigate basic brute-force attacks, they still leave your SSH daemon exposed to the public internet. Authenticators must process invalid handshake attempts, system logs fill with thousands of failed authorization entries, and the server remains vulnerable to daemon-level vulnerabilities. The modern architectural standard is Zero-Public SSH.

1. Architecture: The WireGuard Mesh Ingress Model

A Zero-Public SSH architecture removes port 22 entirely from public internet routing by leveraging a point-to-point WireGuard mesh network:

1. Kernel-Level VPN Mesh: WireGuard operates inside the Linux kernel using modern, high-speed elliptic-curve cryptography (Curve25519 for key exchange, ChaCha20 for encryption, and Poly1305 for authentication). It creates an internal private virtual interface (e.g., wg0 on 10.10.0.1/24).
2. Cryptographic Stealth: Unlike OpenSSH which replies with protocol banners to incoming TCP SYN packets, WireGuard is completely silent. It does not respond to unauthenticated UDP packets, making the server appear completely dark (closed) to port scanners like Nmap or Masscan.
3. Local Interface Binding: OpenSSH daemon (sshd) is explicitly configured to listen solely on the internal WireGuard IP address (e.g., 10.10.0.1), ignoring all packets arriving on public WAN interfaces (eth0).
4. Strict Perimeter Firewall (UFW): The Uncomplicated Firewall (UFW) rejects or drops all inbound public traffic except for necessary web traffic (ports 80 and 443) and the single WireGuard UDP handshake port.

2. Comparing SSH Security Models

The operational and security differences across common cloud VPS access models are detailed below:

3. Step-by-Step Implementation Guide

Step A: Configure WireGuard on the Server

Generate cryptographic keys and establish the /etc/wireguard/wg0.conf configuration file:

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY_HERE
SaveConfig = false

# Authorized Administrator Workstation
[Peer]
PublicKey = ADMIN_LAPTOP_PUBLIC_KEY_HERE
AllowedIPs = 10.10.0.2/32

Enable and start the WireGuard service:

sudo systemctl enable wg-quick@wg0
sudo systemctl start wg-quick@wg0

Step B: Restrict OpenSSH to the WireGuard Virtual Interface

Edit /etc/ssh/sshd_config (or /etc/ssh/sshd_config.d/hardening.conf) to bind exclusively to the internal WireGuard IP:

# Bind SSH exclusively to the WireGuard VPN address
ListenAddress 10.10.0.1

# Enforce secure authentication policies
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3

Step C: Configure UFW Firewall Rules

Configure UFW to deny public SSH while allowing WireGuard and Web traffic:

# Set default incoming policy to DROP/REJECT
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow standard web traffic
sudo ufw allow 80/tcp comment "HTTP Web Traffic"
sudo ufw allow 443/tcp comment "HTTPS Web Traffic"

# Allow WireGuard UDP handshake port
sudo ufw allow 51820/udp comment "WireGuard VPN Ingress"

# Allow SSH strictly over the WireGuard interface (wg0)
sudo ufw allow in on wg0 to 10.10.0.1 port 22 proto tcp comment "Internal SSH over VPN"

# Reload firewall
sudo ufw enable

4. Emergency Out-of-Band Recovery Guardrails

Before applying strict firewall rules, always verify your cloud provider's out-of-band console access (e.g., AWS EC2 Serial Console, DigitalOcean Droplet Console, or Linode Lish). Furthermore, implement a temporary cron safety rollback when testing new rules:

# Emergency fallback cron (remove after successful verification)
echo "sudo ufw disable" | at now + 10 minutes

Key Architectural Takeaways

By binding OpenSSH exclusively to an internal WireGuard VPN interface and blocking public port 22 via UFW, you eliminate 100% of automated internet brute-force traffic. Your server becomes cryptographically invisible to port scanners, auth logs remain immaculate, and your infrastructure is thoroughly insulated against unauthenticated OpenSSH zero-day vulnerabilities.