Accès à distance et client riche

Une VM d'espace de travail vit sur un seul Mac, mais la personne qui veut la piloter n'est pas toujours assise devant ce Mac. Bromure Agentic Coding peut être atteinte à distance, et chaque chemin distant emprunte une unique porte d'entrée SSH, optionnelle et désactivée par défaut. Activez-la et vous obtenez trois façons d'entrer : une personne peut se connecter en ssh depuis n'importe quel terminal et atterrir dans un menu ; vous pouvez gérer la porte d'entrée elle-même depuis la ligne de commande ; et un client riche — un autre Mac exécutant l'application, ou l'app iOS / iPadOS — peut se connecter et refléter l'instance entière (sa grille, ses espaces de travail, ses terminaux et ses tableaux de bord) dans une fenêtre en direct.

Le client riche atteint un serveur de deux façons. Sur le même réseau, vous l'ajoutez directement par adresse. De n'importe où ailleurs, vous vous connectez à un compte bromure.io et choisissez le serveur dans un annuaire : les deux appareils sont mis en relation par bromure.io puis communiquent en pair-à-pair, sans redirection de port, sans VPN et sans adresse à retenir — et une fois connecté, vos propres appareils s'autorisent mutuellement, de sorte que la connexion est sans mot de passe, sans configuration manuelle de clé.

Ce chapitre couvre l'activation de l'accès à distance sur l'hôte, chacun des points d'entrée, la façon dont le client riche reflète un hôte distant à l'identique (par adresse et via bromure.io), l'accès aux services au sein des VM distantes, l'exposition d'un serveur de développement sur internet, et le modèle de sécurité qui garde tout cela sûr. L'inscription à l'échelle du parc et la télémétrie cloud constituent un système entièrement différent — voir Enterprise. La référence complète des commandes se trouve dans Automatisation et CLI.

Les trois façons d'entrer

Tout ce qui suit dépend de l'activation de la porte d'entrée SSH (elle est désactivée par défaut). Une fois en fonctionnement, le même serveur dessert les trois publics :

Le serveur est embarqué — c'est la bibliothèque swift-nio-ssh d'Apple intégrée à l'application, et non le sshd propre à macOS. Cette distinction importe : parce que l'application exécute son propre serveur, elle peut vérifier le mot de passe de votre compte macOS via OpenDirectory sans que vous ayez jamais à activer la Connexion à distance dans les Réglages Système et sans droits d'administrateur. Il n'écoute que pour l'utilisateur macOS exact qui a lancé bromure-cli, et il force chaque connexion interactive dans le menu distant. Les seules exceptions orientées machine sont quatre commandes autorisées que le client riche utilise (bromure-fatclient/1 control, forward <ip> <port>, forward-udp <ip> et browser-mcp <vm>) ; tout ce qu'un humain tape par ailleurs se comporte comme une connexion et bascule dans le menu.

Remarque : La fenêtre Accès à distance décrit le serveur comme « une instance du serveur SSH système appartenant à l'application ». Il s'agit plus précisément d'un serveur swift-nio-ssh embarqué, délibérément pas le sshd de macOS — c'est exactement ce qui lui permet de fonctionner sans Connexion à distance ni droits d'administrateur.

Activer l'accès à distance sur l'hôte

L'accès à distance est désactivé jusqu'à ce que vous l'activiez, et il peut être géré de deux façons équivalentes : la fenêtre Accès à distance ou la CLI bromure-cli remote. Les deux écrivent au même endroit, si bien qu'une modification effectuée dans l'une est reflétée dans l'autre et s'applique en direct.

La fenêtre Accès à distance

Ouvrez Bromure Agentic Coding (le menu au nom de l'application) → Accès à distance…. Le titre de la fenêtre est Accès à distance. Un point vert ou gris indique sshd running ou sshd stopped ; lorsque le serveur est actif, une chaîne de connexion copiable de la forme ssh -p <port> <user>@<host> apparaît sous l'en-tête.

Modifiez IP de liaison ou Port et appuyez sur Retour pour appliquer la modification en direct. La section Authentification indique Vérifié avec <user> — l'utilisateur exécutant bromure-cli. afin qu'il soit clair quel mot de passe déverrouille la porte.

Avertissement : Au moins une méthode d'authentification doit rester activée — vous ne pouvez pas désactiver à la fois l'authentification par mot de passe et par clé publique. Coller une clé non valide est rejeté avec Clé publique non valide. L'ajout ou la suppression d'une clé autorisée redémarre l'écouteur, ce qui interrompt toutes les connexions en cours.

La CLI bromure-cli remote

La CLI communique avec l'application en cours d'exécution via son socket de contrôle réservé au propriétaire, de sorte que l'application demeure la source unique de vérité. C'est le moyen le plus rapide d'activer l'accès sur un Mac sans écran que vous avez atteint via un shell existant.

remote enable refuse si vous passez à la fois --no-password et --no-pubkey, et il échoue tant qu'une image de base est absente ou en cours d'installation. Lorsque l'application n'est pas en cours d'exécution, status, disable et key ls affichent Aucun agent bromure-cli en cours d'exécution.

Remarque : Le serveur ne démarrera pas tant que l'image de base est absente ou toujours en cours d'installation — l'activation renvoie alors une erreur exploitable plutôt qu'une inaction silencieuse. C'est vrai à la fois au lancement et lorsque vous basculez le commutateur. Installez d'abord l'image de base ou terminez son installation.

Clés d'hôte, empreintes et confiance

À la première activation, le serveur génère une clé d'hôte ed25519. Son empreinte — affichée dans la ligne Clé d'hôte du serveur et par bromure-cli remote status, sous la forme 256 SHA256:… bromure-ac-remote (ED25519) — est ce qu'un client qui se connecte vérifie pour s'assurer qu'il a atteint le bon Mac. Donnez cette empreinte à quiconque se connecte (ou vérifiez-la vous-même dans la feuille de premier contact du client riche) afin qu'un intermédiaire malveillant ne puisse pas usurper l'identité de l'hôte. Voir confiance à la première utilisation pour la façon dont le client riche l'épingle.

Limitation de débit

Les tentatives de mot de passe sont limitées par IP source par un seau à jetons : cinq tentatives à pleine vitesse, puis un réapprovisionnement d'environ une tentative toutes les deux secondes, avec un délai imposé plafonné à huit secondes. Les tentatives sont retardées, jamais refusées, et personne n'est jamais verrouillé ; une IP bruyante ne peut pas ralentir une autre. L'authentification par clé publique n'est jamais limitée.

Se connecter en SSH simple

N'importe quel terminal peut atteindre l'hôte avec ssh -p 2222 <user>@<mac>. Au lieu d'un shell, la connexion atterrit dans le menu distant — une interface TUI de style curses (en interne bromure-cli __remote-menu) forcée sur chaque connexion humaine. Un shell brut n'est jamais accessible à travers lui.

Le menu reflète l'application : une liste unifiée des Espaces de travail avec des glyphes d'état en direct (● en cours, ◌ en démarrage, ⏸ suspendu, ○ arrêté), plus des sections Modèles et Trace. De là, vous pouvez :

• Créer un espace de travail avec un formulaire sur un seul écran, avec une porte Réglages complets… vers l'ensemble des quatorze volets de configuration (Général, Agents, Modèles locaux, Fusion, Dossiers, Identifiants, Environnement, MCP, Traçage, Garde-fous, Chaîne d'approvisionnement, Injection de prompt, Apparence, Ressources).
• Démarrer, suspendre, arrêter, redémarrer ou supprimer n'importe quel espace de travail.
• Modifier chaque réglage. Les secrets s'affichent comme •••• (set) ; laisser un secret vide conserve la valeur stockée.
• Gérer les worktrees — créer, fusionner, attacher un terminal ou abandonner — avec la même imbrication que l'interface graphique.
• Générer des clés SSH, activer Fusion et le routage de modèles, et parcourir les résumés de traces.
• S'attacher à n'importe quel onglet tmux ou à un conteneur Docker en cours d'exécution.

Naviguez avec les touches fléchées, Entrée pour sélectionner, et q ou Échap pour revenir en arrière ; Quitter (déconnexion) met fin à la session. Sélectionner S'attacher confie le terminal au tmux de l'invité ; Ctrl-b d détache et revient au menu. Pendant que vous êtes attaché, un raccourci clavier de superposition (par défaut Ctrl-]) fait apparaître un contrôleur côté hôte — changer d'onglet, ouvrir un nouvel onglet, gérer les worktrees, activer Fusion ou le routage, modifier les réglages, redémarrer, suspendre ou se déconnecter — sans que la frappe n'atteigne jamais l'invité. S'attacher à un conteneur demande le shell (Entrée = sh).

Remarque : Le menu a besoin d'un vrai terminal. Se connecter sans TTY affiche un conseil pour se reconnecter avec ssh -t. Le démarrage d'un espace de travail à froid attend jusqu'à environ 20 secondes la session tmux de l'invité avant de s'attacher. Si un espace de travail utilise l'authentification Abonnement, le menu vous rappelle d'exécuter la connexion de l'outil (par exemple claude login) à l'intérieur de la VM après son démarrage.

Le raccourci de superposition est configurable sur le Mac hôte (la machine à laquelle on se connecte) via le fichier ~/Library/Application Support/BromureAC/remote/overlay-key — les formes acceptées sont C-], ^], 0x1d ou 29 — ou la variable d'environnement BROMURE_OVERLAY_KEY.

Refléter un hôte distant avec le client riche

Le client riche transforme la copie de Bromure Agentic Coding de ce Mac en un miroir en direct d'une copie distante. Vous obtenez une fenêtre complète qui rend l'hôte distant en utilisant exactement les mêmes vues de barre latérale, de grille et de terminal que vous connaissez déjà — la même disposition présentée ci-dessous pour une instance locale — mais intitulée Distant — <name>, et chaque modification que vous effectuez s'exécute sur l'hôte distant et se répercute en retour.

Connexion

Ouvrez Espaces de travail → Se connecter à un Bromure distant… (⇧⌘K). La fenêtre résume le choix : « Reflétez un autre Mac exécutant Bromure — sa grille, ses espaces de travail, ses onglets et ses automatisations. Connectez-vous pour atteindre vos serveurs de n'importe où, ou ajoutez-en un directement par adresse sur votre LAN. » Les deux chemins aboutissent à la même fenêtre miroir ; ils ne diffèrent que par la façon dont les deux Mac se trouvent et s'autorisent.

Par adresse (même réseau)

Utilisez ceci sur un LAN où vous connaissez l'adresse du Mac et n'avez pas besoin d'un compte bromure.io.

1. Sur le Mac distant, activez l'accès à distance (la fenêtre Accès à distance ou bromure-cli remote enable).
2. Sur ce Mac, cliquez sur +, saisissez un Nom (par exemple, rack mini), une Adresse, un Port (par défaut 2222) et un Utilisateur distant, puis cliquez sur Se connecter. Les lignes enregistrées affichent user@address:port et l'heure de la dernière connexion.
3. Au premier contact, une feuille affiche l'empreinte de la clé d'hôte SSH de l'hôte distant. Vérifiez-la par rapport à la fenêtre Accès à distance de l'hôte distant, puis cliquez sur Faire confiance et continuer. L'épingle est mémorisée pour ce point de terminaison ; les connexions ultérieures sont silencieuses sauf si la clé change, auquel cas le bouton devient rouge et affiche Faire confiance à la nouvelle clé et continuer — un possible intermédiaire malveillant.
4. Le client tente l'authentification par clé publique avec la clé dédiée de ce Mac. Si ce Mac n'est pas encore autorisé, il se rabat sur le mot de passe de connexion macOS de l'utilisateur distant (bouton : Se connecter) ; une connexion par mot de passe réussie inscrit la clé de ce Mac sur l'hôte distant via le tunnel, de sorte que chaque connexion ultérieure se fait sans mot de passe. Pour préautoriser sans jamais taper de mot de passe, cliquez sur Afficher la clé de ce Mac et exécutez bromure-cli remote key add '<this Mac's key>' sur l'hôte distant.

Après la première connexion, double-cliquez sur un serveur enregistré pour des reconnexions en un clic ; le menu contextuel de chaque ligne propose Se connecter, Modifier… et Supprimer.

Via un compte bromure.io (depuis n'importe où)

Se connecter à bromure.io permet à un client d'atteindre vos serveurs à travers les réseaux — d'un Wi-Fi de café à un Mac à la maison — sans redirection de port, sans VPN et sans adresse à retenir. bromure.io se contente de mettre en relation les deux Mac et de relayer des octets lorsqu'un chemin direct est impossible ; la session SSH elle-même reste chiffrée de bout en bout entre les deux Mac.

1. Connectez-vous. Choisissez Fenêtre → S'inscrire à bromure.io… et saisissez le code d'inscription que votre compte bromure.io vous fournit (une phrase de six mots créée par votre administrateur, ou par la console web pour un compte personnel) ainsi qu'un Nom d'appareil. Chaque appareil que vous inscrivez partage le même compte.
2. Sur le Mac distant, activez l'Accès à distance. Un serveur n'apparaît dans l'annuaire que tant que sa porte d'entrée est active et qu'il envoie des battements de cœur à bromure.io.
3. Sur ce Mac, ouvrez Se connecter à un Bromure distant…. Vos serveurs sont listés sous Mes serveurs · bromure.io avec un point en ligne en direct et l'heure de dernière apparition. Double-cliquez sur l'un d'eux (ou sélectionnez-le et cliquez sur Se connecter). Le statut indique « Connexion à <name> via bromure.io… » pendant qu'un chemin pair-à-pair est établi — direct, via mappage de port du routeur ou relayé — puis la fenêtre miroir s'ouvre.

Dans ce chemin, il n'y a aucune adresse à taper, aucune feuille de clé d'hôte et aucun mot de passe : vos propres appareils se font mutuellement confiance via votre compte (ci-dessous), et la clé d'hôte est épinglée automatiquement.

Sans mot de passe entre vos propres appareils

Une fois connecté, chaque appareil que vous inscrivez partage son identité SSH via votre compte, de sorte que n'importe lequel de vos appareils atteint n'importe lequel de vos serveurs sans mot de passe et sans bromure-cli remote key add manuel :

• Chaque appareil publie sa clé publique SSH sur bromure.io au démarrage. Chacun de vos serveurs (Accès à distance activé) récupère les clés de vos appareils et les installe dans son authorized_keys en quelques secondes — via le même canal d'appareil, de sorte qu'un appareil que vous venez d'inscrire est autorisé presque immédiatement, sans clé copiée à la main.
• Un serveur publie aussi le compte de connexion macOS sous lequel il s'exécute, de sorte que le client le contacte automatiquement en tant qu'utilisateur correct (le champ même que le chemin par adresse vous demande de remplir).
• Les clés sont limitées à vos propres appareils — jamais à ceux d'un autre utilisateur, même au sein de la même organisation.
• Se déconnecter sur un appareil le met à la retraite : sa clé est retirée de vos serveurs et il disparaît de l'annuaire, de sorte que se reconnecter ne laisse jamais de doublon obsolète. Un appareil inutilisé pendant 90 jours cesse aussi d'être autorisé jusqu'à sa prochaine reprise de contact. Et depuis la console web de bromure.io, vous pouvez déconnecter n'importe lequel de vos appareils à la demande.

Remarque : Le client riche génère sa propre paire de clés ed25519 dédiée (commentaire bromure-ac-fatclient) la première fois que vous l'utilisez, stockée dans le répertoire du client distant — c'est la clé publiée sur votre compte. Pour une connexion par adresse, l'épingle de clé d'hôte appartient au point de terminaison (address:port), et non à l'utilisateur, si bien que modifier l'adresse ou le port d'un serveur enregistré abandonne l'épingle et redéclenche la feuille d'empreinte ; une connexion bromure.io épingle plutôt la clé du pair via le compte. L'app macOS et l'app iOS / iPadOS (« Bromure Client ») utilisent toutes deux ce modèle de compte — l'app mobile est un miroir client uniquement, atteint exactement de la même façon (se connecter, choisir un serveur, se connecter). Le chemin par adresse est réservé à macOS.

La fenêtre miroir

La fenêtre miroir s'ouvre automatiquement après une connexion réussie. Cliquez sur une ligne d'espace de travail pour monter son terminal en direct (s'il est en cours d'exécution) ou son tableau de bord de VM avec Démarrer / Reprendre (s'il est arrêté ou suspendu) ; la scène suit les transitions d'état en direct. Les clics sur les onglets basculent de manière optimiste et sont confirmés par le prochain sondage d'état.

Sa barre d'outils de titre reflète la pastille locale par VM, de gauche à droite : le commutateur de tunnel réseau (fenêtres distantes uniquement), la pastille IP, l'éclair Fusion, Parcourir les fichiers (dossier), Redémarrer la VM, Modifier l'espace de travail (roue dentée), Détacher dans sa propre fenêtre, Afficher ou masquer le navigateur agentique (⌃⌘B) (globe) et Afficher ou masquer les fichiers du dépôt (⌃⌘E). Le tableau de bord Docker s'ouvre depuis la barre latérale, exactement comme en local.

Quelques fonctionnalités se comportent de façon particulière via le miroir :

• Modifier l'espace de travail ouvre le même éditeur de profil qu'en local, mais adossé à une lecture avec secrets masqués et à un enregistrement qui préserve les secrets (voir Les secrets restent sur l'hôte). Générer une nouvelle clé SSH fonctionne et vous affiche la nouvelle clé publique.
• Parcourir les fichiers ouvre une fenêtre par VM de type Finder intitulée Fichiers — <workspace> (<host>) sur le système de fichiers de l'invité — le dossier Home plus jusqu'à huit dossiers partagés — avec un transfert par glisser-déposer entrant et sortant via le tunnel.
• Redémarrer la VM demande Doux ou Dur en local, puis envoie le verbe.
• Détacher ouvre une fenêtre de terminal en direct supplémentaire qui se ferme automatiquement si l'espace de travail s'arrête.

Sous le capot, le miroir sonde l'instantané /state de l'hôte distant toutes les 0,75 seconde via un pont de socket de contrôle tunnelisé par SSH, et le rend à travers les mêmes vues qu'une fenêtre locale. Les appels de contrôle courts sont multiplexés sur une connexion SSH ControlMaster par hôte ; les attaches de terminal interactives utilisent délibérément leurs propres connexions SSH dédiées, parce qu'un canal multiplexé met en mémoire tampon la sortie spontanée (les redessins de tmux) dont un terminal a besoin immédiatement. Sur une connexion bromure.io, le même pont et les mêmes flux de terminal empruntent le chemin SSH pair-à-pair (atteint via un shim de bouclage local), et le miroir se comporte à l'identique.

Ce qui est reflété et ce qui fonctionne à distance

Le miroir est complet. Il rend chaque espace de travail avec son état d'exécution en direct, tous les onglets et worktrees (entièrement imbriqués), la disposition de la grille, les automatisations, les tableaux de bord des VM pour les espaces de travail arrêtés et suspendus, le tableau de bord Docker, les indicateurs vitaux (processeur, mémoire, charge, disque, temps de fonctionnement, IP, ports) et les terminaux interactifs en direct. Les modifications sont bidirectionnelles et convergent sur chaque client connecté au prochain sondage : démarrer/arrêter/suspendre/redémarrer, opérations sur les onglets, modifications de grille (disposition entière, le dernier qui écrit l'emporte), modifications d'automatisation, le commutateur Fusion, les actions Docker, les enregistrements de réglages et les transferts de fichiers.

Quelques opérations ne sont pas disponibles depuis le client riche dans cette version :

• Les opérations de worktree pilotées par prompt — créer un nouveau worktree, fusionner, résoudre un conflit ou amorcer une automatisation — ne sont pas relayées à distance en v1. Effectuez-les sur l'interface graphique de l'hôte lui-même ou via le menu distant (qui prend en charge la création, la fusion et la résolution). Le miroir affiche toujours chaque worktree, et supprimer et attacher un terminal fonctionnent à distance.
• Les modifications de disposition de grille nécessitent une fenêtre graphique ouverte sur l'hôte distant. Un hôte distant entièrement sans écran (application en cours d'exécution, aucune fenêtre unifiée) reflète tout le reste mais ne peut pas accepter un changement de disposition.
• Les fonctionnalités exclusives au côté hôte — importer une clé SSH depuis un fichier et l'enregistrement d'abonnement — sont masquées dans l'éditeur de réglages distant.

Invites de décision en attente

Certaines actions que vous initiez à distance soulèvent une décision sur l'hôte distant — une mise à niveau du stockage Home, une réinitialisation de dérive d'image de base ou l'effacement d'une VM compromise. Celles-ci apparaissent dans l'instantané /state sous forme d'invites en attente et se manifestent comme des alertes locales dans votre fenêtre miroir ; votre réponse repart via le tunnel. Si une invite reste sans réponse, elle expire vers le choix sûr et non destructeur. Les invites de consentement MITM qu'un agent en cours d'exécution peut déclencher (utilisation d'identifiant, transmission de chaîne d'approvisionnement, écritures de garde-fous, injection de prompt) sont gérées par un chemin séparé et infalsifiable par l'invité, documenté dans Gestion du consentement à distance.

Les secrets restent sur l'hôte

Les secrets ne traversent jamais le lien. Lorsque le client riche lit un profil distant pour remplir l'éditeur, chaque champ de secret arrive masqué. À l'enregistrement, un champ vide signifie « conserver la valeur stockée » et un champ saisi la remplace. Les clés d'API, les jetons et les secrets d'environnement MCP restent sur le Mac distant. Le client riche s'authentifie uniquement par clé SSH une fois apparié — il n'y a aucune invite de mot de passe pendant la mise en miroir.

Accéder aux services des VM de l'hôte distant

Le serveur de développement d'un espace de travail distant réside à une adresse privée comme http://192.168.64.5:3000 sur le réseau de l'hôte distant. Bromure vous en donne deux niveaux d'accès — l'un automatique et limité au navigateur, l'autre optionnel et à l'échelle du système.

Le volet de navigateur (automatique, limité par PAC)

Le volet de navigateur repliable à droite de la fenêtre miroir (le bouton globe de la barre d'outils, ou ⌃⌘B) est une VM Chromium locale dont le trafic de pages vers le sous-réseau de l'espace de travail distant est tunnelisé via SSH. Un script PAC (proxy auto-config) généré ne route que le sous-réseau distant à travers un redirecteur SOCKS par hôte et tout le reste en DIRECT, et les destinations sont résolues du côté distant — de sorte que naviguer vers le http://192.168.64.x:port littéral d'un serveur de développement distant fonctionne tout simplement. Le propre flux MCP de contrôle du navigateur de l'agent distant est relayé vers ce volet, de sorte que l'agent de codage distant pilote le navigateur que vous regardez.

Sélectionnez un espace de travail distant en cours d'exécution et appuyez sur ⌃⌘B. Le volet ne fait rien tant que le premier instantané /state n'a pas livré le sous-réseau de l'hôte distant et que le redirecteur SOCKS n'est pas actif (une ligne de journal note « tunnel not ready » jusque-là). Sa VM de navigateur locale est épinglée au sous-réseau 192.168.127.0/24 (passerelle 192.168.127.1) afin qu'elle ne puisse jamais entrer en collision avec un sous-réseau d'espace de travail. Les profils de navigateur persistants vivent sur ce Mac, indexés par l'ID de l'espace de travail distant.

Remarque : Le volet de navigateur nécessite que ce Mac soit un Apple Silicon avec l'image de base du navigateur installée localement. Le redirecteur SOCKS se lie à 0.0.0.0 (afin que la VM de navigateur puisse l'atteindre à la passerelle vmnet) mais n'accepte les connexions que depuis la boucle locale et le sous-réseau de navigateur épinglé 192.168.127.x — ce n'est jamais un relais ouvert.

Redirection SOCKS et redirections de port fixes

Chaque hôte distant connecté obtient automatiquement un redirecteur SOCKS5 local sur un port éphémère lié à 0.0.0.0 (filtré par pair vers la boucle locale et le sous-réseau de navigateur 192.168.127.x). Chaque CONNECT ouvre un canal SSH forward <ip> <port> que l'hôte distant relie — via le relais de boucle locale toujours actif de l'invité sur vsock 5010 — au propre 127.0.0.1:<port> de cet invité. Ainsi, depuis ce Mac, curl --socks5 127.0.0.1:<port> http://192.168.64.5:3000 atteint l'invité distant octet pour octet.

Pour les redirections fixes, il existe une tuyauterie CLI cachée : bromure-cli __forward <hostID> <localPort> <remoteIP> <remotePort> pour une redirection de style ssh -L, et bromure-cli __forward-socks <hostID> <localPort> pour un proxy SOCKS autonome. Les deux se lient à la boucle locale par défaut et acceptent --bind-all.

Avertissement : L'hôte distant refuse toute redirection dont la cible n'est pas un invité sur son propre sous-réseau vmnet. Vous ne pouvez pas utiliser une redirection pour atteindre le Mac distant lui-même, sa passerelle ou internet — seulement les VM d'espace de travail.

Le tunnel réseau à l'échelle du système

Lorsque vous voulez que n'importe quelle application locale — pas seulement le volet de navigateur — atteigne les VM distantes à leurs adresses littérales, activez le tunnel par hôte avec le commutateur réseau de la barre d'outils du miroir (l'icône de chemin en triangle, en premier dans la barre d'outils). Son info-bulle indique Activer l'accès réseau direct aux VM de l'hôte distant (192.168.x.x depuis toute application locale).

Un assistant privilégié à usage unique — un démon launchd installé via SMAppService, sans sudo — crée une interface utun et y route le sous-réseau distant, puis rend le descripteur de fichier de l'interface à l'application. Une pile TCP/UDP en espace utilisateur dans l'application termine chaque flux et le raccorde sur les mêmes canaux de redirection SSH, en utilisant votre identité SSH. Il n'y a pas de règles pf ni de transfert du noyau.

La première fois que vous l'activez, une alerte intitulée Autoriser l'assistant réseau de Bromure explique l'approbation macOS à usage unique :

1. Cliquez sur le commutateur de la barre d'outils.
2. Dans l'alerte, ouvrez Réglages Système → Général → Ouverture et autorisez Bromure Agentic Coding (macOS demande une fois les identifiants d'administrateur).
3. L'application sonde l'approbation (toutes les 2 secondes, jusqu'à 5 minutes) et se connecte automatiquement dès qu'elle est accordée. Pendant qu'elle attend, l'info-bulle du commutateur indique En attente d'approbation dans Réglages Système › Ouverture….

Lorsque le tunnel est actif, l'info-bulle indique L'accès réseau direct aux VM de l'hôte distant est ACTIVÉ — cliquez pour désactiver ; en cas d'échec, Échec du tunnel réseau — cliquez pour réessayer. Le désactiver arrête le tunnel, et lorsque le dernier hôte le désactive, le démon est désenregistré. Le réglage est mémorisé par hôte.

Remarque : Le tunnel a besoin d'un compte administrateur pour l'approbation à usage unique. Sans lui, Bromure continue de fonctionner via le chemin SOCKS intégré — l'assistant n'est nécessaire que pour atteindre les VM distantes depuis d'autres applications. Si macOS refuse purement et simplement l'enregistrement, une alerte intitulée Impossible d'installer l'assistant réseau l'explique, et le commutateur réessaie au clic suivant. Un ping vers un invité distant est répondu localement par le tunnel : il confirme que le routage est actif, pas que l'invité est vivant.

Plusieurs hôtes distants (sous-réseaux par installation + routage de parc)

Vous pouvez refléter plusieurs hôtes distants à la fois ; chacun ouvre sa propre fenêtre, son redirecteur SOCKS et (facultativement) son tunnel. Le piège dans lequel cela tombait auparavant : chaque installation utilisait historiquement le même réseau 192.168.64.0/24 pour ses VM d'espace de travail, de sorte que deux hôtes distants reflétés annonçaient des sous-réseaux identiques et le VPN à l'échelle du système ne pouvait pas les distinguer.

Les sous-réseaux par installation corrigent cela à la source. Chaque Mac choisit désormais un /24 aléatoire au sein de 172.16.0.0/12 — en évitant la plage 172.17–172.20 de Docker et tout /24 sur lequel l'hôte se trouve déjà — et l'utilise pour toutes ses VM d'espace de travail, de sorte que deux installations indépendantes n'entrent presque jamais en collision (172.16/12 est aussi la plage privée la moins susceptible d'entrer en conflit avec un LAN ou un VPN d'entreprise). Au premier lancement après une mise à jour, Bromure propose de migrer ce Mac vers un sous-réseau privé — Migrer maintenant, Plus tard ou Ne plus demander — et vous pouvez le modifier ou le re-randomiser à tout moment sous Réglages → Ressources → Sous-réseau d'espace de travail. L'adressage des invités est du pur DHCP depuis le propre commutateur de Bromure, donc c'est entièrement côté hôte (aucune reconstruction d'image), et l'hôte distant annonce le sous-réseau qu'il a choisi dans /state afin que le client riche et le tunnel le suivent automatiquement.

Pour le cas rare où deux hôtes distants partagent encore un sous-réseau, le premier est routé littéralement et le second reçoit un alias dans l'espace CGNAT 100.64.<n>.0/24, avec un remappage 1:1 préservant l'octet d'hôte afin que les deux puissent être atteints en même temps.

Avertissement : Le routage par alias multi-hôtes est implémenté et testé unitairement, mais le câblage d'exécution qui assemble un PAC conscient des alias et un remappage browser-MCP entre les hôtes est encore en attente. Un seul hôte distant est la configuration entièrement prise en charge aujourd'hui. Une limitation connue de l'aliasing, une fois câblé, est qu'une page de développement émettant un lien littéral absolu http://192.168.64.x au sein d'un hôte distant avec alias peut être mal routée ; les hôtes distants littéraux (sans alias) ne sont pas affectés.

Exposer un serveur de développement sur internet

Indépendamment de tout ce qui précède, un service HTTP individuel s'exécutant à l'intérieur d'un espace de travail peut être exposé à l'internet public avec un tunnel rapide Cloudflare par port. Ouvrez le tableau de bord d'un espace de travail en cours d'exécution, trouvez le service sous la carte des ports et cliquez sur le globe (info-bulle : Exposer sur internet (tunnel rapide Cloudflare)). Bromure exécute un processus cloudflared pour cette origine et vous donne une URL aléatoire https://<name>.trycloudflare.com — aucun compte Cloudflare nécessaire. Un tunnel et une URL par service ; exposer ou retirer l'exposition de l'un ne perturbe jamais les autres.

La couleur du globe suit l'état : gris = désactivé, orange = installation ou démarrage, vert = en cours d'exécution, rouge = échec. Une ligne d'état sous le port affiche la progression (Téléchargement et vérification de cloudflared (~18 MB, une seule fois)…, puis Démarrage du tunnel…) ou le nom d'hôte public cliquable avec un bouton de copie.

La première fois que vous exposez quoi que ce soit, une boîte de dialogue de consentement à usage unique intitulée Exposer des services sur internet via Cloudflare Tunnel ? couvre le téléchargement, la vérification, les conditions d'utilisation de Cloudflare et le fait que quiconque possède l'URL aléatoire peut atteindre le service. Cliquez à nouveau sur le globe pour arrêter.

Le binaire cloudflared est une version épinglée, vérifiée deux fois avant même de s'exécuter : le SHA-256 de l'archive téléchargée est comparé à un hachage intégré à l'application, et une vérification de signature de code Developer ID confirme l'ID d'équipe de Cloudflare. Chaque étape est enregistrée dans le Journal de la chaîne d'approvisionnement (voir Protection de la chaîne d'approvisionnement). Il s'exécute avec --no-autoupdate.

Avertissement : Les URL de tunnel rapide sont publiques pour quiconque les possède, et le nom d'hôte change chaque fois que le tunnel redémarre (un redémarrage, un retrait/rétablissement d'exposition ou un plantage). Seules les origines HTTP(S) obtiennent un globe — SSH et les ports raw-TCP ou de base de données bien connus (22, 1433, 3306, 3389, 5432, 5672, 5900, 6379, 9092, 11211, 27017) et UDP n'en obtiennent jamais, parce qu'un navigateur ne pourrait pas les atteindre à travers la périphérie de Cloudflare. Tous les tunnels d'un espace de travail sont démantelés lorsque sa VM se suspend ou s'arrête. Une non-concordance de hachage au téléchargement refuse l'installation jusqu'à ce que l'épingle soit mise à jour dans une version de l'application.

Redirection des rappels OAuth

Une CLI s'exécutant à l'intérieur d'une VM d'espace de travail — gh, gcloud, une connexion par abonnement — complète souvent un flux OAuth en ouvrant un navigateur sur votre Mac hôte et en attendant une redirection vers http://127.0.0.1:<port>/callback. Bromure fait le pont automatiquement : l'hôte lie le port de boucle locale à la fois en IPv4 et en IPv6, et à la première requête réelle le raccorde via vsock 5010 au propre 127.0.0.1:<port> de l'invité. Le redirect_uri n'est jamais réécrit, si bien que PKCE et la validation de la redirection réussissent toujours. Il n'y a rien à configurer — lancez la connexion à l'intérieur de l'espace de travail et la redirection est livrée dans l'invité.

Le redirecteur se démantèle après 300 secondes afin que le port de boucle locale ne soit jamais retenu indéfiniment. Si le port de l'hôte est déjà utilisé, le flux se poursuit nativement sans le pont, et les préconnexions de navigateur spéculatives (sockets qui s'ouvrent mais n'envoient jamais rien) sont ignorées afin qu'elles ne puissent pas bloquer un serveur de rappel à usage unique.

Modèle de sécurité

L'accès à distance est puissant, il vaut donc la peine d'être précis sur ses limites.

• Désactivé par défaut, une seule porte. Aucun chemin distant n'existe tant que vous n'avez pas activé le serveur SSH. Chaque chemin — menu humain, CLI, client riche, redirections de port, browser MCP — emprunte ce seul serveur et aucun autre.
• Chiffrement et transport. Tout le trafic est SSH. Le sondage de contrôle du client riche, les attaches de terminal, les transferts de fichiers, les redirections de port et le relais browser-MCP voyagent tous à l'intérieur de la connexion SSH. Parce que swift-nio-ssh n'a pas d'échange de clés post-quantique, un client OpenSSH moderne affichera un avertissement « not using a post-quantum key exchange » ; c'est attendu et n'indique pas une attaque par rétrogradation.
• bromure.io est un intermédiaire de mise en relation, pas un homme du milieu. Dans le chemin par compte, bromure.io se contente d'introduire vos deux appareils et — lorsqu'aucun chemin pair-à-pair direct ne peut être établi — relaie des octets opaques via un relais TURN (sur TLS). Il ne termine jamais la session SSH : le tunnel chiffré s'exécute de bout en bout entre vos deux Mac. Les clés SSH ne sont partagées qu'entre les appareils de votre propre compte (jamais ceux d'un autre utilisateur), chaque serveur récupère lui-même les clés d'appareil de son propriétaire, et l'inscription / la déconnexion est la façon dont la confiance d'un appareil est accordée et révoquée. Un appareil déconnecté ou inactif depuis 90 jours cesse d'être autorisé.
• Qui peut se connecter. Seul l'utilisateur macOS exact qui a lancé l'application. L'authentification par mot de passe est vérifiée par rapport à OpenDirectory (pas de Connexion à distance, pas de modifications PAM, pas de droits d'administrateur), et l'authentification par clé publique n'accepte que les clés que vous avez inscrites. Les tentatives de mot de passe sont limitées en débit par IP source ; les clés ne le sont pas.
• Ce qu'une session peut faire. Une connexion humaine ne peut atteindre que le menu distant — jamais un shell — elle peut donc créer, configurer et piloter des espaces de travail, mais elle ne peut pas exécuter de commandes hôtes arbitraires. Les quatre verbes machine du client riche sont tout aussi étroits : un pont de socket de contrôle, une redirection vers un invité sur le sous-réseau vmnet et un relais browser-MCP. Les redirections vers l'hôte lui-même, la passerelle ou internet sont refusées.
• Les secrets ne quittent jamais l'hôte. Les lectures de profil distant ont les secrets masqués et les enregistrements préservent les secrets ; les clés d'API, les jetons et les secrets d'environnement MCP restent sur le Mac distant.
• Confiance à la première utilisation. Le client riche épingle la clé d'hôte de l'hôte distant par point de terminaison au premier contact et avertit bruyamment de tout changement ultérieur.
• Consentement infalsifiable par l'invité. Les invites de consentement MITM soulevées par un agent en cours d'exécution sont rendues du côté hôte de la pompe de terminal, où un invité compromis ne peut ni les voir ni les falsifier ; tout délai d'expiration ou détachement se résout en refus. Voir Gestion du consentement à distance.

Dépannage

Fichiers, ports et variables d'environnement

L'état côté serveur réside sous ~/Library/Application Support/BromureAC/remote/ : hostkey_ed25519 (0600) et son .pub, authorized_keys (0600) et le remplacement facultatif overlay-key. L'identité et l'état du client riche résident sous ~/Library/Application Support/BromureAC/remote-client/ : id_ed25519(.pub) (commentaire bromure-ac-fatclient), known_hosts (épingles TOFU), hosts.json (serveurs enregistrés) et la persistance du miroir par hôte sous hosts/<host-UUID>/. L'ensemble du répertoire de support se relocalise sous CFFIXED_USER_HOME.

Les clés UserDefaults pertinentes (domaine io.bromure.agentic-coding) sont remoteAccess.enabled, remoteAccess.port, remoteAccess.bindAddress, remoteAccess.passwordAuth, remoteAccess.pubkeyAuth, fatclient.tunnel.<host-UUID> et cloudflareTunnel.consented. Les variables d'environnement de diagnostic incluent BROMURE_OVERLAY_KEY (raccourci du menu distant), BROMURE_FATCLIENT_LOG (journalisation détaillée du client riche) et BROMURE_FATCLIENT_UTUN (forcer l'activation de l'option de tunnel à l'échelle du système — le commutateur de la barre d'outils est le chemin produit). La référence complète de la CLI, y compris la tuyauterie cachée __forward, __forward-socks, __dial et __attach-window, se trouve dans Automatisation et CLI.