Ce guide s'adresse aux équipes qui font déjà tourner OpenClaw sur un Mac distant LeanVPS en Allemagne (Francfort) et qui veulent une surface d'attaque plus faible qu'une passerelle ouverte sur le LAN. Nous gardons l'écoute sur le loopback, imposons une authentification par jeton de passerelle, joignons le service via un SSH LocalForward, et traitons openclaw doctor --non-interactive ainsi que openclaw config validate comme barrières de fusion obligatoires. Le comportement attendu est calé sur la documentation officielle — notamment la référence de configuration (liaison et auth de la passerelle), le guide Configuration (substitution par variables d'environnement), CLI doctor et Gateway doctor — et non sur des résumés tiers.

Objectif : plan de contrôle loopback uniquement, exposition minimale

La passerelle OpenClaw multiplexe WebSocket et HTTP sur le port 18789 par défaut. La référence de configuration indique que gateway.bind: "loopback" maintient l'écoute sur localhost, tandis que les liaisons hors loopback exigent une authentification de passerelle (jeton, mot de passe ou proxy de confiance correctement borné). Sur un Mac distant partagé, le compromis raisonnable est donc : liaison loopback + mode jeton, les opérateurs et l'automatisation atteignant le port par un tunnel chiffré plutôt qu'en exposant 18789 sur l'interface publique de l'hôte.

Combinez cette topologie avec les pratiques démon, sortie réseau et journaux décrites dans notre article compagnon OpenClaw sur LeanVPS Allemagne : démon, liste blanche et base conformité. Pour dimensionner ou louer une instance, appuyez-vous sur la page publique Achat Allemagne et croisez les paliers mémoire sur les tarifs. La console reste le point d'entrée pour la région d'hébergement affichée sur la facture et les tickets.

127.0.0.1
Liaison loopback
SSH -L
Tunnel LocalForward
CI
Validate + doctor

Étapes minimales reproductibles (Mac distant)

Exécutez d'abord la séquence sur un hôte de préproduction ; ne propagez le même plist, le même bloc sshd_config et le même job CI vers la production qu'après un essai sec au vert. Limitez le compte SSH du tunnel aux clés fortes, désactivez l'agent forwarding pour ce principal si vous n'en avez pas besoin, et documentez dans le runbook quels postes opérateurs peuvent ouvrir le LocalForward et pendant combien de temps une session reste autorisée.

  1. Socle SSH. Créez un utilisateur macOS dédié à OpenClaw. N'installez que la build OpenClaw approuvée par votre chaîne d'approvisionnement, puis vérifiez un SSH non interactif par clés (désactivez l'authentification par mot de passe pour ce compte dans sshd_config si la politique interne l'autorise).
  2. Déclarer liaison et auth en JSON5. Dans ~/.openclaw/openclaw.json, conservez gateway.mode: "local", réglez gateway.bind: "loopback" et configurez gateway.auth.mode: "token" avec gateway.auth.token: "${OPENCLAW_GATEWAY_TOKEN}" comme décrit sous « Env var substitution in config values » dans le guide officiel Configuration. Si des objets jeton et mot de passe coexistent, la référence impose un gateway.auth.mode explicite — fixez-le volontairement pour éviter un démarrage ambigu.
  3. Injecter le jeton, pas un chemin de secret dans Git. Fournissez OPENCLAW_GATEWAY_TOKEN via le dictionnaire EnvironmentVariables du LaunchDaemon ou un fichier d'environnement appartenant à root avec permissions POSIX strictes. Pour un bootstrap ponctuel sur un shell admin sécurisé, vous pouvez lancer openclaw doctor --generate-gateway-token comme documenté sur CLI doctor ; faites ensuite tourner le secret et migrez-le vers votre coffre (Vault, gestionnaire de secrets CI, etc.) sans le laisser dans l'historique shell partagé.
  4. Contrôle santé sans TTY. Enchaînez openclaw config validate puis openclaw doctor --non-interactive. La page Gateway doctor précise que --non-interactive évite les invites, applique les migrations sûres et contourne le rafraîchissement OAuth interactif — adapté au cron ou à la CI.
  5. Installer ou redémarrer le service passerelle. Réutilisez le flux fournisseur déjà standardisé chez vous (par ex. openclaw gateway install avec les drapeaux épinglés). Vérifiez avec openclaw gateway status qu'un écouteur sain n'écoute que le loopback.
  6. SSH LocalForward depuis le poste opérateur. Exécutez ssh -N -L 18789:127.0.0.1:18789 openclaw-svc@hote-allemagne.exemple (adaptez utilisateur et FQDN). Vos outils locaux ciblent ws://127.0.0.1:18789 tandis que le trafic transite par SSH. Ajoutez -o ExitOnForwardFailure=yes et, pour un tunnel longue durée, une unité systemd ou launchd côté client avec journalisation minimale des échecs de connexion.
  7. Test fumée du chemin jeton. Tunnel levé, connectez-vous depuis le portable à 127.0.0.1:18789 avec le schéma bearer documenté dans votre runbook (Control UI, CLI ou petit script jetable). Envoyez une fois un jeton volontairement faux : vous devez obtenir un échec d'authentification explicite, preuve de bout en bout que la passerelle refuse les accès non autorisés.
Pourquoi éviter le bind LAN ? Ouvrir 18789 sur 0.0.0.0 sans contrôles compensatoires augmente la surface de découverte et de force brute. Si un accès hors SSH est indispensable, placez un reverse proxy durci (mTLS, Tailscale Serve, etc.) et relisez la section trusted-proxy de la référence de configuration plutôt que de renoncer à l'auth.

Checklist exposition / conformité d'exploitation (ingénierie uniquement)

Aucun des points ci-dessous ne constitue un avis juridique ; ils traduisent le moindre privilège en critères vérifiables que la revue sécurité peut contrôler automatiquement ou manuellement.

  • Pas de jetons en clair dans l'historique shell : chargez les secrets via LaunchDaemon ou injecteurs de secrets CI, jamais avec un export inline dans une session screen partagée.
  • Séparer SSH opérateur et comptes de service : les humains utilisent leurs propres principaux UNIX ; l'utilisateur du démon OpenClaw ne doit pas posséder vos dotfiles personnels.
  • Réviser les diffs passerelle en PR : toute modification touchant gateway.bind, gateway.auth, hooks ou gateway.http exige une double relecture.
  • Sauvegarder la config avant les réparations doctor : conservez une copie horodatée de openclaw.json avant montée de version ; si une migration supprimait des métadonnées d'auth, restaurez depuis le stockage d'artefacts et redémarrez le service.
  • Documenter le bris de glace : si quelqu'un élargit temporairement le mode de liaison pour un incident, ouvrez un ticket et revenez au socle dans la fenêtre SLA.

Recette de barrière de fusion (pseudo CI type GitHub Actions)

Versionnez dans Git un gabarit ou un extrait sanitisé de la config — jamais le jeton de production. Injectez un OPENCLAW_GATEWAY_TOKEN factice depuis les secrets CI pour que les chemins de validation résolvant la substitution d'environnement réussissent. Le job doit :

  1. Installer la même version mineure OpenClaw qu'en production.
  2. Exécuter openclaw config validate sur le modèle commité fusionné avec des secrets de test.
  3. Exécuter openclaw doctor --non-interactive ; faire échouer le pipeline si les avertissements dépassent le seuil défini (beaucoup d'équipes traitent toute ligne « auth missing » comme erreur bloquante).
  4. Option : lancer openclaw doctor --deep en nocturne — pas à chaque PR — car les analyses profondes sont plus lentes et peuvent exiger des droits élevés.

Pour les blocages provisioning ou SSH, suivez votre runbook interne ; les pages publiques Aide et Console restent les canaux documentés côté LeanVPS.

Guide d'exploitation uniquement. Le comportement d'OpenClaw évolue d'une release à l'autre — vérifiez drapeaux et valeurs par défaut sur les liens de documentation officielle cités avant de basculer l'automatisation en production.
Francfort · Mac distant

Besoin de métal dédié pour cette topologie ?

Provisionnez un Mac mini sur le nœud Allemagne via le flux d'achat public Allemagne, alignez la mémoire unifiée avec votre empreinte navigateur et modèle sur la page tarifs, et ouvrez un ticket depuis l'aide si l'accès SSH ou le déploiement bloque.

Achat Allemagne Voir les tarifs Centre d'aide