OpenClaw Linux VPS hardening 2026 | firewall, loopback Gateway, SSH vs HTTPS

Running OpenClaw Gateway on a Linux VPS is attractive until the first port scan hits your admin UI. The practical goal is a small, enumerable surface: default deny on the edge, the Gateway reachable only where you intend, and a clear choice between SSH tunnel management and a public HTTPS reverse proxy. Here is a reusable firewall baseline, loopback binding guidance, an SSH access pattern, and a matrix so you neither over-build on day one nor skip hardening later.

22 / 443

Typical public ports to justify

127.0.0.1

Preferred Gateway bind in lockdown mode

L0–L3

Tiered triage for support parity

Threat model in one paragraph

Assume credential stuffing on SSH, scraping of any HTTP listener, and supply-chain noise on install paths. The Gateway orchestrates tokens and sessions, so isolate it from unrelated daemons. Start from default deny inbound, then allow only SSH (key-only, optional IP allow-list) plus what you deliberately publish for assistants or webhooks.

Firewall template: default deny, explicit allow

With ufw or nftables, keep the same story: loopback open, established/related accepted, new inbound narrowed to SSH and (only if required) 80/443 for TLS. Mirror rules on IPv6 or consciously disable v6—do not leave it wide open by accident.

UFW-style baseline (adapt ports to your SSH)

# Reset only on a console session you trust
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH    # or: allow 22/tcp
# If terminating TLS on this box for OpenClaw:
# sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verbose

Provider security groups first

Cloud control-plane firewalls (security groups) should repeat the same story as OS firewalls. If both exist, keep them aligned so a mistaken UI toggle does not silently widen the VPS.

Gateway loopback binding

If no other host on a LAN must call the Gateway, bind to 127.0.0.1 (and the v6 loopback if enabled). That removes most “forgot to firewall high port” incidents. Add a local reverse proxy only when something on the same box must bridge protocols; otherwise use SSH port forwarding below for admin traffic.

Health checks and agents

If an external uptime checker must hit the Gateway, loopback-only mode is wrong for that path—use a split listener, mTLS on a private interface, or move checks to the process supervisor on the host instead of the public Internet.

SSH tunnel for management-plane access

For solo operators and small teams, ssh -L keeps much of the trust in keys and a browser you control. Example:

Local forward example (ports illustrative)

ssh -N -L 8443:127.0.0.1:18789 user@vps-hostname
# Then open https://127.0.0.1:8443 in the browser if TLS is local to the tunnel stack,
# or http://127.0.0.1:8443 if the Gateway is plain HTTP on loopback (prefer wrapping stunnel/wireguard for prod).

Harden SSH: keys only, tight AllowUsers, rate limits or fail2ban as needed; non-default SSH ports are hygiene, not policy. When the tunnel works but the Gateway does not, use 2026 OpenClaw Linux production troubleshooting: systemd, openclaw logs, gateway port probes — tiered FAQ for systemd and log triage.

Decision matrix: SSH loopback path vs public HTTPS reverse proxy

Use HTTPS when browsers, mobile networks, or webhooks need a stable public URL. Use SSH when only operators touch admin UI and you want fewer edge moving parts.

Dimension	SSH tunnel to loopback Gateway	Public HTTPS reverse proxy (Nginx/Caddy)
Audience	Admins with SSH keys	Browsers, apps, vendor webhooks
Exposure	SSH only (+ optional VPN)	443 (and often 80 for ACME)
TLS work	Can stay minimal if trust SSH transport	Certificates, renewal, cipher suites
Failure modes	NAT timeouts, broken ControlMaster	Mis-routed Host headers, stale upstream
Best when	Solo/small team, no public integrations	Shared assistants, strict SLO on availability

Progressive exposure

Ship day one with loopback + SSH. Promote to HTTPS only when a concrete integration needs a stable public URL; keep the old SSH path as break-glass access after cutover.

Tiered troubleshooting FAQ

Keep L0–L3 wording aligned with other OpenClaw runbooks so tickets stay comparable.

L0 — “Nothing listens”

Check the unit is active, then ss -lntp. If the Gateway is loopback-only, testing from another host is a false negative—retest via tunnel or on the VPS.

L1 — “SSH works, tunnel does not”

Look for local port collisions, odd localhost vs 127.0.0.1 IPv6 behavior, and curl -v from the VPS shell to the loopback target to split SSH from app faults.

L2 — “HTTPS path flaps after cert renew”

Inspect ACME mode (HTTP-01 vs DNS-01), proxy reload errors, and upstream keepalives; renewals should not bounce the Gateway unless automation coordinates health checks.

L3 — “Suspected compromise”

Export firewall state, rotate SSH keys and tokens, revoke webhooks, and rebuild from a known image instead of whack-a-mole on a live disk. Install-path questions belong with 2026 OpenClaw Linux cloud VPS hands-on: curl install vs Docker, environment checks, and common errors FAQ.