autossh surveille votre connexion et si elle tombe en panne, il se reconnecte. C'est plus fiable que les keepalives. Si vous vous connectez à une session d'écran, vous continuerez à partir de l'endroit où vous vous êtes déconnecté (cf. rscreen qui est fourni avec autossh)

Tmux

Celui-ci est un classique. Utilisez-le chaque fois que vous risquez de perdre la connexion à un terminal.

$ tmux
$ sh do_something_that_takes_forever

!! Connection fails so you reconnect once you notice

$ tmux ls
0: 1 windows (created Tue Aug 23 12:39:52 2011) [103x30]

$ tmux attach -t 0

Juste comme ça, vous êtes de retour en action.

J'installerais et lancerais l'écran pour résoudre votre problème. Screen vous permettra de vous reconnecter à une session d'écran précédente.

En outre, screen vous permet également de faire des choses sympas comme diviser votre écran, afficher la console, etc. Vous pouvez trouver plus d'informations aquí y aquí .

Pour commencer, si vous êtes déconnecté, vous pouvez utiliser

screen -ls

pour visualiser vos sessions et

screen -r ${session} 

pour se reconnecter à une personne déconnectée.

Utilice reptyr pour reparenter un programme en cours sur un nouveau terminal.

COMMENT FAIRE :

Supposons que nous nous soyons connectés à ssh à partir d'une adresse IP antérieure aaa.bbb.ccc.old ,
puis exécutez aptitude et au milieu du travail, cette connexion a été rompue.

Nous nous connectons avec ssh à nouveau (éventuellement à partir d'une adresse IP différente aaa.bbb.ccc.new ).
La connexion actuelle utilise pty/1 pseudo-terminal :

$ **tty**
/dev/**pts/1**

Mais il y a 2 connexions ouvertes, le courant pts/1 et le vieux brisé qui utilise pts/0 :

$ **who**
user     **pts/0**        2022-02-22 22:00 (**aaa.bbb.ccc.old**)
user     **pts/1**        2022-02-22 22:11 (**aaa.bbb.ccc.new**)

Lister tous les shells et leurs sous-processus :

$ **ps auf**
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
user        **2000**  1.3  0.5  10168  5236 **pts/1**    Ss   22:11   0:00 **\-bash**
user        2001  0.0  0.3  10620  3304 pts/1    R+   22:11   0:00  \\\_ **ps auf**
user        **1000**  0.0  0.5  10168  5132 **pts/0**    Ss   22:00   0:00 **\-bash**
user        1001  5.8 16.0  46639 15839 pts/0    Sl+  22:00   0:03  \\\_ **aptitude**
root         820  0.0  0.1   5836  1840 tty1     Ss+  22:00   0:00 /sbin/agetty -o -p -- \\u --noclear tty1 linux
root         810  0.0  0.2   7360  2260 ttyS0    Ss+  22:00   0:00 /sbin/agetty -o -p -- \\u --keep-baud 115200,38400,9600 ttyS0 vt220

Il y a 2 bash coquilles :
l'actuel pts/1 un avec PID 2000 en cours d'exécution ps auf
et le vieux brisé pts/0 un avec PID 1000 en cours d'exécution aptitude

Reconnectons nous à l'ancien avec reptyr :

$ sudo **reptyr** -T **1000**

De cette façon, nous avons accès à l'ancien Shell et à ses sous-processus.
Puisque l'aptitude utilise ncurses vous devrez peut-être appuyer sur Ctrl + L ou redimensionner la fenêtre de l'émulateur de terminal pour l'obliger à se repeindre.
Maintenant nous pouvons arrêter aptitude et ensuite quitter l'ancien Shell ( 1000 ),
retournant ainsi à notre nouveau Shell ( 2000 ) avec seulement 1 connexion restante, qui est la connexion actuelle :

$ **who**
user     **pts/1**        2022-02-22 22:11 (**aaa.bbb.ccc.new**)

Alors que screen maintiendra votre session Shell ouverte sur le serveur distant si votre session ssh est interrompue, il ne fera rien pour résoudre le problème des connexions ssh interrompues. Comme le suggère zero_r, essayez de régler votre connexion ssh avec des keep alives et des timeouts longs.

Je vous suggère de rechercher la cause des paquets perdus qui causent les problèmes et de la résoudre au lieu de la contourner.