SSD Nodes Learn
Guías Matt ConnorPor Matt Connor · Actualizado 2026-07-24

Cómo asegurar OpenClaw en un VPS

Evite riesgos de ejecución de shell con OpenClaw. Guía para configurar un usuario sin privilegios, firewall y systemd para mitigar fallos como CVE-2026-32922.

Qué es OpenClaw y por qué debe blindarse primero

OpenClaw es un agente de IA self-hosted. Se ejecuta en su propio servidor, se conecta a un modelo de lenguaje extenso y puede ejecutar comandos de shell, controlar un navegador, leer y escribir sus archivos, y actuar según los mensajes que se le envíen desde aplicaciones de chat. Ese alcance es el propósito de la herramienta, y también es su riesgo total. Un agente capaz de ejecutar cualquier comando es tan seguro como el equipo donde se ejecuta y los límites que se le impongan.

Dos hechos definen el enfoque de esta guía. Primero, OpenClaw está diseñado para ser blindado por el usuario. Su modelo de seguridad delega la responsabilidad de las políticas de herramientas, el sandboxing y los permisos estrictos al operador, no a una configuración segura por defecto. Segundo, el proyecto ya ha sufrido un incidente de seguridad grave: en marzo de 2026, se revelaron nueve vulnerabilidades en cuatro días, incluyendo un fallo crítico de escalada de privilegios, CVE-2026-32922, con una puntuación de 9.9 sobre 10. Ninguno de estos hechos significa que deba evitar OpenClaw. Significan que no debe ejecutarlo de forma descuidada, y esta guía es el método cuidadoso.

También hay buenas noticias. OpenClaw ya toma una decisión segura por usted: su gateway, el proceso único que lo controla todo, escucha en la dirección de loopback por defecto, por lo que no es accesible desde internet a menos que se exponga deliberadamente. La mayor parte del trabajo a continuación consiste en mantenerlo así y limitar el radio de explosión si algo falla.

Asigne a OpenClaw su propio usuario sin privilegios

Nunca ejecute un agente como root. Si OpenClaw se ejecuta como root y algo falla, ya sea un bug, una instrucción errónea o un CVE como el mencionado, el daño no tendrá límite. Cree un usuario de sistema dedicado sin shell de inicio de sesión y sin sudo, y ejecute el agente con ese usuario:

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

Todo lo que OpenClaw posee reside bajo /opt/openclaw, propiedad de esa cuenta. Este es el paso más importante y es el mismo principio tratado en ejecutar servicios como un usuario sin privilegios: la cuenta bajo la cual se ejecuta un agente es el límite de lo que puede romper.

Instalar OpenClaw

OpenClaw se distribuye como un paquete npm, así que instale Node.js primero si el servidor no lo tiene. Instale el paquete de forma global, lo que coloca el binario openclaw en el PATH para cada usuario, y luego ejecute el paso de configuración inicial:

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

Ejecutar la configuración inicial como el usuario openclaw significa que la configuración del agente se guardará en su directorio home, /opt/openclaw, y no en el de root. El proyecto también ofrece un instalador curl -fsSL https://openclaw.ai/install.sh | bash que realiza la misma instalación en una línea. Omita el flag --install-daemon durante la configuración inicial: este registraría el propio servicio de OpenClaw, y la unidad systemd blindada que construirá a continuación es más estricta.

Mantenga el gateway en loopback, detrás de un firewall

El gateway se vincula a 127.0.0.1 por defecto. Déjelo ahí. Casi nunca hay una razón para publicar ese puerto en internet; hacerlo otorga a cualquier persona que lo encuentre un punto de acceso remoto a un proceso que ejecuta comandos de forma continua.

Coloque un firewall de denegación por defecto delante del equipo para que nada se exponga accidentalmente:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Dos trampas que debe evitar aquí. Un firewall que solo cubra IPv4 puede dejar el mismo servicio totalmente abierto en IPv6, que es exactamente el vacío de firewall IPv6 que afecta a tantas personas. Y si necesita acceder al gateway desde su portátil, no abra el puerto. Acceda mediante una VPN o un túnel SSH, para que el agente nunca esté escuchando en internet abierto.

Aísle sus secretos

OpenClaw necesita una API key para el modelo de lenguaje al que se conecte. Esa clave puede gastar su dinero y, a través del agente, actuar en su nombre, así que trátela como una contraseña. Manténgala fuera del archivo de la unidad y fuera de cualquier repositorio. Colóquela en un archivo que solo el usuario OpenClaw pueda leer:

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

La unidad systemd carga ese archivo con EnvironmentFile, de modo que la clave llega al proceso sin estar nunca en una línea de comandos, un log o su historial de shell.

Ejecútelo como un servicio systemd blindado

Ejecutar el agente bajo systemd le proporciona reinicios automáticos, logs limpios mediante journalctl y, lo más importante, un conjunto de opciones de sandboxing a nivel de kernel que reducen lo que el proceso puede tocar incluso si se ve comprometido. Las más importantes para un agente son NoNewPrivileges para que nunca pueda obtener nuevos poderes, ProtectSystem=strict para que el sistema de archivos sea de solo lectura excepto donde permita escrituras, PrivateTmp para su propio directorio temporal aislado, y ProtectHome para que no pueda leer los directorios home.

Genere una unidad completa y blindada aquí, y luego cópiela a /etc/systemd/system/openclaw.service:

ToolGenerate a hardened systemd unit for the agent

La unidad inicia openclaw gateway, el proceso de larga duración que controla al agente; si which openclaw muestra una ruta distinta en su servidor, ajuste ExecStart para que coincida. El recorrido completo de estas directivas, y de daemon-reload y enable --now, se encuentra en ejecutar un programa como un servicio systemd. La versión corta una vez haya pegado la unidad:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

Blinde también la puerta principal

Un equipo de agente es tan seguro como el servidor que lo rodea. Otras dos capas completan el trabajo. Mueva SSH a autenticación solo por clave y desactive el login de root, como en blindaje de SSH en un VPS, para que la cuenta desde la que administra el equipo no pueda ser atacada por fuerza bruta. Luego añada Fail2ban para expulsar a los scanners que atacan cada puerto público. Ninguno toca OpenClaw directamente, pero ambos cortan las rutas que un atacante usaría para alcanzarlo.

Manténgalo actualizado, deliberadamente

Las revelaciones de marzo de 2026 son el argumento más claro para mantenerse al día. Un bug de escalada de privilegios en un agente es mucho más serio que en una aplicación web ordinaria, porque el agente ya ejecuta comandos. Vigile los lanzamientos del proyecto, aplique las actualizaciones de seguridad rápidamente y trate la actualización de OpenClaw como un mantenimiento rutinario en lugar de algo que posponer.

Para entender qué está blindando realmente, la arquitectura de un agente estilo OpenClaw analiza las partes móviles, y construir su propio agente de IA en un VPS cubre la estructura general que adopta cualquier agente.

FAQ

¿Es seguro ejecutar OpenClaw en un VPS público?

Puede serlo, si lo blinda. OpenClaw es potente por diseño: ejecuta comandos de shell y controla un navegador, por lo que una configuración descuidada es realmente peligrosa, y el proyecto ya ha tenido un CVE crítico (CVE-2026-32922 en marzo de 2026). Su modelo de seguridad espera que usted, el operador, añada los límites. Ejecútelo como un usuario sin privilegios, mantenga su gateway en loopback detrás de un firewall de denegación por defecto, aísle sus API keys y ejecútelo como un servicio systemd blindado.

¿Debo exponer el gateway de OpenClaw a internet?

No. El gateway se vincula a loopback por defecto y debe dejarlo ahí. Es el proceso único que controla al agente, por lo que un gateway expuesto es una ruta remota hacia algo que ejecuta comandos de forma continua. Si necesita acceder de forma remota, utilice una VPN o un túnel SSH en lugar de abrir el puerto.

¿Con qué usuario debe ejecutarse OpenClaw?

Con un usuario de sistema dedicado sin shell de inicio de sesión y sin sudo, nunca como root. Si el agente se ve comprometido, su cuenta de usuario es el límite del daño, por lo que esa cuenta solo debe poseer sus propios archivos bajo un directorio como /opt/openclaw y nada más.

¿Cómo mantengo seguras las API keys de OpenClaw?

Guárdelas en un archivo legible solo por el usuario OpenClaw (modo 600) y cárguelo en el servicio con el comando EnvironmentFile de systemd. Mantenga la clave fuera del archivo de la unidad, fuera de su historial de shell y fuera de cualquier repositorio git. Rótela si sospecha que se ha filtrado.