En 2026, comment diagnostiquer les déconnexions fréquentes de SSH avec Starlink ?

Une coupure SSH avec Starlink se diagnostique d’abord en séparant une perte momentanée du réseau d’une session SSH réinitialisée ; vérifiez ensuite la liaison, le routeur et le VPN, puis confrontez les journaux du client et du serveur. Si vous devez garder une session longue active pour une tâche importante, prévoyez une connexion de secours ou un environnement de travail qui permet de reprendre la session après une interruption.

Cet article s’adresse aux développeurs qui se connectent par SSH à une machine de développement, à un dépôt de code ou à un serveur de production.
Il peut aussi aider les SRE chargés d’astreinte à distinguer un problème d’accès d’une panne serveur.
Les petites équipes qui travaillent via Starlink y trouveront une méthode pour décider quand basculer sur une autre connexion.

Comment diagnostiquer les coupures SSH avec Starlink ?

Ne commencez pas par modifier la configuration du serveur. Relevez d’abord l’heure exacte, l’état de la connexion Internet et le message affiché par le client SSH. Notez aussi si le VPN était actif et si d’autres services, par exemple une page web ou une visioconférence, se sont interrompus au même moment. Cette trace simple évite d’attribuer à tort une coupure SSH au réseau satellite.

Les symptômes ne désignent pas tous la même panne :

• Le client SSH affiche une erreur et se termine. Une fermeture distante, un refus de connexion ou une expiration peuvent en être la cause. Conservez le texte exact de l’erreur ; « connexion réinitialisée » n’indique pas à elle seule quel équipement a interrompu le flux.
• Le terminal semble bloqué, puis répond à nouveau. La session peut avoir été ralentie ou temporairement privée de réseau sans être immédiatement fermée. Notez si la fenêtre de terminal est toujours ouverte et si une commande en cours reprend.
• Le VPN se reconnecte, mais d’autres applications restent accessibles. Le tunnel ou sa route peuvent être en cause, sans que la liaison Internet entière soit hors service.
• L’appareil perd aussi l’accès aux autres services. Le diagnostic doit remonter vers le Wi-Fi, le routeur, le terminal Starlink ou la liaison elle-même, plutôt que se limiter à SSH.
• Un seul serveur est inaccessible. Examinez aussi le serveur, son pare-feu et son service SSH. Une panne qui ne touche qu’un hôte ne prouve pas que l’accès satellite est responsable.

Pour un relevé côté poste client, lancez temporairement SSH avec son mode de diagnostic détaillé, ssh -vvv. Le manuel OpenSSH explique les options de configuration et de journalisation du client dans sa documentation de configuration SSH. Le but n’est pas de conserver indéfiniment une sortie verbeuse, mais de l’associer à l’heure de l’incident et au symptôme.

Commencez par la liaison et l’environnement d’installation

Ouvrez l’application Starlink et examinez l’état de la connexion, les alertes et les éventuels avertissements d’obstruction. La documentation officielle sur le contrôle des obstructions décrit cette vérification. Si l’application signale une zone obstruée, inspectez l’emplacement de l’antenne et les obstacles visibles avant de toucher aux paramètres SSH.

Cherchez ensuite une corrélation, sans la transformer en conclusion prématurée. Les interruptions arrivent-elles surtout lorsque vous travaillez depuis une pièce précise, lorsque vous utilisez un équipement mobile, ou pendant une situation météorologique particulière ? Un incident observé une fois ne permet pas d’établir qu’une météo, une position ou Starlink provoque systématiquement les coupures. Il fournit une piste à comparer avec de nouveaux relevés.

La page Starlink consacrée au diagnostic des interruptions de service fournit les vérifications officielles à effectuer lorsque la connexion est intermittente. Consultez également les explications officielles sur les alertes Starlink afin de distinguer un avertissement affiché par le service d’une interprétation personnelle de vos symptômes.

Vous pouvez compléter ces observations par un test de connectivité vers une destination adaptée. ping permet de relever des réponses et des pertes ; sa documentation décrit les statistiques présentées à la fin de l’exécution. Servez-vous du manuel de ping pour interpréter ces résultats, mais ne transformez pas un test ponctuel en estimation de la qualité durable de votre ligne. Un test vers un hôte qui filtre les requêtes ou ne répond pas peut aussi donner une fausse impression de panne.

Cas concret : si le terminal SSH se fige au même moment que votre appel vidéo et que l’application Starlink signale une interruption, relevez les heures des trois événements. Si, en revanche, la vidéo continue et que seul le tunnel VPN se reconnecte, la piste du réseau local ou du VPN mérite d’être isolée avant de conclure à un problème de liaison satellite.

Isolez le routeur, le Wi-Fi et le VPN

Le réseau local peut reproduire les symptômes d’une interruption satellite. Un signal Wi-Fi faible, une transition entre points d’accès, un câble défectueux ou un redémarrage du routeur peuvent couper la session SSH alors que le service satellite fonctionne. Procédez par comparaison : gardez le même ordinateur, le même serveur et le même moment de travail, puis remplacez une seule variable à la fois.

• Wi-Fi puis connexion filaire : si la coupure se produit en Wi-Fi mais pas par câble, examinez la portée, les interférences et le point d’accès. Si les deux modes échouent ensemble, poursuivez vers le routeur, la liaison ou le serveur.
• VPN activé puis désactivé : si votre politique de sécurité l’autorise, comparez des sessions séparées. Une reconnexion du VPN, une modification de route ou un changement de DNS peut interrompre SSH. Ne désactivez pas un tunnel exigé par votre organisation pour accéder à un environnement protégé.
• Nom d’hôte puis adresse connue : si la résolution DNS change au moment de la coupure, SSH peut chercher une destination différente. Vérifiez l’adresse obtenue, mais ne contournez pas les règles d’accès de votre équipe.
• Un service puis plusieurs services : comparez SSH avec une autre connexion réseau. Si plusieurs applications s’interrompent en même temps, la piste d’une panne générale est plus crédible qu’un défaut propre au serveur.

Évitez de changer simultanément le canal Wi-Fi, les paramètres du routeur, la configuration VPN et le fichier SSH. Si le comportement change, vous ne saurez plus quelle modification l’a influencé. Notez chaque essai, son heure et son résultat, puis revenez à l’état précédent avant d’en tester un autre.

Une autre source de confusion est le DNS : une connexion VPN peut imposer des serveurs DNS différents de ceux utilisés hors tunnel. Si un nom ne se résout plus, mais que l’hôte reste accessible par son adresse habituelle, cela peut expliquer un échec de connexion sans indiquer une coupure physique de Starlink. Vérifiez toutefois l’adresse auprès de l’administrateur avant de l’utiliser, car une adresse peut changer et les politiques de sécurité peuvent imposer le nom attendu.

Conservez des traces utilisables côté client et serveur

Une trace exploitable met en regard les deux extrémités. Côté poste, enregistrez l’heure, le message d’erreur, le réseau utilisé, l’état du VPN et, si nécessaire, la sortie du mode détaillé SSH. Côté serveur, demandez à la personne responsable de vérifier les journaux d’authentification et de connexion autour du même instant. N’envoyez pas de clé privée, de jeton, de mot de passe ni de fichier de configuration complet dans un ticket de support.

Sur un serveur Linux utilisant systemd, journalctl permet de consulter les journaux du système et des services. La documentation de journalctl décrit les filtres permettant de retrouver des événements pertinents. Le nom de l’unité SSH varie selon la distribution et la configuration : utilisez le nom réellement présent sur votre serveur plutôt que de supposer qu’il est identique partout.

Les résultats permettent de départager plusieurs situations :

• Le client indique une perte de transport, tandis que le serveur ne rapporte pas de fermeture volontaire : vérifiez d’abord la liaison et les intermédiaires réseau.
• Le serveur journalise une fermeture, une erreur d’authentification ou un redémarrage du service au même moment : examinez le service SSH, la configuration et les politiques d’accès.
• Les journaux du serveur ne montrent pas l’arrivée de la tentative : le problème peut se trouver avant le serveur, dans le réseau local, le VPN, le routage ou la résolution de nom.
• Les événements du VPN et du client SSH se suivent dans le temps : comparez plusieurs occurrences avant de désigner le tunnel comme cause.

Des horloges désynchronisées peuvent rendre cette comparaison trompeuse. Vérifiez que l’ordinateur et le serveur utilisent une heure cohérente, et indiquez le fuseau horaire si vous transmettez les traces à une autre équipe. Masquez les adresses, noms de comptes et identifiants qui ne sont pas nécessaires à l’analyse.

Les paramètres de maintien ne réparent pas une liaison coupée

Les options de maintien de connexion SSH peuvent aider lorsque l’équipement intermédiaire ferme une session inactive. Elles peuvent provoquer l’envoi périodique d’un message de contrôle afin de détecter qu’une connexion ne répond plus ou d’éviter une expiration due à l’inactivité, selon la configuration. La documentation OpenSSH sur les paramètres du client décrit notamment les directives associées.

Choisissez ces réglages avec prudence : un intervalle trop agressif peut générer des échanges inutiles, tandis qu’un contrôle trop espacé retarde la détection d’une session perdue. Surtout, un mécanisme de maintien ne rétablit pas une liaison satellite indisponible, ne corrige pas un point d’accès instable et ne répare pas un tunnel VPN qui se réinitialise. Si le réseau interrompt réellement le flux, attendez-vous à devoir ouvrir une nouvelle connexion.

Pour réduire les conséquences d’une coupure, exécutez les tâches longues dans un multiplexeur de terminal sur la machine distante. tmux peut laisser un processus attaché à une session distante même si votre terminal local disparaît ; vous pourrez ensuite vous reconnecter et retrouver cette session si le serveur et le processus sont restés actifs. Le guide officiel de démarrage de tmux explique comment créer et reprendre une session. Vérifiez tout de même après reconnexion que la commande tourne encore et que ses fichiers de sortie sont intacts : tmux ne protège pas contre un redémarrage de la machine distante ou l’arrêt du processus.

Décidez de la suite avec cette liste de contrôle

Cochez la situation qui correspond aux traces recueillies, puis appliquez la décision associée. Si plusieurs cases correspondent, commencez par celle qui décrit le plus grand nombre de services touchés et vérifiez chaque hypothèse séparément.

• [ ] SSH et plusieurs autres services tombent au même instant. Examinez l’état de Starlink, les avertissements d’obstruction et le routeur. Si l’accès ne revient pas ou si vous devez poursuivre une opération sensible, basculez sur une connexion de secours.
• [ ] Le Wi-Fi échoue, mais la connexion filaire reste stable. Utilisez provisoirement le câble et diagnostiquez séparément le point d’accès. Si les deux modes échouent, revenez à l’examen du routeur, de la liaison et des journaux serveur.
• [ ] Les coupures n’apparaissent qu’avec le VPN. Comparez les événements du tunnel et de SSH, puis demandez une vérification des routes et du DNS. Gardez le VPN activé si votre organisation l’exige ; ne contournez pas une règle de sécurité pour gagner en disponibilité.
• [ ] Un seul serveur est touché et ses journaux montrent une fermeture ou un redémarrage. Traitez d’abord le service distant et son infrastructure. Si les journaux ne montrent aucune tentative entrante, examinez le chemin réseau avant le serveur.
• [ ] Les interruptions sont brèves et la tâche peut reprendre. Utilisez tmux, sauvegardez votre travail et vérifiez l’état du processus après reconnexion. Si le processus a disparu ou si son résultat est incomplet, ne supposez pas que la session a repris automatiquement.
• [ ] Une perte de session peut interrompre une intervention de production. Préparez une seconde voie d’accès et désignez à l’avance la personne qui décide du basculement. Si cette solution n’a pas été testée, ne la considérez pas encore comme un plan de continuité.

Une connexion de secours peut être un autre accès Internet disponible dans votre environnement, à condition que les règles d’accès à vos serveurs l’autorisent. Avant de compter dessus, vérifiez qu’elle donne réellement accès au VPN, aux hôtes nécessaires et à l’authentification attendue. Une solution jamais testée ne constitue pas un plan de continuité.

Pour un travail de développement distant, examinez aussi la manière dont vous séparez le terminal local du processus distant. Enregistrer le code, utiliser un dépôt distant et exécuter les tâches longues dans une session récupérable ne rend pas la liaison plus stable ; cela limite plutôt le travail à refaire après une coupure. Pour la création audio ou vidéo, ou le travail de conception, vérifiez en plus que l’accès distant répond aux besoins des logiciels, périphériques et transferts de fichiers : un terminal récupérable ne remplace pas une station locale adaptée à ces tâches.

Questions fréquentes

Pourquoi SSH se coupe-t-il régulièrement avec Starlink ?

La même coupure apparente peut venir d’une interruption de liaison, d’un obstacle, du Wi-Fi, du VPN, du DNS ou d’une fermeture côté serveur. Relevez l’heure et les symptômes avant de choisir une cause. Comparez ensuite l’état de l’application Starlink avec les journaux du client et du serveur. Une seule occurrence ne suffit pas pour conclure qu’un facteur donné explique tous les incidents.

Comment distinguer une panne Starlink d’un problème serveur ?

Regardez si d’autres services ou hôtes restent accessibles au moment de l’incident. Si plusieurs connexions disparaissent ensemble, examinez le réseau local, le routeur et la liaison. Si un seul serveur échoue, vérifiez son service SSH, son pare-feu et ses journaux. Des horodatages cohérents côté client et serveur permettent de savoir si la tentative atteint la machine distante.

Quels réglages contrôler pour se connecter à un serveur distant par satellite ?

Comparez une connexion Wi-Fi avec une connexion filaire, puis testez séparément l’effet du VPN si votre politique de sécurité l’autorise. Vérifiez aussi le nom d’hôte, le DNS, la destination configurée et les règles de pare-feu. Les journaux détaillés du client et les événements côté serveur aident à localiser le problème. Les paramètres de maintien de session ne réparent pas une interruption réelle.

Le VPN peut-il rendre SSH instable avec Starlink ?

Oui, un tunnel VPN qui se reconnecte, change les routes ou utilise une autre résolution DNS peut perturber SSH. Pour le vérifier, comparez des essais avec et sans VPN en ne changeant pas les autres paramètres. Si la connexion échoue uniquement avec le tunnel, rassemblez les événements du VPN et de SSH pour l’administrateur. Ne désactivez pas un VPN imposé par les règles de votre organisation.

Si vous comptez uniquement sur Starlink, ses interruptions possibles, le Wi-Fi de votre installation et un VPN qui rétablit son tunnel restent autant de points de défaillance ; à l’inverse, basculer vers une autre connexion peut demander une configuration et des contrôles d’accès supplémentaires. Pour une équipe qui a besoin d’un environnement Mac distant en complément de son poste actuel, la location d’un Mac peut fournir une machine de travail séparée, mais elle ne supprimera pas les coupures de votre accès Internet et ne convient pas à tous les usages. Consultez les environnements Mac proposés par Kvmzen et les informations sur la location de Mac mini aux États-Unis, puis choisissez selon vos outils, vos besoins d’accès et votre plan de reprise.

Questions fréquentes