Comment sécuriser OpenClaw sur un VPS

Ce qu’est OpenClaw et pourquoi il faut d’abord le renforcer

OpenClaw est un agent IA auto-hébergé. Vous l’exécutez sur votre propre serveur, vous le connectez à un grand modèle de langage, puis il peut exécuter des commandes shell, contrôler un navigateur, lire et écrire vos fichiers et traiter les messages que vous lui envoyez depuis des applications de chat. Cette capacité d’action est précisément l’objectif de l’outil, mais aussi son principal risque. Un agent capable d’exécuter n’importe quelle commande est aussi sûr que le serveur qui l’exécute et que les limites que vous lui imposez.

Deux faits donnent le ton à ce guide. Premièrement, OpenClaw est conçu pour être renforcé par vos soins. Son modèle de sécurité vous confie la responsabilité de définir des règles strictes pour les outils, le sandboxing et les permissions, au lieu de fournir une configuration par défaut sûre. Deuxièmement, le projet a déjà connu un incident de sécurité grave : en mars 2026, neuf problèmes de sécurité ont été divulgués en quatre jours, dont une faille critique d’élévation de privilèges, CVE-2026-32922, notée 9.9 sur 10. Aucun de ces faits ne signifie que vous devez éviter OpenClaw. Ils signifient que vous ne devez pas l’exécuter avec une configuration négligée. Ce guide présente la méthode prudente. Cette méthode consiste notamment à décider à l’avance de ce que l’agent peut faire sans demander confirmation. C’est un choix que Claude Code rend explicite avec ses modes de permission. Un serveur devant lequel vous n’êtes pas assis doit avoir une configuration plus restrictive que l’ordinateur portable que vous surveillez.

Il y a aussi une bonne nouvelle. OpenClaw fait déjà un choix sûr pour vous : sa gateway, l’unique processus qui contrôle l’ensemble du système, écoute par défaut sur l’adresse loopback. Elle n’est donc pas accessible depuis Internet, sauf si vous choisissez délibérément de l’exposer. La plupart des opérations ci-dessous consistent à conserver ce comportement et à limiter l’impact en cas de problème.

Donnez à OpenClaw son propre utilisateur sans privilèges

N’exécutez jamais un agent en tant que root. Si OpenClaw s’exécute en tant que root et qu’un problème survient, qu’il s’agisse d’un bug, d’une instruction incorrecte ou d’une CVE comme celle mentionnée plus haut, les dégâts sont sans limite. Créez un utilisateur système dédié, sans shell de connexion et sans sudo, puis exécutez l’agent avec ce compte :

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

Tout ce qui appartient à OpenClaw se trouve sous /opt/openclaw et appartient à ce compte. C’est l’étape la plus importante. C’est le même principe que celui présenté dans exécuter les services avec un utilisateur sans privilèges : le compte avec lequel un agent s’exécute définit la limite de ce qu’il peut compromettre.

Installer OpenClaw

OpenClaw est distribué sous forme de package npm. Installez donc d’abord Node.js si le serveur ne l’a pas. Installez le package globalement. Le binaire openclaw sera ainsi disponible dans le PATH de tous les utilisateurs. Exécutez ensuite l’étape d’initialisation unique :

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

L’exécution de l’initialisation avec l’utilisateur openclaw place la configuration de l’agent dans son répertoire personnel, /opt/openclaw, et non dans celui de root. Le projet propose également un installateur curl -fsSL https://openclaw.ai/install.sh | bash qui effectue la même installation en une seule ligne. N’utilisez pas l’option --install-daemon pendant l’initialisation : elle enregistrerait le propre service d’OpenClaw, alors que l’unité systemd durcie que vous créez ci-dessous est plus stricte.

Conservez la passerelle sur loopback, derrière un pare-feu

La passerelle est liée à 127.0.0.1 par défaut. Laissez-la ainsi. Il n’y a presque jamais de raison d’exposer ce port sur Internet. Cela donnerait à toute personne qui le découvre un point d’accès distant vers un processus qui exécute des commandes.

Placez un pare-feu en refus par défaut devant le serveur afin que rien ne soit exposé par erreur :

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

Deux pièges sont à éviter. Un pare-feu qui ne couvre qu’IPv4 peut laisser le même service entièrement ouvert sur IPv6. C’est précisément la faille du pare-feu IPv6 qui piège tant d’administrateurs. Si vous devez accéder à la passerelle depuis votre ordinateur portable, n’ouvrez pas le port. Utilisez un VPN ou un tunnel SSH. L’agent ne sera ainsi jamais à l’écoute sur Internet.

Isoler ses secrets

OpenClaw a besoin d’une clé d’API pour le modèle de langage auquel vous le connectez. Cette clé peut dépenser votre argent et, par l’intermédiaire de l’agent, agir en votre nom. Traitez-la donc comme un mot de passe. Ne la placez ni dans le fichier d’unité ni dans un dépôt. Stockez-la dans un fichier que seul l’utilisateur OpenClaw peut lire :

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

L’unité systemd charge ce fichier avec EnvironmentFile. La clé est ainsi transmise au processus sans apparaître dans une ligne de commande, un journal ou l’historique de votre shell. Cette méthode s’applique à tous les secrets du serveur : renforcer un Vaultwarden auto-hébergé consiste à protéger son jeton d’administration et son fichier de sauvegarde, plutôt que son chiffrement, car ce sont les permissions des fichiers qui déterminent réellement qui peut lire un secret au repos.

Exécuter l’agent comme un service systemd renforcé

Exécuter l’agent sous systemd permet de redémarrer automatiquement le service et de centraliser proprement les journaux avec journalctl. Surtout, systemd fournit des options de mise en bac à sable au niveau du noyau. Elles limitent ce que le processus peut utiliser, même si le serveur est compromis. Pour un agent, les options les plus importantes sont NoNewPrivileges, afin qu’il ne puisse jamais obtenir de nouvelles capacités, ProtectSystem=strict, afin que le système de fichiers soit en lecture seule, sauf aux emplacements où les écritures sont autorisées, PrivateTmp, afin de lui fournir son propre répertoire temporaire isolé, et ProtectHome, afin de lui interdire la lecture des répertoires personnels.

Générez ici une unité complète et renforcée, puis copiez-la dans /etc/systemd/system/openclaw.service :

L’unité démarre openclaw gateway, le processus long terme qui contrôle l’agent. Si which openclaw affiche un chemin différent sur votre serveur, adaptez ExecStart en conséquence. La procédure complète consacrée à ces directives, ainsi qu’à daemon-reload et enable --now, figure dans exécuter un programme comme service systemd. Voici la version courte une fois l’unité collée :

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

Renforcez également le point d’entrée

La sécurité d’un agent dépend de celle du serveur qui l’héberge. Deux couches supplémentaires permettent de finaliser le dispositif. Configurez SSH pour n’autoriser que l’authentification par clé et désactivez la connexion root, comme dans Renforcement de SSH sur un VPS, afin d’empêcher le brute force du compte utilisé pour administrer le serveur. Ajoutez ensuite Fail2ban pour bloquer les scanners qui martèlent tous les ports publics. Ces deux mesures ne modifient pas directement OpenClaw, mais elles coupent les voies qu’un attaquant utiliserait pour l’atteindre.

Mettez-le à jour volontairement

Les divulgations de mars 2026 sont l’argument le plus clair pour rester à jour. Une faille d’élévation de privilèges dans un agent est bien plus grave que dans une application web ordinaire, car l’agent exécute déjà des commandes. Surveillez les releases du projet, appliquez rapidement les mises à jour de sécurité et considérez une mise à niveau d’OpenClaw comme une opération de maintenance courante, plutôt que comme une tâche à repousser.

Pour comprendre ce que vous sécurisez réellement, l’architecture d’un agent de type OpenClaw présente les différents composants. Créer votre propre agent IA sur un VPS décrit la structure générale de tout agent. Si vous exécutez un deuxième agent à ses côtés, souvenez-vous que deux sessions Claude Code sur un même VPS peuvent se transmettre du travail. Chacun doit donc avoir son propre compte et ses propres limites, au lieu d’hériter des vôtres.

FAQ

Est-il sûr d’exécuter OpenClaw sur un VPS public ?

Oui, à condition de le renforcer. OpenClaw est puissant par conception : il exécute des commandes shell et contrôle un navigateur. Une configuration négligée est donc réellement dangereuse. Le projet a déjà fait l’objet d’une CVE critique (CVE-2026-32922 en mars 2026). Son modèle de sécurité suppose que vous ajoutiez vous-même les limites nécessaires. Exécutez-le avec un utilisateur non privilégié, gardez sa gateway sur la loopback derrière un pare-feu en refus par défaut, isolez ses clés API et exécutez-le comme un service systemd renforcé.

Dois-je exposer la gateway OpenClaw sur Internet ?

Non. La gateway se lie à la loopback par défaut et vous devez la laisser ainsi. Il s’agit du processus unique qui contrôle l’agent. Une gateway exposée fournit donc un accès distant à un composant qui exécute des commandes. Si vous devez y accéder à distance, utilisez plutôt un VPN ou un tunnel SSH que l’ouverture du port.

Avec quel utilisateur OpenClaw doit-il s’exécuter ?

Avec un utilisateur système dédié, sans shell de connexion et sans sudo, jamais avec root. Si l’agent est compromis, son compte utilisateur limite l’ampleur des dommages. Ce compte doit donc être propriétaire uniquement de ses propres fichiers, dans un répertoire tel que /opt/openclaw, et de rien d’autre.

Comment sécuriser les clés API d’OpenClaw ?

Stockez-les dans un fichier lisible uniquement par l’utilisateur OpenClaw (mode 600) et chargez-les dans le service avec EnvironmentFile de systemd. Ne mettez pas la clé dans le fichier d’unité, dans l’historique de votre shell ni dans un dépôt git. Faites-la tourner si vous pensez qu’elle a été divulguée.