La déconnexion d'une session SSH tue-t-elle vos programmes ?

Édition pour 2016 :

Ces questions et réponses sont antérieures au débâcle de systemd v230 . À partir de systemd v230, le nouveau défaut est de tuer tous les enfants d'une session de connexion qui se termine, quelles que soient les précautions historiquement valables prises pour éviter cela. Ce comportement peut être modifié en définissant KillUserProcesses=no en /etc/systemd/logind.conf ou contourné en utilisant les mécanismes spécifiques au système pour démarrer un démon en espace utilisateur. Ces mécanismes sont en dehors de la portée de cette question.

Le texte ci-dessous décrit comment les choses ont traditionnellement fonctionné dans l'espace de conception UNIX depuis plus longtemps que Linux n'existe.

Ils seront tués, mais pas nécessairement immédiatement. Cela dépend du temps qu'il faut au démon SSH pour décider que votre connexion est morte. Ce qui suit est une explication plus longue qui vous aidera à comprendre comment cela fonctionne réellement.

Lorsque vous vous êtes connecté, le démon SSH a alloué un pseudo-terminal pour vous et l'a attaché au login configuré de votre utilisateur Shell. C'est ce qu'on appelle le terminal de contrôle. Chaque programme que vous démarrez normalement à partir de ce moment, peu importe le nombre de couches de shells, remontera finalement à ce Shell. Vous pouvez observer cela avec la fonction pstree commandement.

Lorsque le processus démon SSH associé à votre connexion décide que votre connexion est morte, il envoie un signal de raccrochage ( SIGHUP ) au login Shell. Cela notifie le Shell que vous avez disparu et qu'il doit commencer à nettoyer après lui-même. Ce qui se passe à ce stade est spécifique à Shell (recherchez "HUP" dans sa page de documentation), mais pour l'essentiel, elle commencera à envoyer SIGHUP aux travaux en cours qui lui sont associés avant de se terminer. Chacun de ces processus, à son tour, fera ce qu'il a été configuré pour faire à la réception de ce signal. En général, cela signifie se terminer. Si ces tâches ont leurs propres tâches, le signal sera souvent transmis également.

Les processus qui survivent à un blocage du terminal de contrôle sont ceux qui se sont dissociés du terminal (processus démons que vous avez démarrés à l'intérieur du terminal), ou ceux qui ont été invoqués avec le préfixe nohup commande. (Les démons interprètent le signal HUP différemment ; puisqu'ils ne disposent pas d'un terminal de contrôle et ne reçoivent pas automatiquement un signal HUP, celui-ci est transformé en une demande manuelle de l'administrateur pour recharger la configuration. Ironiquement, cela signifie que la plupart des administrateurs n'apprennent que beaucoup, beaucoup plus tard l'usage "hangup" de ce signal pour les non-daemons. C'est pourquoi vous lisez ceci !

Les multiplexeurs de terminaux sont un moyen courant de garder votre environnement Shell intact entre deux déconnexions. Ils vous permettent de vous détacher de vos processus Shell de manière à pouvoir vous y rattacher ultérieurement, que cette déconnexion ait été accidentelle ou délibérée. tmux et screen sont les plus populaires ; la syntaxe pour les utiliser dépasse le cadre de votre question, mais il vaut la peine de s'y intéresser.

On m'a demandé de préciser le temps que met le démon SSH à décider que votre connexion est morte. Il s'agit d'un comportement spécifique à chaque implémentation d'un démon SSH, mais vous pouvez compter sur tous ces démons pour se terminer lorsque l'un ou l'autre côté réinitialise la connexion TCP. Cela se produira rapidement si le serveur tente d'écrire dans le socket et que les paquets TCP ne sont pas reconnus, ou lentement si rien ne tente d'écrire dans le PTY.

Dans ce contexte particulier, les facteurs les plus susceptibles de déclencher une écriture sont les suivants :

• Un processus (généralement celui en avant-plan) tente d'écrire dans le PTY du côté serveur. (serveur->client)
• L'utilisateur tente d'écrire dans le PTY du côté client. (client->serveur)
• Keepalives de toute sorte. Ils ne sont généralement pas activés par défaut, que ce soit par le client ou par le serveur, et il en existe deux types : au niveau de l'application et au niveau du protocole TCP (c.-à-d. SO_KEEPALIVE ). Les "keepalives" consistent à ce que le serveur ou le client envoie rarement des paquets à l'autre partie, même lorsque rien n'aurait autrement une raison d'écrire sur la socket. Bien que cette pratique soit généralement destinée à contourner les pare-feu qui interrompent les connexions trop rapidement, elle a pour effet secondaire de permettre à l'expéditeur de remarquer plus rapidement que l'autre partie ne répond pas.

Les règles habituelles des sessions TCP s'appliquent ici : s'il y a une interruption de la connectivité entre le client et le serveur, mais qu'aucun des deux côtés ne tente d'envoyer un paquet pendant le problème, la connexion survivra à condition que les deux côtés soient réactifs par la suite et reçoivent les numéros de séquence TCP attendus.

Si l'une des parties a décidé que la socket est morte, les effets sont généralement immédiats : le processus sshd enverra HUP et s'arrêtera d'elle-même (comme décrit précédemment), ou le client informera l'utilisateur du problème détecté. Il convient de noter que le fait qu'un côté pense que l'autre est mort ne signifie pas que l'autre en a été informé. Le côté orphelin de la connexion restera généralement ouvert jusqu'à ce qu'il tente d'y écrire et s'arrête, ou qu'il reçoive une réinitialisation TCP de l'autre côté. (si la connectivité était disponible à ce moment-là). Le nettoyage décrit dans cette réponse n'a lieu qu'une fois que le côté orphelin de la connexion a été supprimé. serveur a remarqué.