Comment détacher une session ssh sans tuer un processus en cours d'exécution ?

Utiliser

Ctrl-Z

pour suspendre l'application et revenir à la ligne de commande. Utilisez ensuite

bg

pour permettre au processus de se poursuivre en arrière-plan. Utilisez enfin

disown

Pour que le processus ne se ferme pas lorsque vous déconnectez votre session et fermez votre terminal.

Le processus continuera à s'exécuter, mais il n'y a aucun moyen de "rattacher" au terminal pour afficher la sortie dont je suis conscient si vous vous reconnectez à une nouvelle session.

Utilisez reptyr

C'est exactement le cas man 1 reptyr mentionne explicitement :

reptyr est un utilitaire pour prendre un programme en cours d'exécution existant et l'attacher à un nouveau terminal. Vous avez démarré un processus de longue durée via ssh, mais vous devez partir et ne voulez pas l'interrompre ? Commencez simplement un screen , utilisez reptyr pour le récupérer, puis tuez la session ssh et rentrez chez vous.

(Le manuel mentionne screen , vous pouvez utiliser tmux à la place, selon votre préférence).

Ne manquez pas cette note :

reptyr dépend du ptrace(2) appel système à attacher au programme distant. Sur Ubuntu Maverick et supérieur, cette capacité est désactivée par défaut pour des raisons de sécurité. Vous pouvez l'activer temporairement en faisant

echo 0 > /proc/sys/kernel/yama/ptrace_scope

en tant que root, ou de façon permanente en éditant le fichier /etc/sysctl.d/10-ptrace.conf , qui contient également plus d'informations sur ce paramètre.

Si le fichier n'existe pas mais le /etc/sysctl.d/ répertoire le fait, alors il suffit probablement de le créer avec le contenu suivant :

kernel.yama.ptrace_scope = 0

Le paramètre sera appliqué au prochain redémarrage. Veuillez consulter les considérations de sécurité ci-dessous.

Utilisation de base

L'utilisation de base est simple :

reptyr PID

où PID est le PID du processus que vous souhaitez attacher à un nouveau terminal. Remarque reptyr attache uniquement un processus à un autre terminal. Cela ne signifie pas que le processus devient un enfant du nouveau shell.

Considérations de sécurité

Réglage ptrace_scope comme 0 n'est pas recommandé.

À mesure que Linux gagne en popularité, il deviendra une cible plus importante pour les logiciels malveillants. Une faiblesse particulièrement troublante des interfaces de processus Linux est qu'un seul utilisateur est capable d'examiner la mémoire et l'état de fonctionnement de n'importe lequel de ses processus. Par exemple, si une application (par exemple, Pidgin) était compromise, il serait possible pour un attaquant de se connecter à d'autres processus en cours d'exécution (par exemple, Firefox, sessions SSH, agent GPG, etc.) pour extraire des informations d'identification supplémentaires et continuer à étendre la portée de leur attaquer sans recourir au phishing assisté par l'utilisateur.

Ce n'est pas un problème théorique. Le détournement de session SSH (http://www.storm.net.nz/projects/7) et les attaques par injection de code arbitraire (http://c-skills.blogspot.com/2007/05/injectso.html) existent déjà et perdurent possible si ptrace est autorisé à fonctionner comme avant. Depuis ptrace n'est pas couramment utilisé par les non-développeurs et les non-administrateurs, les constructeurs de systèmes devraient avoir la possibilité de désactiver ce système de débogage.

[…]

Les paramètres sysctl (inscriptibles uniquement avec CAP_SYS_PTRACE ) sont :

0 - classique ptrace autorisations :un processus peut PTRACE_ATTACH à tout autre processus s'exécutant sous le même uid, tant qu'il est dumpable […]

1 - restreint ptrace :un processus doit avoir une relation prédéfinie avec l'inférieur qu'il veut appeler PTRACE_ATTACH sur. Par défaut, cette relation est celle de ses seuls descendants lorsque le critère classique ci-dessus est également rempli. […]

2 - pièce jointe réservée aux administrateurs :uniquement les processus avec CAP_SYS_PTRACE peut utiliser ptrace avec PTRACE_ATTACH , ou par l'intermédiaire d'enfants appelant le PTRACE_TRACEME .

3 - pas d'attachement :aucun processus ne peut utiliser ptrace avec PTRACE_ATTACH ni via PTRACE_TRACEME . Une fois définie, cette valeur sysctl ne peut pas être modifiée.

Une approche raisonnable consiste à définir ptrace_scope à 2 puis autorisez reptyr utiliser ptrace :

echo 2 | sudo tee /proc/sys/kernel/yama/ptrace_scope
sudo setcap CAP_SYS_PTRACE+pe /usr/bin/reptyr

N'oubliez pas le fichier qui contient le réglage permanent.

Les capacités sont stockées dans l'inode du fichier. Par conséquent, je ne serais pas surpris si reptyr perd la capacité lorsqu'il est mis à jour (remplacé de manière atomique par un nouvel exécutable).

Vous pouvez totalement dissocier une commande (en bash ou zsh , éventuellement d'autres shells) avec le disown commande. La commande peut cependant ne pas être satisfaite si elle nécessite un tty, auquel cas voir le reptyr réponse.

$ ssh somecentos7system
-bash-4.2$ sleep 252727
^Z
[1]+  Stopped                 sleep 252727
-bash-4.2$ bg
[1]+ sleep 252727 &
-bash-4.2$ disown
-bash-4.2$ logout
Connection to somecentos7system closed.
$ ssh somecentos7system
-bash-4.2$ pgrep -lf 252727
20089 sleep
-bash-4.2$ 

Une autre option consiste à démarrer automatiquement une session screen (ou tmux) afin que vous ne puissiez pas oublier d'en démarrer une car une a déjà été démarrée pour vous parce que vous avez configuré les choses de cette façon. Il y a d'autres messages ailleurs sur la façon de le faire.