OpenClaw SSH
Diagnostic port forwarding en pratique

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

La passerelle OpenClaw multiplex WebSocket et HTTP sur le port 18789 par défaut. La référence de configuration indique que gateway.bind: "loopback" verrouille le listener sur l'interface de loopback locale, tandis qu'une liaison non-loopback nécessite l'activation de l'authentification de passerelle (token, mot de passe ou proxy de confiance strictement configuré). Pour un Mac distant partagé, la meilleure approche est : liaison loopback + mode token — les opérateurs et l'automatisation accèdent au port via un tunnel chiffré, sans exposer 18789 sur l'interface publique de l'hôte.

Cet article peut être lu en complément de : OpenClaw sur nozcloud Allemagne : mise en service du daemon et conformité de base. Pour acheter ou ajuster une configuration, visitez la page d'achat et comparez les offres sur la page de tarifs.

Étapes minimales reproductibles (Mac distant)

Il est recommandé d'exécuter le processus suivant sur une machine de test, puis de pousser le même plist, la configuration SSH et les tâches CI en production une fois la validation réussie.

1. Configuration SSH de base. Créez un utilisateur macOS dédié pour OpenClaw. Installez uniquement la version OpenClaw que vous avez approuvée, puis vérifiez le SSH non-interactif par clé (désactivez l'authentification par mot de passe pour ce compte dans sshd_config si la politique le permet).
2. Déclarez la liaison et l'authentification en JSON5. Dans ~/.openclaw/openclaw.json, conservez gateway.mode: "local", définissez gateway.bind: "loopback", et configurez gateway.auth.mode: "token" et gateway.auth.token: "${OPENCLAW_GATEWAY_TOKEN}". Si les objets token et password coexistent, spécifiez explicitement gateway.auth.mode pour éviter toute ambiguïté au démarrage.
3. Injectez le token sans committer le chemin de la clé dans Git. Exportez OPENCLAW_GATEWAY_TOKEN via le dictionnaire EnvironmentVariables du LaunchDaemon ou un fichier d'environnement en propriété root avec des permissions POSIX strictes. Lors du premier démarrage, exécutez openclaw doctor --generate-gateway-token dans un shell administrateur sécurisé.
4. Vérification de santé sans TTY. Exécutez successivement openclaw config validate et openclaw doctor --non-interactive. L'option --non-interactive ignore les invites interactives, applique les migrations de sécurité et évite le rafraîchissement OAuth interactif — idéal pour les crons et CI.
5. Installer ou redémarrer le service de passerelle. Utilisez le processus vendor standardisé (ex. openclaw gateway install avec vos paramètres fixés). Confirmez que openclaw gateway status affiche le listener actif uniquement sur l'adresse de loopback.
6. Établissez un SSH LocalForward depuis votre poste local. Exécutez ssh -N -L 18789:127.0.0.1:18789 openclaw-svc@germany-host.example (remplacez utilisateur et hôte). Vos outils locaux peuvent alors accéder à ws://127.0.0.1:18789 tandis que le trafic est chiffré via SSH.
7. Validez le chemin du token. Une fois le tunnel établi, connectez-vous à 127.0.0.1:18789 depuis votre ordinateur portable avec le Bearer Token selon le runbook d'exploitation. Envoyez intentionnellement un token incorrect : vous devriez voir un échec d'authentification, pas une acceptation silencieuse — preuve de l'application de bout en bout.

Liste de contrôle de surface d'exposition orientée conformité

Ces éléments ne constituent pas des conseils juridiques ; ils traduisent le principe du moindre privilège en points de contrôle concrets vérifiables par les auditeurs de sécurité.

• Ne jamais laisser de tokens en clair dans l'historique shell : chargez les secrets via LaunchDaemon ou un injecteur de secrets CI, ne faites jamais d'export en ligne dans une session partagée.
• Séparez les comptes SSH d'exploitation et les comptes de service : les utilisateurs humains ont leur propre principal UNIX ; l'utilisateur daemon OpenClaw ne doit pas avoir accès à vos dotfiles personnels.
• Révisez les modifications de configuration de passerelle dans les PR : tout changement impliquant gateway.bind, gateway.auth, hooks ou les endpoints gateway.http doit faire l'objet d'une double révision.
• Sauvegardez la configuration avant que doctor n'applique des corrections : conservez une copie horodatée de openclaw.json avant les mises à jour ; si une migration entraîne une perte de métadonnées d'authentification, restaurez depuis le stockage d'artefacts et redémarrez le service.
• Documentez les procédures opérationnelles d'urgence : si quelqu'un assouplit temporairement le mode de liaison lors d'un incident, soumettez immédiatement un ticket et revenez en arrière dans la fenêtre SLA.

Schéma de contrôle de merge (exemple en pseudo-code GitHub Actions)

Stockez dans Git les fixtures en lecture seule de votre configuration de production ou des extraits anonymisés — jamais les tokens de production. Injectez un OPENCLAW_GATEWAY_TOKEN à usage unique via les secrets CI pour que les chemins de validation nécessitant la substitution de variables d'environnement fonctionnent correctement. La tâche doit inclure les étapes suivantes :

1. Installer la même version minor d'OpenClaw qu'en production.
2. Appliquer openclaw config validate au résultat fusionné du template versionné et du token de test.
3. Exécuter openclaw doctor --non-interactive ; échouer si les avertissements dépassent le seuil de la politique (de nombreuses équipes traitent toute ligne « authentification manquante » comme une erreur bloquante).
4. Optionnel : exécuter openclaw doctor --deep la nuit plutôt qu'à chaque PR — le scan profond est plus long et peut nécessiter des privilèges élevés.

Pour les questions de mise à jour, suivez votre runbook d'exploitation interne ; en cas de blocage sur le provisionnement ou l'accès SSH, soumettez un ticket via le lien du centre d'aide ci-dessous.