Un serveur DeepSeek Harness lancé avec la commande officielle démarre par défaut sur http://127.0.0.1:3080, donc uniquement sur la boucle locale. (github.com) Votre décision est simple : cette semaine, gardez cette écoute locale et utilisez un tunnel SSH pour un accès personnel ou limité. Ne passez à une entrée publique que si vous pouvez ajouter une authentification indépendante, TLS, une restriction des sources et un audit des connexions.

Cette analyse s’adresse à trois profils :

  • Développeur individuel : vous voulez ouvrir ponctuellement le Web UI depuis un ordinateur portable ou une autre station.
  • Ingénieur plateforme : vous devez fournir un accès stable à plusieurs membres sans mélanger réseau, identité et permissions applicatives.
  • Responsable sécurité : vous devez vérifier que le proxy, trustedHosts, l’authentification et les droits internes forment réellement une chaîne de contrôle.
01

Le bon niveau d’entrée dépend d’abord du nombre d’utilisateurs

Ne commencez pas par modifier l’adresse d’écoute. Commencez par mesurer la portée réelle du besoin.

Pour un accès individuel, le tunnel SSH est généralement le meilleur compromis. Le processus DeepSeek Harness reste attaché à 127.0.0.1, tandis que votre navigateur local accède à un port transféré par SSH. Le service n’est pas rendu directement joignable par les autres machines du réseau.

Pour un groupe fixe, le tunnel SSH reste pertinent si chaque membre possède déjà un compte système distinct et si vous acceptez que l’accès soit géré au niveau SSH. Vous devez toutefois prévoir le retrait des clés, l’expiration des comptes et la traçabilité des connexions.

Pour une équipe plus large, une entrée HTTPS contrôlée peut devenir nécessaire. Elle doit alors être traitée comme un service partagé, et non comme une simple option de confort du Web UI. Le proxy doit gérer l’identité, les sessions, les règles d’accès et les journaux. DeepSeek Harness conserve ensuite ses propres contrôles de workspace, d’approbation et de permissions.

Le dépôt officiel décrit DeepSeek Harness comme un projet encore en « developer preview », avec des changements incompatibles possibles. Vous devez donc relire la documentation et le fichier de configuration à chaque évolution importante. (github.com)

La boucle locale n’est pas une authentification

Une écoute sur 127.0.0.1 limite la portée réseau. Elle ne vérifie pas l’identité d’une personne connectée sur la machine elle-même.

À l’inverse, une écoute non limitée à la boucle locale augmente la portée réseau. Elle ne crée pas non plus une authentification. Ces deux notions répondent à des questions différentes :

  • Réseau : qui peut atteindre le port ?
  • Hôte : quel nom ou quelle autorité HTTP l’application accepte-t-elle ?
  • Utilisateur : quelle personne est connectée ?
  • Application : quelles actions cette personne peut-elle approuver ou exécuter ?

Cette séparation est essentielle pour éviter une erreur fréquente : ouvrir la page, voir l’interface et conclure que l’accès est sécurisé.

Le guide officiel précise que le Web UI permet de choisir un workspace, de configurer une clé API et d’exécuter des opérations pouvant demander une approbation selon la politique active. Cela concerne le fonctionnement du harness, pas la preuve d’identité du navigateur. (raw.githubusercontent.com)

02

Les indicateurs réseau distinguent clairement tunnel SSH et entrée publique

Un tunnel SSH conserve le serveur Web UI sur la machine distante et expose seulement un point d’accès local sur votre appareil. La commande standard ressemble à ceci :

ssh -N -L 3080:127.0.0.1:3080 utilisateur@machine-distante

Le port local est alors relié au port du service distant. La documentation OpenBSD précise que l’adresse de liaison locale peut limiter le port transféré à l’usage local, alors qu’une adresse vide ou * peut le rendre disponible sur toutes les interfaces. (man.openbsd.org)

Pour votre poste client, utilisez donc une liaison locale explicite. Évitez de transformer le port transféré en nouveau service partagé par erreur.

Avantages du tunnel SSH :

  • le Web UI reste en boucle locale sur la machine distante ;
  • le transport est protégé par le canal SSH ;
  • la surface publique est réduite ;
  • la révocation peut s’appuyer sur les comptes ou clés SSH ;
  • la mise en place ne nécessite pas immédiatement un certificat public.

Limites du tunnel SSH :

  • chaque utilisateur doit disposer d’un accès SSH correctement géré ;
  • le partage d’un même compte détruit une partie de la traçabilité ;
  • la disponibilité dépend du processus SSH et de la connectivité réseau ;
  • le tunnel ne fournit pas automatiquement une gestion de sessions applicatives ;
  • il devient difficile à administrer lorsque les membres, les appareils et les environnements se multiplient.

Une entrée publique, elle, modifie le périmètre. Vous devez définir explicitement le nom d’hôte, l’adresse d’écoute, les sources autorisées et le chemin de fermeture. Une règle de pare-feu seule ne suffit pas si le proxy laisse passer n’importe quel utilisateur.

Après toute modification, contrôlez le résultat réel plutôt que la configuration théorique :

lsof -nP -iTCP:3080 -sTCP:LISTEN

Puis testez depuis un appareil situé sur un autre réseau :

curl -I http://adresse-ou-nom-autorise:3080

Ces commandes ne prouvent pas la sécurité. Elles répondent uniquement à deux questions : quel processus écoute, et le port est-il réellement joignable ?

Rappel de méthode : une page inaccessible depuis Internet peut être correctement protégée, mais une page accessible n’est pas nécessairement authentifiée. L’accessibilité est un indicateur réseau, jamais un test d’identité.

03

trustedHosts protège une autorité d’hôte, pas une personne

trustedHosts doit être traité comme une frontière de confiance liée à l’en-tête Host et au fonctionnement du proxy. Il peut aider l’application à refuser un nom d’hôte inattendu, mais il ne sait pas qui se trouve derrière le navigateur.

Ce point rejoint les recommandations générales de test contre l’injection d’en-tête Host : si une application accepte sans validation une valeur contrôlée par le client, elle peut générer des redirections, sélectionner un hôte inattendu ou contourner une logique qui dépend du domaine demandé. (owasp.org)

La configuration de trustedHosts doit donc être précise :

  • utilisez les noms réellement employés par les utilisateurs ;
  • évitez les valeurs génériques couvrant tous les hôtes ;
  • vérifiez le comportement lorsque le proxy transmet ou réécrit Host ;
  • testez également X-Forwarded-Host si votre architecture l’utilise ;
  • rejetez les noms non prévus au lieu de les accepter pour faciliter le dépannage.

Une configuration correcte doit produire un refus avec un nom d’hôte invalide. Elle ne doit pas être présentée comme une page de connexion.

Pour un accès d’équipe, il faut en plus une authentification indépendante. Selon votre architecture, il peut s’agir d’un fournisseur d’identité, d’une authentification forte, d’un certificat client ou d’un mécanisme de session géré par le proxy. Les exigences minimales sont les suivantes :

  • identifier chaque membre sans compte partagé ;
  • expirer ou révoquer une session ;
  • retirer rapidement un utilisateur ;
  • enregistrer les succès et les échecs de connexion ;
  • limiter les actions selon le rôle ;
  • empêcher l’exposition de la clé API dans le navigateur ou dans les journaux.

Le Web UI officiel demande de saisir la clé API dans les paramètres du modèle et indique que la configuration devient utilisable sans redémarrage. Vous devez donc vérifier où cette valeur est stockée et comment elle circule avant d’autoriser plusieurs utilisateurs. (raw.githubusercontent.com)

04

Le transport et les secrets fixent la limite du passage par Internet

Un tunnel SSH chiffre le trajet entre votre client SSH et la machine distante. Il ne transforme pas automatiquement le Web UI en application multi-utilisateur. Vous devez toujours protéger le compte système, les clés privées et les permissions du workspace.

Une entrée HTTPS inverse les responsabilités. Le proxy doit présenter un certificat valide, empêcher les accès HTTP non protégés et transmettre les requêtes au service interne sans exposer les secrets. TLS fournit la confidentialité, l’intégrité et l’authentification du serveur, mais l’authentification du client reste une fonction distincte. (developer.mozilla.org)

Avant d’autoriser un accès externe, contrôlez les points suivants :

  • l’URL publique utilise HTTPS de bout en bout jusqu’au proxy ;
  • les ressources du Web UI ne sont pas chargées depuis une origine HTTP ;
  • les journaux ne contiennent ni clé API ni cookie de session ;
  • les en-têtes de proxy sont documentés et cohérents avec trustedHosts ;
  • les utilisateurs ne reçoivent pas une clé API commune par commodité ;
  • le proxy refuse les méthodes ou chemins non nécessaires ;
  • le pare-feu limite l’accès aux sources prévues.

Si vous utilisez un Mac distant pour des travaux audio, vidéo ou design, l’accès au Web UI ne représente qu’une partie de la chaîne. Le workspace, les fichiers importés et les opérations approuvées restent sur la machine distante. Une équipe doit donc sécuriser aussi les répertoires, les comptes système et les sauvegardes.

Pour un poste de travail distant stable, vous pouvez comparer les options disponibles dans les pages Mac mini distant pour le développement et tarifs de location de Mac mini. Le choix du matériel ne remplace pas la conception de l’entrée réseau, mais il influence la disponibilité du workspace et la continuité des sessions.

05

L’audit et la maintenance font la différence dans la durée

Le tunnel SSH coûte peu en maintenance tant que le nombre d’utilisateurs reste limité. Vous devez surveiller les clés, les comptes, les connexions et les processus persistants, mais vous n’avez pas à maintenir une application publique complète.

Une entrée d’équipe ajoute plusieurs responsabilités :

  • journaliser les connexions acceptées et refusées ;
  • associer les actions à une identité connue ;
  • documenter les changements de DNS, proxy, certificat et pare-feu ;
  • tester la révocation après chaque modification importante ;
  • vérifier le comportement après une mise à jour de DeepSeek Harness ;
  • prévoir une procédure de retour à la boucle locale ;
  • conserver un responsable capable de fermer l’entrée rapidement.

Le risque principal n’est pas seulement l’attaque externe. C’est aussi l’oubli opérationnel. Un certificat arrive à expiration, une règle de proxy est élargie pour résoudre un incident, une clé reste active après le départ d’un membre ou une mise à jour change le comportement des en-têtes.

Pour un usage personnel temporaire, cette charge est disproportionnée. Pour une équipe, elle est incontournable.

06

La procédure d’acceptation doit commencer par l’extérieur

Voici une procédure de validation que vous pouvez appliquer à chaque déploiement. Elle évite de confondre « le navigateur affiche la page » avec « le système est prêt à être partagé ».

Étape 1 : figer la version et la configuration

Notez la version installée, la commande de démarrage, le répertoire de travail et l’adresse d’écoute. Au 19 août 2026, la documentation officielle indique un démarrage Web UI sur 127.0.0.1:3080 par défaut. Vérifiez cette valeur dans le dépôt officiel avant de réutiliser une commande après une mise à jour. (github.com)

Étape 2 : vérifier l’écoute réelle

Utilisez lsof, ss ou un outil équivalent pour confirmer l’adresse et le port. Contrôlez également le pare-feu local et le pare-feu du fournisseur d’infrastructure. Une configuration déclarée sur une adresse locale ne doit pas apparaître comme accessible depuis un réseau externe.

Étape 3 : tester le chemin choisi

Pour SSH, ouvrez le tunnel depuis un appareil autorisé, chargez l’URL locale et interrompez le processus SSH. Pour un proxy, testez depuis un réseau externe, puis essayez l’URL sans HTTPS, avec un nom d’hôte invalide et depuis une source non autorisée.

Étape 4 : valider l’identité

Utilisez un compte de test autorisé et un compte refusé. Vérifiez que la session possède un identifiant distinct, que sa révocation prend effet et qu’un compte supprimé ne peut pas réutiliser une session existante.

Étape 5 : valider le workspace et les permissions

Ajoutez le workspace prévu, exécutez une tâche sans effet destructif, puis tentez une opération nécessitant une approbation. Le guide officiel confirme que les opérations dépendant de la politique active peuvent demander une approbation dans le Web UI. (raw.githubusercontent.com)

Étape 6 : contrôler les secrets et les journaux

Cherchez les clés API, cookies, jetons et en-têtes sensibles dans les journaux du proxy, du processus et du navigateur. Vérifiez également que les erreurs retournées à un utilisateur non autorisé ne révèlent pas le chemin du workspace ou la configuration interne.

Étape 7 : simuler une coupure

Arrêtez le tunnel ou le proxy, redémarrez DeepSeek Harness, puis vérifiez la reconnexion. Une solution acceptable doit échouer proprement et revenir à un état contrôlé. Si la reprise nécessite de supprimer manuellement des fichiers de session ou de réouvrir une règle trop large, le déploiement n’est pas prêt.

07

Tableau de choix selon votre niveau d’exposition

Situation observée Entrée recommandée Conditions minimales Décision de repli
Accès personnel ponctuel depuis un autre appareil Tunnel SSH Compte SSH individuel, clé protégée, port local limité Retour à l’accès local
Petit groupe fixe avec comptes système distincts Tunnel SSH ou réseau privé contrôlé Révocation des clés, journaux SSH, workspace séparé Tunnel SSH individuel
Équipe avec accès régulier et besoins d’audit Proxy HTTPS contrôlé Authentification indépendante, TLS, sources autorisées, journaux et responsable Boucle locale jusqu’à validation
Utilisateurs externes ou identité non maîtrisée Ne pas ouvrir directement le Web UI Modèle d’accès à revoir, permissions et sessions à formaliser Accès individuel temporaire
Besoin de continuité sur un Mac distant Entrée privée ou tunnel persistant Supervision, reprise après coupure, contrôle du workspace Accès local et relance manuelle

Un proxy inverse n’est donc pas automatiquement meilleur qu’un tunnel SSH. Il est plus adapté à un service partagé, mais il apporte aussi une surface de configuration plus large. Le tunnel est plus simple, mais il ne constitue pas une gouvernance d’équipe complète.

08

Tableau d’acceptation avant ouverture non locale

Contrôle Résultat attendu Preuve à conserver
Adresse d’écoute Adresse conforme au niveau d’exposition choisi Sortie de l’outil d’écoute
Port externe Accessible uniquement depuis les sources prévues Test externe et règle de pare-feu
trustedHosts Hôtes prévus acceptés, hôtes inconnus refusés Réponses de test avec Host valide et invalide
Authentification Chaque membre est identifiable et révocable Journal de connexion et test de retrait
TLS Certificat valide, HTTP non utilisé pour la session Vérification du navigateur et de la configuration TLS
Workspace Répertoire attendu, permissions conformes Tâche de lecture, écriture et approbation
Secrets Aucun secret dans URL, logs ou capture Revue des journaux et du navigateur
Reprise Arrêt, redémarrage et reconnexion contrôlés Compte rendu de coupure et restauration

Si une seule ligne reste sans preuve, ne considérez pas l’entrée publique comme acceptée. Revenez à la boucle locale ou au tunnel SSH jusqu’à ce que le contrôle soit documenté.

09

Questions fréquentes

Le Web UI de DeepSeek Harness peut-il être exposé directement sur Internet ?

Oui, la configuration officielle prévoit une écoute non limitée à la boucle locale, mais cela ne fournit pas une sécurité complète. Une exposition publique doit être placée derrière une authentification indépendante, HTTPS, une restriction des sources et des journaux exploitables. Si vous ne pouvez pas révoquer un utilisateur ou identifier ses connexions, utilisez plutôt un tunnel SSH.

Pourquoi trustedHosts ne remplace-t-il pas une authentification ?

trustedHosts contrôle l’autorité d’hôte acceptée par l’application. Il ne vérifie pas l’identité de la personne qui utilise le navigateur, ne crée pas une session utilisateur et ne gère pas la révocation. Une page accessible après validation de l’en-tête Host prouve uniquement que la requête est acceptée par cette couche, pas que l’utilisateur est autorisé.

Tunnel SSH ou proxy inverse pour un accès distant ?

Choisissez le tunnel SSH pour un accès personnel ou un petit groupe déjà administré au niveau système. Choisissez un proxy inverse pour une équipe seulement si vous disposez d’une authentification indépendante, de TLS, d’un contrôle des sources, de journaux et d’une procédure de retrait. Un proxy sans identité ni audit ne fait qu’élargir la surface réseau.

Que vérifier après une écoute sur 0.0.0.0 ?

Vérifiez le processus réellement à l’écoute, le pare-feu, la portée externe du port, le nom d’hôte accepté, les en-têtes du proxy, le certificat TLS, les comptes autorisés et les journaux. Testez aussi un Host invalide, une source interdite, un utilisateur révoqué et la fermeture complète de l’entrée publique avant de partager l’URL.

10

Conclusion : choisissez la gouvernance avant l’URL

Si votre solution actuelle est un port exposé sans authentification indépendante, elle dépend trop fortement de la discrétion du lien. Si elle repose uniquement sur trustedHosts, elle contrôle le nom d’hôte mais pas l’identité. Si elle utilise un proxy sans journaux ni procédure de révocation, elle rend les incidents difficiles à attribuer et à contenir.

Pour un usage individuel, le tunnel SSH reste le choix le plus raisonnable. Pour une équipe, une entrée HTTPS peut être pertinente, mais uniquement après validation de l’identité, du transport, des sources, des permissions et de la reprise après coupure. Si vous avez besoin d’un Mac distant qui reste disponible pour du développement, du montage audio ou vidéo, du design ou des tâches DeepSeek Harness prolongées, examinez d’abord la commande d’un Mac distant, puis validez séparément l’architecture d’accès. La location d’un environnement Mac auprès de VpsMesh peut être plus souple pour un test, une mission temporaire ou un poste distant à maintenir sans achat immédiat, mais elle ne dispense pas de cette validation du réseau et de la sécurité.