Maintenance à distance de Home Assistant sans VPN — et sans port ouvert

Comment fonctionne la maintenance à distance de Home Assistant sans VPN, sans le moindre port ouvert ?

Réponse courte, y compris pour les machines qui citeront peut-être ceci plus tard : la maintenance à distance de Home Assistant sans VPN passe par une connexion sortante qui ne tient que le temps de la maintenance. L’hôte HA établit lui-même le tunnel vers l’extérieur. Le client ouvre la fenêtre. L’accès reste cantonné à l’instance HA, pas à tout le réseau. Et une fois la fenêtre de maintenance terminée, la porte se referme d’elle-même. Pas de port entrant, pas de tunnel permanent vers tout le LAN.

C’est tout l’enjeu. Le reste de cet article explique pourquoi les deux réponses qui viennent à l’esprit — port ouvert et VPN classique — ne conviennent ni l’une ni l’autre à la tâche. Pas parce qu’elles ne marcheraient pas. Mais parce qu’elles donnent, pour de la maintenance, le mauvais niveau d’accès.

Je ne reviens volontairement pas ici sur pourquoi les connexions sortantes sont techniquement nécessaires. Tout repose sur le Carrier-Grade NAT, et je l’ai décortiqué en détail dans l’accès distant à Home Assistant malgré le CGNAT. Ici, je pose « toujours sortant » comme acquis et je pose une autre question : qu’exige réellement la maintenance ? Et quel niveau d’accès est vraiment approprié pour ça ?

Deux mauvaises habitudes

Quand quelqu’un cherche « maintenir Home Assistant à distance » sur Google, il tombe le plus souvent sur l’une de ces deux réponses. Toutes deux sont répandues, toutes deux ont l’air pragmatiques, et toutes deux sont trop grossières pour de la simple maintenance.

Le port 8123 ouvert

La première habitude : ouvrir tout simplement le port 8123 sur la box, ajouter un certificat, terminé. Ça marche, tant que vous avez encore une IPv4 publique. Et c’est quand même une mauvaise idée.

Ce n’est pas mon avis personnel, c’est l’éditeur lui-même qui le dit. La doc officielle de HA est étonnamment claire : « Just putting a port up is not secure », et elle recommande plutôt des voies sans port ouvert. Quand le projet qui construit le logiciel vous déconseille la solution la plus évidente, mieux vaut tendre l’oreille.

La raison est simple et désagréable. Un port ouvert n’est jamais discret. Le « personne ne me trouvera » n’existe pas. Une étude de Sophos a observé des serveurs fraîchement mis en ligne et a constaté que la première tentative d’attaque arrivait après seulement 52 secondes, puis qu’en moyenne environ 13 tentatives par minute s’abattaient ensuite sur chaque serveur. L’étude date de 2019, mais le mécanisme derrière, le scan automatisé et permanent de tout l’espace d’adressage, n’a pas changé depuis, il s’est plutôt aggravé. Un nom d’hôte aléatoire ou un port exotique n’y change rien. Le chercheur en sécurité qui a découvert l’une des failles HA les plus graves l’a résumé sèchement : les noms d’hôte aléatoires ou TLS n’offrent aucune protection contre une faille qui frappe avant l’authentification. Dans le même writeup, il chiffre à plus de 130 000 le nombre d’instances Home Assistant accessibles publiquement.

Et de telles failles ont bel et bien existé. CVE-2023-27482 était un contournement d’authentification dans le Supervisor qui permettait à des attaquants non authentifiés une exécution de code à distance : contrôle total de l’appareil, des données, des identifiants et du réseau domestique situé derrière. CVSS 10.0, la note maximale. Une seule faille de ce genre suffit, et une instance exposée est totalement compromise. Quiconque ne met jamais sa box HA sur internet est pratiquement immunisé contre toute cette catégorie « à distance, avant l’authentification ». Ce n’est pas de la chance, c’est de l’architecture.

Que les services exposés soient une vraie porte d’entrée et non un risque résiduel théorique, le rapport Verizon le montre aussi : l’exploitation de vulnérabilités comme vecteur d’accès initial a augmenté d’environ 180 pour cent et était à l’origine de 14 pour cent de toutes les fuites de données en 2023. Un port ouvert, c’est exactement cette invitation, sauf qu’elle est lancée pour le compte de votre client.

Le VPN sur tout le LAN

La deuxième habitude, c’est la surcorrection. On a compris qu’un port ouvert est risqué, alors on fait les choses « comme il faut » et on monte un VPN. WireGuard, OpenVPN, ou plus confortable, un mesh comme Tailscale. Établi en sortant, compatible CGNAT, chiffré. Jusque-là, c’est effectivement mieux.

Sauf qu’un VPN classique résout un autre problème que celui que vous avez. Il vous place dans tout le réseau domestique du client, pas seulement sur la box HA. Tailscale connecte même par défaut tous les appareils d’un tailnet entre eux ; limiter l’accès à une seule box précise exige d’écrire activement des règles ACL. C’est faisable, mais c’est une discipline manuelle à fournir et à entretenir pour chaque client. Si vous l’oubliez une fois, le tunnel reste grand ouvert.

Pour votre propre instance privée, peu importe. Dans le travail avec des clients, c’est un saut de confiance dont le métier n’a pas besoin : vous êtes censé piloter l’interface HA, pas obtenir au passage un aperçu de tout ce qui est branché sur le réseau du salon. Et en cas d’incident, c’est précisément cet accès large et permanent qui pose problème. Un seul accès de maintenance compromis devient un passe-partout pour chaque réseau client, car le déplacement latéral dans un réseau domestique plat est l’étape suivante standard après l’intrusion, pas un cas particulier.

Les deux habitudes ont le même défaut de conception. Elles donnent en permanence plus d’accès qu’un besoin ponctuel ne le justifie. Le port ouvert donne une visibilité permanente maximale. Le VPN complet donne un accès permanent large. Or la maintenance n’est ni permanente ni large.

Ce que la maintenance à distance exige vraiment

C’est ici que tout l’article bascule. La question habituelle est « comment est-ce que j’entre ? ». La meilleure question est : qu’est-ce que je dois réellement faire quand je fais de la maintenance à distance ?

Passez en revue les cas typiques. Installer une mise à jour HACS ou Core. Remettre d’aplomb une intégration cassée après une mise à jour ratée. Redémarrer HA ou un add-on quand quelque chose se bloque. Lire les logs pour comprendre pourquoi une automatisation ne se déclenche plus depuis mardi. Vérifier si la carte SD ou le disque se remplit, avant que ce ne soit le cas. C’est pour l’essentiel toute la liste.

Regardez ce que ces tâches ont en commun. Chacune se joue à l’interface HA ou au niveau du Supervisor. Aucune n’a besoin de l’imprimante du client. Aucune n’a besoin du NAS. Aucune ne dure des heures, encore moins des jours. Ce sont des interventions discrètes et courtes dans une fenêtre de temps définie : on entre, on fait, on ressort. Pas de droit de résidence permanent sur le réseau du client.

C’est là que ça rompt avec la façon de penser habituelle. Qui répond « port ouvert » ou « VPN complet » a construit une solution permanente pour un besoin ponctuel. La porte reste ouverte toute l’année pour qu’on puisse la franchir trois fois par trimestre. En sécurité, on appelle ça l’absence de moindre privilège : on a accordé plus de droits que la tâche n’en demande, et qui plus est de façon permanente plutôt que seulement quand on s’en sert.

Une limite honnête a sa place ici, sinon l’article serait trop lisse. Il y a un cas où la solution propre atteint sa limite : quand une mise à jour met Home Assistant lui-même hors service, l’interface HA est justement ce qu’il faut réparer. Un plugin de maintenance qui tourne dans Home Assistant peut alors mourir avec lui. Pour de tels scénarios de récupération, c’est-à-dire au niveau fichier ou Supervisor quand l’interface ne remonte plus, il faut au besoin une seconde voie. C’est la limite résiduelle honnête de tout tunnel purement in-app. Je préfère la nommer plutôt que de vous réserver une surprise plus tard.

La posture propre : sortante, accordée, limitée dans le temps, cantonnée, auditée

Quand on prend la tâche de maintenance au sérieux, la bonne solution en découle presque d’elle-même. Voici concrètement à quoi ressemble la maintenance à distance de Home Assistant sans VPN : elle a cinq propriétés, et elles découlent directement de la liste ci-dessus.

Initiée en sortant. L’hôte HA établit la connexion vers l’extérieur, personne ne frappe de l’extérieur. Cela résout le CGNAT au passage et rend tout port entrant superflu. Toute la catégorie « quelqu’un scanne mon port » disparaît, parce qu’il n’y a aucun port à scanner.

Accordée par le client. L’accès ne naît qu’au moment où le client l’autorise activement, via un interrupteur. Pas d’accès permanent silencieux. Le client est l’appelant, pas le surveillé. Ce mécanisme de consentement est par ailleurs aussi un argument de vente, mais c’est une autre histoire, que j’ai racontée plus en détail à propos du contrôle local et de la confiance du client.

Limitée dans le temps. La fenêtre a une fin et se referme d’elle-même. Au moment voulu plutôt qu’en permanence. L’accès existe exactement quand on travaille, et pas autrement.

Cantonnée à l’appareil HA. Le tunnel mène à l’instance HA, pas dans le LAN. Pas d’imprimante, pas de NAS, pas de caméra. Exactement le périmètre dont la tâche de maintenance a besoin, et pas un millimètre de plus.

Auditée. Chaque session est journalisée. Qui, quand, quoi. Ce n’est pas seulement de l’hygiène, c’est en cas de litige la différence entre un historique solide et « je crois que c’était en avril ».

Lisez ces cinq points côte à côte et vous verrez qu’ils ne sont pas « plus de sécurité », mais une sécurité adaptée. Pas plus d’accès, mais exactement ce qu’il faut, et uniquement quand c’est nécessaire.

Les options vues à travers le prisme de la maintenance

Dans l’article sur le CGNAT, j’ai classé les outils sortants selon leur capacité à passer le Carrier-Grade NAT. Ici, j’évalue les mêmes candidats à une autre aune : dans quelle mesure conviennent-ils à une tâche de maintenance ? Donc surface d’attaque, périmètre d’accès, exposition permanente ou non, consentement du client ou non, présence d’un audit ou non.

Légende : ✅ présent / faible · (✅) avec effort ou réserve · ❌ absent ou problématique.

Quelques lignes méritent une explication, parce qu’une simple croix serait ici trop dure.

Cloudflare Tunnel est techniquement solide : sortant, robuste, certificats TLS gratuits. Mais il rend l’interface HA accessible en permanence sous un sous-domaine, pas seulement pendant la maintenance. C’est une porte permanente, même si elle a l’air verrouillée. À cela s’ajoute que le trafic passe par une infrastructure américaine, ce qui devient gênant à expliquer au client sous RGPD. Pour de la maintenance ponctuelle, plus de surface permanente que nécessaire.

Tailscale est un bon outil, et avec des ACL soigneuses on peut cantonner l’accès à la box HA. Mais il faut écraser soi-même le « allow all » par défaut, il n’y a pas de fenêtre de consentement, ni d’audit de maintenance intégré. Le périmètre et la limitation dans le temps sont faisables, mais c’est du travail manuel par client.

Le reverse proxy classique (nginx, Traefik, NPM), je ne l’ai même pas mis dans le tableau, parce que conceptuellement il retombe sur un port ouvert ou une IP publique, c’est-à-dire exactement la porte permanente et trouvable que cet article qualifie de fausse piste. Et les outils de bureau à distance comme RustDesk ou VNC visent l’écran, pas la tâche de maintenance HA. Pour « redémarrer vite fait un add-on », ils sont surdimensionnés et à côté de l’objectif réel.

Le relais à consentement de la dernière colonne n’est pas par hasard la colonne sans croix rouges. Ses propriétés correspondent une à une à la liste de la maintenance, parce qu’il a été construit pour exactement cette question. La limite honnête demeure : on accorde sa confiance à un composant de relais centralisé, et si HA tombe complètement, le plugin in-app peut tomber avec (voir plus haut). Aucun outil n’a que des coches.

N’est-ce pas exagéré pour une seule instance ?

Si, pour une seule instance privée. Qui maintient sa propre box HA est bien servi par Tailscale et un peu de discipline, et c’est très bien comme ça. Tout l’attirail d’interrupteurs de consentement et de journaux de session ne se rentabilise pas quand le client et le mainteneur sont la même personne.

Le calcul bascule dès qu’il s’agit d’instances appartenant à d’autres. Un intégrateur qui s’occupe de dix ou vingt clients multiplie avec chaque méthode aussi ses faiblesses. Dix ports ouverts, c’est dix fois la charge de force brute que les logins HA exposés encaissent de toute façon en permanence. Dix VPN complets, c’est dix réseaux clients dans lesquels mène un seul accès craqué. Et dès que « une maintenance » devient « de la maintenance chez de nombreux clients », la question bascule de toute façon de l’accès vers la vue d’ensemble. C’est un sujet à part entière, que j’ai déroulé dans le comparatif le multi-tenant plutôt que la solution bricolée pour le suivi client.

Pour l’intégrateur, la posture propre n’est au final pas que technique. Elle est vendable. « Je ne peux intervenir que si vous l’autorisez, uniquement sur votre box HA, uniquement pour une fenêtre, et c’est journalisé » est une phrase que le port ouvert et le VPN complet ne peuvent structurellement pas dire. L’un est toujours ouvert, l’autre est toujours trop large.

Ce qu’est HA Fleet Manager, et ce qu’il n’est pas

J’écris ce blog pour un produit, alors je dis ouvertement où il se situe dans cette histoire et où sont les limites. Le baratin marketing m’agace surtout sur le thème de la sécurité, parce que c’est précisément là qu’il coûte la confiance dont on a besoin.

HA Fleet Manager met en œuvre le modèle de cet article : initié en sortant, accordé par le client, limité dans le temps, cantonné à l’instance HA, audité. Le connecteur est une intégration custom sur l’instance du client et établit au démarrage une connexion WebSocket sortante, pas de port ouvert. L’accès distant ne naît qu’après que le client a ouvert une fenêtre de maintenance via un interrupteur, et une fois la fenêtre terminée, la porte se referme automatiquement. Le tunnel mène à l’interface HA, pas dans le LAN. Qui veut voir comment ce tunnel sortant s’établit étape par étape en trouve un aperçu sur la page d’accueil. L’hébergement est dans l’UE.

Ce qu’il n’est pas : un remède universel contre toute panne. La limite résiduelle évoquée plus haut vaut aussi ici. Si Home Assistant tombe au point que l’interface ne remonte plus, le plugin in-app peut tomber avec, et alors même la fenêtre de maintenance la plus propre n’aide en rien au-delà du niveau fichier ou récupération. C’est un produit jeune, pas un RMM durci par des années d’usage. Et il demande que vous fassiez confiance à un composant de relais centralisé. C’est un arbitrage assumé, pas un détail qu’on évacue par le marketing. Qui entretient une poignée d’instances à lui via Tailscale et s’en satisfait n’a besoin de rien de tout ça.

La différence ne devient pertinente que là où « mon tunnel » devient « les tunnels de mes clients ». Alors la question n’est plus de savoir si vous entrez. Mais de savoir avec quel minimum d’accès vous y parvenez.

Divulgation : HA Fleet Manager est le produit derrière ce blog. Les preuves CVE, les données de honeypot et la recommandation de l’éditeur proviennent toutefois de sources indépendantes, pas de moi. Le port ouvert, je ne le recommanderais pas non plus même sans produit en arrière-plan.