openclaw-secure-linux-cloud

SKILL.md

Overview

Use this skill for the conservative "deploy first, expose later" pattern for
OpenClaw on a cloud server.

Default to a private control plane:

Harden the Linux host before exposing anything.

Keep the gateway bound to 127.0.0.1.

Reach the Control UI through an SSH tunnel first.

Keep token authentication, pairing, and sandboxing enabled.

Start with a narrow tool profile and loosen only with an explicit need.

This skill is for secure Linux cloud hosting. If the user only wants the
fastest generic OpenClaw install on a local machine, prefer the official
OpenClaw onboarding docs instead of forcing this flow.

Open references/REFERENCE.md when you need the
command matrix, baseline config shape, checklist, or access-path comparison.
When To Use

Use this skill when the user mentions any of the following:

OpenClaw on a cloud server, VM, or other Linux host

Secure self-hosting, hardening, or "run it privately"

Podman, loopback binding, SSH tunneling, or remote Control UI access

Tailscale vs reverse proxy for OpenClaw

Pairing, sandboxing, token auth, or locked-down tool permissions

Reviewing whether an existing OpenClaw host is too exposed

Do not use this skill for:

General Linux hardening with no OpenClaw component

Local single-machine onboarding where remote access is irrelevant

Pure local onboarding with no remote-host hardening questions

Non-Linux hosting unless the user explicitly wants this Linux-first pattern
adapted

Workflow

1. Classify the request

Put the task in one of these buckets before giving detailed guidance:

Fresh deploy: the user wants to stand up OpenClaw securely on a Linux
cloud host from scratch.

Hardening review: the user already has OpenClaw running and wants to
reduce exposure or audit risky defaults.

Access-model decision: the user is choosing between SSH tunneling,
Tailscale, or a reverse proxy.

2. Start from the secure baseline

Unless the user clearly asks for something else, recommend this baseline:

Harden the Linux host first: updates, SSH keys, SSH lock-down, and a
default-deny inbound firewall matched to the distro.

Run OpenClaw under rootless Podman rather than as a root-owned long-lived
process.

Keep the gateway on loopback only.

Keep the Control UI private and access it through an SSH tunnel.

Require token authentication.

Keep pairing enabled for inbound messaging channels.

Start with a minimal tool set and sandbox sessions by default.

Treat these as explicit red flags:

Binding the gateway to 0.0.0.0

Opening port 18789 to the public internet

Turning on broad runtime, filesystem, automation, or browser access by
default

Leaving ~/.openclaw readable by other local users

3. Separate local and server actions

Always distinguish between:

Local machine actions: SSH key generation, tunnel setup, browser access

Server actions: Linux hardening, Podman install path, OpenClaw service
setup, config permissions, service restarts

Do not blur the two execution contexts together. The user should be able to
tell which commands run on their laptop and which run on the Linux host.

4. Ask only for blocking facts

Only stop for missing facts that change the safe path, such as:

Linux distro and host access details when package-manager or firewall
commands matter

Whether OpenClaw is already installed

Whether the user truly needs repeated remote private access or public access

Whether an existing deployment is already reachable from the internet

If a detail is not safety-critical, make the reasonable secure assumption and
state it.

5. Use the access escalation ladder

Recommend remote access in this order:

SSH tunnel: default for first deployment and personal use

Tailscale: next step when the user needs repeated private access across
trusted devices

Reverse proxy: only when the user explicitly needs public exposure and
accepts the extra hardening burden

If the user asks for Tailscale or reverse proxy, still explain why the loopback
binding and private-first model remain the baseline.

Output Expectations

For a fresh deployment, provide:

A short architecture summary

Local-vs-server steps

A conservative config baseline

A pre-launch checklist

A short "what not to expose" warning

For a hardening review, provide:

The likely risks in the current setup

A prioritized remediation sequence

Any immediate exposure concerns to fix before anything else

For an access-path decision, provide:

A recommendation

Why it is the lowest-risk fit

What extra safeguards are required if the user chooses a broader exposure
model

Common Mistakes

Treating OpenClaw like a normal public web app on day one

Assuming auth alone replaces network boundaries

Turning on more tool power before the user has a clear workflow that needs it

Disabling pairing just to save time during early setup

Skipping follow-up audits after changing config or sandbox settings

Reference Usage

Use references/REFERENCE.md when you need:

The cross-distro hardening flow and Debian/Ubuntu example commands

The Podman-based OpenClaw setup outline

The baseline config skeleton

The pre-launch checklist

The day-to-day audit commands

The SSH tunnel vs Tailscale vs reverse-proxy comparison