Générer automatiquement un processus d'arrière-plan ControlMaster lors du premier accès à un système distant SSH

9

Dernièrement, j'utilise souvent la fonction ControlMaster du client SSH, qui me permet d'utiliser une seule connexion SSH-TCP pour plusieurs shells et transferts de port vers le même système distant. La chose la plus ennuyeuse à ce sujet est que le processus du premier shell ouvert devient automatiquement le ControlMaster. Cela signifie que si ce processus est interrompu, tous les autres shells et transferts de port utilisant la connexion maître de contrôle deviennent indisponibles.

J'aimerais vraiment quand la première commande ssh d'un système distant engendrerait un processus d'arrière-plan supplémentaire qui maintiendrait la connexion tant qu'il y aurait encore des connexions utilisant la connexion ControlMaster, donc je pourrais simplement fermer les shells sans avoir à risquer de planter d'autres Connexions. Idéalement, le processus ControlMaster en arrière-plan serait même configurable pour attendre un certain temps que de nouveaux shells ou des transferts de port utilisent le ControlMaster avant de s'arrêter définitivement.

Existe-t-il un moyen de faire faire une telle chose au client ssh? Je sais que je pourrais créer une telle connexion manuellement avant d'utiliser ssh pour créer le premier shell, mais je veux explicitement que cela se produise automatiquement car sinon j'oublierais sûrement de le faire de temps en temps.

Laisser un script wrapper le faire ne serait pas aussi facile, car j'utilise souvent des raccourcis configurés pour les noms de serveurs distants dans .ssh / config et le socket ControlMaster est créé en utilisant USERNAME @ NETWORK_NAME: NETWORK_PORT comme nom. Un wrapper devrait donc parfaitement comprendre .config / ssh pour fonctionner comme prévu.

aef
la source

Réponses:

10

Vous devez utiliser l'option de configuration ControlPersist.

 ControlPersist
         When used in conjunction with ControlMaster, specifies that the
         master connection should remain open in the background (waiting
         for future client connections) after the initial client connec‐
         tion has been closed.  If set to “no”, then the master connection
         will not be placed into the background, and will close as soon as
         the initial client connection is closed.  If set to “yes”, then
         the master connection will remain in the background indefinitely
         (until killed or closed via a mechanism such as the ssh(1) “-O
         exit” option).  If set to a time in seconds, or a time in any of
         the formats documented in sshd_config(5), then the backgrounded
         master connection will automatically terminate after it has
         remained idle (with no client connections) for the specified
         time.

ControlPersist no est le comportement par défaut, comme vous le décrivez. J'utilise ControlPersist 4h pour permettre aux sessions d'arrière-plan de se nettoyer périodiquement.

Daniel Lawson
la source
Est-ce disponible sur RHEL?
ewwhite
1
@ewwhite Je n'ai pas RHEL, mais CentOS devrait être le même. C'est dans CentOS 7, mais ne semble pas être dans CentOS 6.5. Le journal des modifications openssh suggère qu'il a été ajouté dans openssh 5.6, et CentOS 6.x n'en a que 5.3 (7.0 a openssh 6.4)
Daniel Lawson