--- id: daily-secure-linux-web-hosting name: "secure-linux-web-hosting" url: https://skills.yangsir.net/skill/daily-secure-linux-web-hosting author: xixu-me domain: cloud-infra tags: ["security", "serverless", "infrastructure-as-code"] install_count: 155600 rating: 4.80 (1824 reviews) github: https://github.com/xixu-me/skills --- # secure-linux-web-hosting > 将Linux云主机安全配置为可访问的web主机，避免依赖过时的发行版特定教程 **Stats**: 155,600 installs · 4.8/5 (1824 reviews) ## Before / After 对比 ### 服务器安全配置 **Before**: 在网上搜索多个教程，拼接不同来源的配置命令，容易遗漏安全步骤或使用过时的Debian 10时代的方法 **After**: 遵循统一的安全配置流程，从防火墙到SSL证书一站式配置，确保服务器安全且符合当前最佳实践 | Metric | Before | After | Change | |---|---|---|---| | 配置时间 | 120分钟 | 30分钟 | -75% | ## Readme # 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`](https://github.com/xixu-me/skills/blob/HEAD/skills/secure-linux-web-hosting/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`](https://github.com/xixu-me/skills/blob/HEAD/skills/secure-linux-web-hosting/references/workflow-map.md) for the phase map, branching logic, and validation order. Use [`references/distro-routing.md`](https://github.com/xixu-me/skills/blob/HEAD/skills/secure-linux-web-hosting/references/distro-routing.md) when distro family, package manager, firewall tooling, or config layout matters. Use [`references/nginx-patterns.md`](https://github.com/xixu-me/skills/blob/HEAD/skills/secure-linux-web-hosting/references/nginx-patterns.md) when the user needs the static-site branch or the reverse-proxy branch. Use [`references/security-and-tls.md`](https://github.com/xixu-me/skills/blob/HEAD/skills/secure-linux-web-hosting/references/security-and-tls.md) for SSH hardening sequence, firewall posture, certificate issuance, renewal, and redirect timing. Weekly Installs5.3KRepository[xixu-me/skills](https://github.com/xixu-me/skills)GitHub Stars1First SeenTodaySecurity Audits[Gen Agent Trust HubPass](/xixu-me/skills/secure-linux-web-hosting/security/agent-trust-hub)[SocketPass](/xixu-me/skills/secure-linux-web-hosting/security/socket)[SnykWarn](/xixu-me/skills/secure-linux-web-hosting/security/snyk)Installed onopencode5.3Kdeepagents5.3Kantigravity5.3Kgithub-copilot5.3Kcodex5.3Kwarp5.3K --- *Source: https://skills.yangsir.net/skill/daily-secure-linux-web-hosting* *Markdown mirror: https://skills.yangsir.net/api/skill/daily-secure-linux-web-hosting/markdown*