secure-linux-web-hosting

Secure Linux Web Hosting

Overview

Use this skill to turn a Linux cloud host into a safely reachable web host without leaning on stale distro-specific memory or outdated Debian-10-era tutorials.

This skill keeps the familiar teaching arc of a beginner-friendly server guide, but turns it into a reusable operator workflow:

• Intake and routing

• Prerequisites

• Secure access

• Firewall and exposure

• Web server setup

• Static site or app proxy

• HTTPS

• Validation

• Optional advanced tuning

Before giving actionable commands, identify the distro family and verify the current package names, service units, config paths, and ACME-client guidance against official documentation for the user's distro and chosen tools.

Open references/workflow-map.md first for the phase sequence, then open the narrower reference file you need.

When to Use

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

• a Linux VPS, VM, droplet, or cloud server they want to use for hosting

• connecting a domain or DNS A/AAAA record to a server

• SSH login, SSH hardening, root login, keys, ports, or firewall setup

• installing or configuring Nginx for a website

• serving a simple static site from Linux

• putting a small app behind Nginx as a reverse proxy

• HTTPS, Let's Encrypt, Certbot, acme.sh, certificate renewal, or redirecting HTTP to HTTPS

• optional post-setup performance or network tuning such as BBR

Do not use this skill for:

• Kubernetes, PaaS, or full container-orchestrator deployment design

• application-specific build or CI/CD questions where Linux hosting is not the actual problem

• Windows or macOS host administration

• public multi-tenant production architecture reviews that need a broader SRE or platform-design treatment

Workflow

1. Intake and classify the current state

Start by identifying:

• distro family or image name

• whether the user has root access, an admin user, or only one live SSH session

• whether DNS already points at the host

• whether the goal is a static site or an app reverse proxy

• whether ports are already exposed

• whether HTTPS is already partially configured

If the distro is unknown, ask for it or have the user inspect /etc/os-release before giving concrete package or service commands.

2. Verify current docs before actionable commands

Use bundled references for routing, then verify details against live official docs before giving commands that depend on current distro behavior.

Always verify:

• package manager commands and package names

• firewall tooling and service names

• SSH service unit names and config include paths

• Nginx package and config layout

• the chosen ACME client's current instructions

If you cannot verify a detail, say so and give high-level guidance instead of pretending the old Debian tutorial path is universal.

3. Keep the phases in order

Walk through the phases in this order unless the user is explicitly asking for review or remediation of an existing setup:

• prerequisites

• secure access

• firewall and exposure

• web server

• choose one hosting branch: static site or app proxy

• HTTPS

• validation

• optional advanced tuning

Do not collapse the static-site branch and reverse-proxy branch into one default answer. Pick the branch that matches the user's goal.

4. Enforce the safety gates

Treat these as hard stop checks:

• Do not recommend changing SSH port, disabling password auth, or disabling root SSH login until key-based login works in a second SSH session.

• Do not recommend certificate issuance until DNS resolves to the intended host and the HTTP site or proxy path works as expected.

• Do not force an HTTP-to-HTTPS redirect until HTTPS loads cleanly.

• Do not suggest BBR or similar tuning until secure hosting is already working.

Always distinguish:

• local-machine actions: SSH, DNS checks, browser tests

• server actions: package install, config edits, service reloads, firewall rules

Output Expectations

For a fresh setup, provide:

• a brief diagnosis of the current state

• the current phase and why it comes next

• local-machine steps separate from server steps

• concrete commands or config snippets only after doc verification

• a verification step after each risky change

• a short "if this fails, check X" branch for the likely mistake at that phase

For a hardening or troubleshooting review, provide:

• the most likely risk or breakage first

• a prioritized remediation sequence

• the first safe verification step before the next config change

Common Mistakes

• treating Debian-specific commands from an old article as Linux-universal

• hardening SSH in the only active session and locking the user out

• opening application ports directly instead of keeping the app on loopback

• mixing static-file hosting guidance and reverse-proxy guidance in one config

• attempting ACME issuance before DNS or HTTP is actually correct

• forcing redirects before HTTPS is proven

• treating BBR as part of the core setup instead of an optional later step

• ignoring SELinux or AppArmor differences when Nginx can read files on one distro but not another

Reference Usage

Use references/workflow-map.md for the phase map, branching logic, and validation order.

Use references/distro-routing.md when distro family, package manager, firewall tooling, or config layout matters.

Use references/nginx-patterns.md when the user needs the static-site branch or the reverse-proxy branch.

Use references/security-and-tls.md for SSH hardening sequence, firewall posture, certificate issuance, renewal, and redirect timing. Weekly Installs5.3KRepositoryxixu-me/skillsGitHub Stars1First SeenTodaySecurity AuditsGen Agent Trust HubPassSocketPassSnykWarnInstalled onopencode5.3Kdeepagents5.3Kantigravity5.3Kgithub-copilot5.3Kcodex5.3Kwarp5.3K