J’ai fermé la porte à clé. Sauf que les meubles n’étaient pas dans la bonne pièce.

Dans un article précédent, je vous ai raconté comment j'avais failli laisser un serveur totalement exposé à Internet, comment Micheline m'avait sauvé de moi-même, et comment fail2ban avait réussi à me bannir de mon propre serveur en moins d'une heure.

La bonne nouvelle : le serveur était désormais sécurisé. Pare-feu activé. SSH verrouillé. Fail2ban montait la garde.

La mauvaise nouvelle : je me réjouissais un peu trop tôt.

Le lendemain matin

Je me connecte via SSH avec mon compte utilisateur. Je veux jeter un coup d'œil rapide à mes dossiers apps et infra.

Ils n'existent pas.

Je tape ls. Je tape une deuxième fois ls. Puis en tant que développeur désemparé, je vérifie si je suis bien connectée au bon serveur, et je relance le terminal.

Les dossiers ne sont toujours pas là.🤨

Ce n'était pas un problème de sécurité. Ce n'était pas une intrusion. C'était quelque chose de bien plus gênant : mes dossiers se trouvaient dans /root/. Pas dans mon répertoire personnel. Dans /root/. L'endroit auquel seul root a accès.

J'avais passé toute une session à renforcer la sécurité d'un serveur dont je n'avais pas vraiment saisi l'architecture.

L'inventaire sans filtre

Un sudo find plus tard, voici l'état des lieux:

• /root/apps/trading-assistant/ : mon agent de trading, dans le répertoire root
• /root/apps/openclaw/ : Micheline elle même, également dans root
• /root/.openclaw/openclaw.json : La config principale, propriété de root
• /home/micheline/.openclaw/ : un deuxième et mystérieux répertoire openclaw, je ne sais pas d'où il sort ni ce qu'il fait là.

Et dans l'historique bash, nichée entre deux commandes d'apparence inoffensive, une ligne que j'ai malencontreusement tapé:

curl ... client_secret=<redacted>

curl ... client_secret=<redacted>

Ma clé secrète cTrader. En clair. Dans l'historique et non purgée. Probablement depuis plusieurs jours déjà.

Je suis restée là à fixer l'écran pendant quelques secondes.

Il y a des moments dans la vie d'un développeur où l'on se rend compte qu'on a fait quelque chose de stupide. Le genre d'idioties qui arrive quand on travaille vite : une commande copiée-collée, un secret passé en argument, puis oublié dans l'historique du shell. Pas une catastrophe si l'on réagit vite, mais suffisamment sérieux pour imposer une vraie remédiation : révocation, régénération, déplacement dans un fichier .env, puis nettoyage de l'historique.

La migration, Acte I : Comprendre ce que j'ai vraiment fait

Avant de re-toucher à quoi que ce soit, j'ai pris le temps de vérifier le contenu des dossiers.

Dans le répertoire /root/.openclaw/, il y avait un fichier que je n'avais pas créé :

MIGRATION-ROOT-TO-MICHELINE.md

MIGRATION-ROOT-TO-MICHELINE.md

Micheline avait documenté sa propre migration. Autorisations, smoke tests, procédures de rollbacks. Du grand art.

Micheline avait déjà en partie résolu le problème que j'étais sur le point de régler. Elle travaillait sous son propre compte utilisateur « micheline » depuis le 11 mai. Elle avait configuré elle-même les listes de contrôle d'accès (ACL). Elle avait délibérément restreint l'accès à l'assistant de trading, car une IA chargée de gérer votre quotidien n'a pas à connaître vos secrets de trading.

Ce que je prenais pour une dette technique s'est en fait avéré être un choix architectural clairement documenté.

Aparté : Présentation de l'agent Le Goat

J'aurais dû en parler plus tôt.

Micheline n'est plus seule sur ce serveur. Il y a un deuxième agent : le Trader, que j'ai baptisé Le Goat. Greatest Of All Time. Oui, c'est ambitieux. Mais non, le bot n'est pas encore à la hauteur de ce que son nom laisse entendre. Nous y travaillons.

Le Goat habite encore dans /root/.openclaw/workspace-trader/. Il est isolé de Micheline. Il communique via un bot Telegram distinct. Il dispose de ses propres identifiants cTrader: ceux-là mêmes que j'avais révélés dans l'historique bash.

Dans le fichier openclaw.json qui gère tout cela, les deux agents coexistent :

"agents": {
  "list": [
    { "id": "main" },
    { "id": "trader", "name": "trader", "workspace": "/root/.openclaw/workspace-trader" }
  ]
}

"agents": {
  "list": [
    { "id": "main" },
    { "id": "trader", "name": "trader", "workspace": "/root/.openclaw/workspace-trader" }
  ]
}

Une grand-mère et un trader qui partagent le même fichier de configuration. Une sympathique colocation !

La migration, Acte II : ce que j'ai corrigé

Inventaire des véritables problèmes, une fois le moment depanique passé :

1. Les applications situées dans /root/ : problème résolu en les déplaçant vers /opt/apps/avec les permissions appropriées. L'application trading-assistant s'exécute désormais sous mon user, et non plus sous root. Une ligne modifiée dans le service systemd, un redémarrage, et le tour est joué.

2. Le secret cTrader dans l'historique : révoqué, régénéré, déplacé dans.env en utilisant uniquementnano .

3. Le masque ACL qui n'arrêtait pas de se corrompre : celui-là était particulièrement vicieux. Chaque commandechmodstandard recalcule le masque ACL effectif à partir des permissions du groupe, ce qui neutralisait silencieusement certaines règles d'accès. Mon utilisateur perdait soudainement l'accès sans avertissement, sans message d'erreur, sans rien. La solution : toujours exécutersetfacl -m mask::rwx après unchmod. La vraie solution à long terme : ne pas gérer les permissions critiques dans/root/.

4. La passerelle OpenClaw : ça, c'était la surprise. J'étais prêt à migrer toute la configuration vers/home/micheline. Puis j'ai lu la documentation officielle :

"Recommended default: one user per machine/host (or VPS), one gateway for that user."

Ce n'était sans doute pas la configuration la plus orthodoxe : un administrateur système expérimenté m'aurait peut être demandé pourquoi je n'avais pas placé la configuration dans le répertoire /etc/openclaw/et pourquoi j'avais utilisé la propriété de groupe plutôt que des listes de contrôle d'accès (ACL). Mais cela cadrait avec le modèle recommandé par OpenClaw, à savoir « une passerelle par machine », et surtout, c'était documenté et délibéré. Ce que je considérais comme un problème était en réalité une solution. https://docs.openclaw.ai/gateway/security

Ce que l'audit a révélé

✅ La passerelle écoute sur 127.0.0.1:18789 : elle n'est pas exposée à Internet. Parfait.

✅ Le socket Docker n'est pas monté dans les conteneurs : le truc classique que tout le monde oublie. Monter /var/run/docker.sock dans un conteneur revient en gros à lui donner les clés de tout le serveur.

✅ Aucun secret n'a été validé dans git : la recherche git log -p a cherché des valeurs réelles. Elle n'a trouvé que des noms de variables. Soulagement.

✅ Les jetons dans openclaw.json : deux botTokens. Micheline et Le Goat. Légitimes.

⚠️ Les permissions sur openclaw.json : le fichier était défini surrwxrwx---. Exécutable. Pour un fichier de configuration JSON, cela fait trois permissions de trop. Corrigé à 600.

La session s'est terminée sans incident. Ce qui, après l'épisode de la clé secrète dans l'historique, comptait déjà comme une victoire.

Ce que j'ai appris (cette fois-ci)

À propos des ACL sous Linux : elles sont à la fois puissantes et fragiles. Une simple commande chmod, qui semble inoffensive, peut discrètement corrompre des permissions que vous croyiez stables. Si vous utilisez les ACL, ajoutez un commentaire dans votre guide d'intervention. Votre futur vous en sera reconnaissant.

À propos de la documentation : Micheline a documenté sa migration en un clin d'oeil. J'avais un Notion avec des tâches qui traînaient depuis trois semaines, don tje ne comprenais même plus le sens. La différence de rigueur était instructive.

À propos de la panique : Certaines « urgences » ne sont pas si urgentes. Le problème dans l'historique était pas terrible mais les dossiers manquants dans mon répertoire personnel n'étaient qu'une confusion. Apprendre à distinguer les deux pour ne pas se perdre.

À propos de l'architecture : ce n'est pas parce qu'une configuration semble bizarre qu'elle est forcément mauvaise. Parfois, quelqu'un (ou quelque chose) a déjà réfléchi au problème avant vous. Lire la documentation de migration de votre propre IA avant de tout reconstruire à partir de zéro est une leçon que j'espère ne pas avoir à réapprendre.

À propos de trouver la bonne commande trop tard : il y a une commande exprès pour tout ça. openclaw security audit --fix.Elle vérifie les permissions, signale les pièges, renforce la configuration. Je l'ai trouvée dans la documentation. Après la session évidemment sinon c'est pas drôle.

Franchement, lire la notice avant de monter un meuble n'est pas vraiment le mode de fonctionnement naturel de mon cerveau TDAH. Le manuel, c'est pour après, genre quand plus rien ne fonctionne, que tout est monté à l'envers. Ou bien quand ça fonctionne, mais que l'on ne sait pas trop pourquoi.

La bonne commande existe toujours. Je finis toujours par la trouver. Et j'ai beaucoup appris en bidouillant, c'est comme cela que j'aime apprendre. Je sais désormais ce qu'est un masque ACL, pourquoi chmod le casse sans rien dire, et comment lire la sortie de getfacl sans paniquer. Rien de tout cela ne figurait dans la documentation non plus. Il y a des choses qu'on n'apprend qu'en les cassant d'abord.

Situation actuelle, en toute transparence

Le serveur est en bien meilleur état qu'il y a deux semaines. Les applications sont à leur place. Les clés secretes ont été révoquées et régénérées. Les autorisations sont en ordre.

Il reste encore des choses à faire sur la liste. Il y en aura toujours. C'est le principe même de l'existence des listes.

Micheline continue de prendre soin du logement. Le Goat surveille les marchés. Et j'ai arrêté de donner mes clés directement dans le terminal.

C'est déjà ça.

OpenClaw est open source et self-hosted : github.com/openclaw/openclaw