OpenClaw 2.0 sur un VPS est-il sûr ? Contrôle 7 jours : permissions, SSH, clés API

Installer OpenClaw 2.0 sur un VPS Linux est la partie facile. Un Gateway qui répond au chat n’est pas une machine qu’on laisse seule une semaine. L’install hôte est prudente : bind loopback, codes de pairing pour les DM inconnus, groupes qui n’agissent que sur mention. Ce qui reste ouvert le septième jour, c’est le trio que l’installateur ne resserre pas : sandbox éteint, outils de session qui voient tout le Gateway, clés API modèle qui peuvent encore dormir dans des fichiers lisibles par l’agent.

Nous avons tenu la même box Ubuntu sept jours, un seul opérateur, API distante, un canal Telegram. Un métier par jour : permissions, SSH et écoute, clés API, navigateur, isolation des agents. Verdict : on peut le laisser tourner dans un seul domaine de confiance. Ce n’est pas une frontière multi-locataires. La doc officielle le dit dès le premier écran. Le dimensionnement est dans les notes OpenClaw 2.0 sur CPU, RAM et disque ; ici on demande seulement quelles portes étaient encore ouvertes après une semaine.

Réponse courte : sûr, sous contrat

OpenClaw traite un Gateway comme une frontière de confiance — un opérateur, ou une petite équipe qui se fait déjà confiance. Des utilisateurs hostiles, des clients distincts, des lignes métier distinctes exigent leur propre Gateway et leurs propres identifiants, idéalement leur propre utilisateur OS ou leur propre hôte. C’est le modèle des docs sécurité du Gateway OpenClaw, pas une formule de blog. Noté comme SaaS multi-locataires, presque chaque défaut échoue. Noté comme « ma machine de garde », la plupart tiennent.

Nous avons relancé openclaw security audit chaque jour. Le jour un n’était pas un port nu — une install hôte reste en loopback, donc 18789 n’apparaît pas à un scan public. Les findings bruyants étaient l’exécution d’outils sur l’hôte et la visibilité des sessions à l’échelle du Gateway. On laisse ça, on ajoute un skill navigateur et une persona « famille en lecture seule », et le rayon d’explosion passe de « cette VM » à « chaque transcript et chaque secret de cette VM ».

Sept jours sans prendre « aucun incident » pour une réussite

La box : 2 vCPU / 8 Go Ubuntu 24.04, install.sh natif, API distante, unité systemd utilisateur. SSH en clés seulement, login mot de passe coupé. Le Gateway est resté en bind: loopback ; on atteignait la Control UI par un forward SSH local et on n’a jamais ouvert 18789 dans le security group cloud. Telegram est resté en pairing. On a laissé le sandbox Docker volontairement éteint, pour que le jour sept montre la vraie posture par défaut.

Trois artefacts chaque matin : openclaw security audit --json, ss -lntp confronté au pare-feu du fournisseur, et un balayage des permissions plus des clés en clair sous ~/.openclaw. On n’a pas noté « une injection de prompt a-t-elle réussi ». On a noté la dérive de config et les fichiers que l’agent (ou nous) avait laissés lisibles par tout le monde.

Contrôle 1 : permissions — l’exec atterrit encore sur l’hôte

Le sandbox d’OpenClaw 2.0 est optionnel. Le Gateway reste toujours sur l’hôte ; les outils ne passent dans Docker ou Podman qu’après agents.defaults.sandbox. Éteint, host=auto retombe sur la machine gateway. Agréable pour un assistant personnel de confiance. Pour un bot de garde qui verra liens, transferts et pièces jointes, ça câble l’injection de prompt jusqu’au shell de l’utilisateur de déploiement.

L’audit du jour un a tenu deux notes : un rayon d’outils trop large, et security="full" — le défaut documenté pour l’opérateur de confiance, pas un CVE. Notre coupe : l’agent personnel peut garder l’exec hôte si le pairing est on, si les outils fichiers restent au workspace, et si tools.elevated est off. Un second agent face à la famille ou à un salon public doit avoir sandbox.mode: "all", workspace ro ou none, et refuser exec, browser, gateway et cron.

Les modes de répertoires dérivent plus vite qu’on ne croit. Un scp depuis un portable, un volume Docker, ou l’agent qui copie openclaw.json transforment 600/700 en 644/755. openclaw security audit --fix resserre les modes d’état et de config. Il n’allume pas le sandbox. Faites tourner le Gateway sous son propre utilisateur Linux pour que clés, store de sessions et workspace vivent dans ce home, pas sous ubuntu ou root.

Contrôle 2 : SSH et bind — le plan de contrôle hors du net public

Le jour deux était un scan externe. Sur le chemin install hôte, 18789 n’écoutait que 127.0.0.1. Le security group n’autorisait que 22. Le scanner n’a pas vu le Gateway. C’est le défaut documenté pour un hôte normal, et le finding le plus calme de la semaine. Les images conteneur sont l’autre histoire : bind exposé par défaut, auth obligatoire. Publier des ports Docker n’est pas « aussi sûr qu’une install hôte ».

Pour SSH, trois exigences seulement : pas de login mot de passe, pas de mot de passe root, pas de vieux types de clés. L’accès distant au Gateway passait par un tunnel SSH (ou Tailscale), pas par « reverse-proxy de la Control UI sur 443 et on oublie le token ». HTTP et WebSocket partagent un port, Control UI et widgets écrits par l’agent compris. La guidance officielle traite ces widgets comme du contenu non fiable. Ne les mettez pas sur la même origine qu’une appli admin déjà connectée.

Les ports de conteneur publiés sautent l’INPUT hôte et empruntent la chaîne de forward de Docker. Les docs sécurité citent la chaîne DOCKER-USER. Si vous tournez un conteneur, retestez contre l’IP publique, pas contre ss dans le namespace. Pour le tranché pare-feu contre loopback, utilisez la matrice Linux d’exposition minimale SSH/HTTPS, puis revenez ici et demandez si quelqu’un a basculé le bind sur 0.0.0.0 pendant la semaine.

Le pairing de nœud est aussi une surface SSH. sshVerify relit l’identité de l’appareil via le SSH opérateur ; la seule joignabilité n’approuve pas. autoApproveCidrs est off par défaut et ne couvre qu’un premier rôle node sans scope. Nous avons laissé les deux défauts. La commodité n’est pas une raison d’auto-approuver une seconde machine.

Contrôle 3 : clés API — le clair sur disque reste lisible par l’agent

Le jour trois était un balayage de secrets. OpenClaw 2.0 a les SecretRefs : les champs apiKey fournisseur, le token Gateway et certains identifiants de canal peuvent se résoudre depuis env, file, exec ou store. Le clair fonctionne encore. Les SecretRefs sont opt-in par champ. « On est passés en 2.0 » ne veut pas dire « les clés ont quitté le disque ».

Le risque n’est pas « une clé existe sur la machine de garde ». Le risque est une clé là où read ou exec peut l’ouvrir : openclaw.json, .env, le agents/*/agent/models.json généré, les archives d’auth-profile retirées. L’injection de prompt n’a pas besoin de casser SSH si le modèle accepte de « lire la config et la coller dans le chat ». Le guide des secrets OpenClaw ne tient la migration pour finie que lorsque les champs supportés sont des SecretRefs, l’ancien clair est nettoyé, et openclaw secrets audit --check est propre. Les identifiants sans SecretRef ont encore besoin d’un utilisateur OS, d’un conteneur ou d’un proxy externe.

Traitez le token Gateway comme une classe à part. Un secret partagé qui peut appeler /v1/chat/completions, /tools/invoke ou le RPC admin est un identifiant opérateur complet. Pas dans le workspace de l’agent, pas dans un dépôt de skills, pas « pour la commodité » dans un second bot. La rotation est courte : nouveau token, redémarrage, clients mis à jour, preuve que l’ancienne valeur meurt. Nous avons déplacé les clés modèle vers des SecretRefs env et gardé le token Gateway dans un fichier env lisible seulement par l’utilisateur de déploiement. Plus aucune ligne sk- dans le workspace.

Contrôle 4 : le navigateur — vous tendez les mains de l’opérateur au modèle

Le jour quatre nous avons allumé un skill navigateur et l’avons éteint le jour même. Pas parce que Chromium mange la RAM — 8 Go tiennent un passage — mais parce que le contrôle navigateur distant est documenté comme équivalent à un accès opérateur. L’agent hérite des logins, cookies et mots de passe enregistrés de ce profil. Votre profil Chrome quotidien n’est pas un outil.

L’isolation est en couches : profil dédié, gestionnaire de mots de passe et sync coupés, répertoire de téléchargements à part traité comme non fiable, ports de contrôle seulement en loopback ou sur un tailnet, jamais Funnel. OpenClaw 2.0 peut faire tourner un navigateur sandboxé dans son propre conteneur sur openclaw-sandbox-browser, allowHostControl off par défaut. Le SSRF reste strict ; les destinations privées restent bloquées sauf dangerouslyAllowPrivateNetwork. Nous l’avons laissé off.

Relais d’extensions et CDP distant : « si vous voyez l’onglet, vous êtes cette personne ». Le mode session existante n’est pas plus sûr ; il est plus vous. Un nœud sur une machine bureau est admin après pairing. Gardez Gateway et nœud sur le même réseau privé. Règle de la semaine : un assistant texte n’a pas besoin de navigateur. S’il le faut, un profil sans comptes personnels, et ne partagez pas la RAM avec un modèle 7B local.

Contrôle 5 : isolation des agents — les défauts ne sont pas des locataires

Les jours cinq et six, nous avons ajouté un second agent en lecture seule et avons cru que les sessions se sépareraient. Elles ne l’ont pas fait. Le défaut tools.sessions.visibility est all ; tools.agentToAgent.enabled est true. Un agent sans sandbox peut lister, chercher et lire les sessions des autres, y compris la persona que vous croyiez « famille lecture seule ». Les appelants sandboxés restent sur leur arbre de spawn, mais cela ne cache pas leurs transcripts à un agent principal sans sandbox.

Séparer les personas sur un Gateway, c’est une visibilité agent ou self, l’agent-à-agent off ou en liste d’autorisation, et pas de sandbox scope: "shared". Si plus d’une personne peut DM le bot, mettez session.dmScope à per-channel-peer ou chaque DM roule dans la session principale. Ce sont des rambardes de collaboration, pas des murs de locataires hostiles. Client A et client B ont besoin de deux Gateways.

Les outils du plan de contrôle ont besoin de la même coupe. gateway lit la config (topologie et indices de secrets). cron continue après votre déconnexion. Tout agent qui verra du contenu non fiable doit refuser les deux, plus sessions_spawn et sessions_send. Traitez plugins et arbres de skills comme du code de confiance : sources épinglées, plugins.allow, redémarrage après changement.

Jour 7 : ce qui a dérivé, ce qui n’a pas bougé

Dernier passage : bind encore loopback, pairing encore pairing, personne n’avait ouvert 18789 sur le security group. Ce qui a dérivé, c’est une copie de debug .env dans le workspace et un allowHostControl commenté resté de l’essai navigateur — tout près d’atterrir dans le fichier « production » au merge. Après --fix, les modes de fichiers étaient propres. Avec le sandbox encore éteint sur l’agent principal, l’audit étiquette toujours la posture « opérateur de confiance », pas multi-utilisateur.

Lisez le tableau comme une décision : OpenClaw 2.0 peut rester allumé une semaine ou un an sur un VPS si vous acceptez un Gateway comme un domaine de confiance et si vous relancez l’audit avant une seconde persona, un navigateur ou un reverse-proxy public. Vous n’avez pas besoin d’une nouvelle fonction. Il faut que l’histoire par défaut « je fais confiance à l’opérateur » corresponde à la menace réelle.

Refermer : une liste scène par scène

Ne chassez pas le « zéro confiance entreprise » en une séance. Écrivez les conditions qui doivent toutes être vraies pour la charge de ce soir. Quand elles se battent, séparez les machines. Les exceptions empilées dans une config coûtent plus cher qu’une seconde box.

Deux corvées d’ops sont des corvées de sécu : les tokens dans les logs, et les plugins chargés depuis une source que vous n’avez pas lue. Activez le masquage et la rotation ; épinglez plugins.allow. Ensuite seulement, décidez si la box Linux de garde doit encore porter les clés opérateur, ou si ces clés appartiennent à un plan de contrôle plus calme.

FAQ

Texte seulement, défauts d’usine — un scan public voit-il le Gateway ?

Une install hôte en loopback ne montre pas 18789 sur l’internet public. Fermez d’abord le pairing. Un inconnu qui peut déjà vous DM est le vrai premier saut, pas nmap.

Docker est-il automatiquement plus sûr ?

Les images aident au rollback et à l’isolation du système de fichiers. Les conteneurs officiels exposent le bind par défaut, et les ports publiés contournent l’INPUT hôte. Sans auth et sans retest externe, Docker est en général plus risqué, pas plus sûr.

audit --fix remplace-t-il les retouches à la main ?

Non. Il ramène les politiques de groupe ouvertes vers des listes d’autorisation et rétablit les modes 600/700. Il n’allume pas le sandbox, ne migre pas les SecretRefs, et ne resserre pas la visibilité des sessions.

Le modèle peut-il lire la clé API lui-même ?

Si du clair reste sur un chemin lisible par l’agent, les outils fichiers ou exec peuvent l’ouvrir. Les SecretRefs réduisent le résidu disque. Ce n’est pas de l’isolation de processus. Ne combinez pas contenu non fiable et exec hôte.