Ce que vous voyez
$ ssh -N -L 5433:10.0.3.4:5432 bastion # rien ne s’affiche, tout va bien # vingt minutes plus tard $ psql -h localhost -p 5433 connection refused $ ps aux | grep ssh # le processus est toujours là
Votre tunnel n’est pas instable. Il est tué.
Un ssh -L qui meurt « tout seul » meurt presque toujours pour l’une de trois raisons connues : personne ne parle sur la connexion, le serveur applique son propre délai, ou la machine s’est endormie. Les trois se corrigent, et cette page donne les options exactes avant de parler de quoi que ce soit d’autre.
macOS 11+ · Windows bientôt
Ce qui se passe vraiment
Le processus est vivant. Le tunnel, non.
C’est ce décalage qui fait croire à une instabilité : rien n’a planté, et pourtant plus rien ne passe.
Ce qui s’est passé
Un pare-feu a coupé une connexion muette · NAT, équilibreur, VPN d’entreprise ou le serveur a appliqué ClientAliveMaxCount ou le Mac s’est endormi · le socket meurt, pas le processus Personne ne vous l’a dit.
Les trois causes
Ce qui tue un tunnel, et ce qui le garde en vie.
| La cause | Le symptôme | Ce qui la corrige |
|---|---|---|
| Connexion muette coupée en route | meurt après 5 à 30 min sans trafic | ServerAliveInterval 30 et ServerAliveCountMax 3 |
| Le serveur applique son délai | meurt à heure fixe, quoi que vous fassiez | côté serveur : ClientAliveInterval, sinon, seul le keepalive client aide |
| La machine s’est endormie | mort au réveil, systématiquement | rien côté ssh : il faut relancer, ou quelque chose qui le fasse |
| Le port local reste pris | « Address already in use » à la relance | ExitOnForwardFailure yes, pour échouer franchement plutôt qu’à moitié |
| Le tunnel semble ouvert mais refuse | connection refused juste après le lancement | attendre que le port écoute : le processus démarre avant la porte |
Options documentées dans ssh_config(5) et sshd_config(5). Relevé le 7 août 2026 ; elles n’ont pas changé depuis des années et ne changeront pas de sitôt.
La configuration qui règle les deux premières
Quatre lignes dans ~/.ssh/config.
Elles valent pour tous vos hôtes, et elles suffisent dans la plupart des cas : y compris si vous n’installez jamais Kestro.
ServerAliveInterval 30
Envoie un signal toutes les trente secondes. La connexion cesse d’être muette, et les pare-feux qui coupent les sessions inactives n’ont plus de raison de la couper.
ServerAliveCountMax 3
Au bout de trois signaux sans réponse, ssh abandonne au lieu de rester accroché à une connexion morte. Vous savez alors que c’est tombé, ce qui vaut mieux qu’un tunnel fantôme.
ExitOnForwardFailure yes
Sans cette ligne, ssh ouvre la session même quand le transfert de port échoue : vous avez un processus vivant et aucun tunnel. Avec elle, l’échec est franc.
TCPKeepAlive yes
La ceinture en plus des bretelles : le keepalive du système, en complément de celui de ssh, pour les équipements réseau qui ignorent le second.
Sur votre machine
Tout reste chez vous.
Vos connexions vont de votre poste à vos serveurs, sans passer par nous.
Aucun compte
Rien à créer, aucun mot de passe.
Vos clés ne bougent pas
SSH, Google Cloud, AWS : Kestro se sert de vos outils, sur place.
Aucune statistique d’usage
Nous ne savons pas ce que vous ouvrez, ni quand.
Une seule exception
La licence se renouvelle chez nous. Rien d’autre ne sort.
Ce que la configuration ne règle pas
La veille, et le mensonge du vert.
Deux problèmes qu’aucune option de ssh ne corrige, parce qu’ils sont hors de son ressort.
Fermer le portable tue le tunnel
Aucun réglage ne survit à une mise en veille : le socket est fermé par le système. Il faut relancer la commande, et surtout, savoir qu’il faut la relancer, ce que rien n’indique au réveil. C’est précisément ce que Kestro fait : il rouvre les tunnels quand la machine se réveille, avec un recul croissant, et l’écrit sur la ligne.
Processus vivant ne veut pas dire port ouvert
Un ssh -L met une à trois secondes à s’authentifier puis à écouter. Pendant ce temps, tout script qui teste « le processus tourne-t-il ? » répond oui, et la connexion échoue quand même. Kestro sonde le port local et n’affiche « ouvert » qu’au premier raccordement réussi : le vert n’arrive jamais en avance.
Et si vous voulez juste que ça marche
Les quatre lignes ci-dessus sont gratuites et vous appartiennent : copiez-les, elles régleront la majorité des cas. Kestro s’adresse à ceux qui ont plusieurs tunnels, une machine qui dort, et mieux à faire que de surveiller lesquels sont encore vivants.
Prix
Vous payez une fois. C’est tout.
Un outil qu’on ouvre quarante fois par jour ne devrait pas envoyer une facture tous les mois.
Licence Kestro
29,99 €29,99 $US25,99 £GB25,90 CHF40,99 $CA45,99 $AU39,99 €39,99 $US34,99 £GB33,90 CHF54,99 $CA61,99 $AU · Offre de lancement · tarif à venir
1 ordinateur · paiement unique
- Toutes les fonctions de l’application, sans palier ni version « Pro »
- Un an de mises à jour incluses, puis renouvellement libre
- L’application reste la vôtre, même sans renouveler
- Une seule clé, la même sur tous vos ordinateurs
- Changez de machine quand vous voulez, sans limite
- Aucun compte à créer : la clé arrive par courriel
Ou télécharger gratuitement d’abord →
Remboursé sous 14 jours, sans question posée.
Questions qu’on nous pose
Où se mettent ces options ?
Dans ~/.ssh/config, sous un Host qui vise l’hôte concerné, ou sous Host * pour qu’elles valent partout. Elles s’appliquent à la connexion suivante, sans rien redémarrer. Si vous passez par un bastion, mettez-les sur le bastion : c’est cette connexion-là qui porte le tunnel.
ServerAliveInterval ou ClientAliveInterval ?
Le premier est côté client, dans votre ~/.ssh/config, et c’est celui que vous contrôlez. Le second est côté serveur, dans sshd_config, et il sert au serveur à se débarrasser des clients silencieux. Si c’est le serveur qui coupe et que vous n’y avez pas accès, seul ServerAliveInterval peut compenser : en faisant en sorte que vous ne soyez jamais silencieux.
autossh ne fait-il pas déjà tout cela ?
Il relance ce qui tombe, oui, et c’est un bon outil. Il ne vous dit pas pour autant qu’un port local écoute vraiment, il ne se réveille pas avec le Mac, et il ne sait rien des tunnels qui ne sont pas du SSH : un proxy Cloud SQL, une session AWS. Selon ce que vous ouvrez, il peut parfaitement suffire.
Mon tunnel Cloud SQL tombe aussi, est-ce pareil ?
Non, les causes diffèrent : le proxy Cloud SQL a sa propre gestion de session et ses jetons d’identité, qui expirent pour d’autres raisons. La page sur le refus de connexion du proxy traite ce cas-là.