La nouvelle option ControlPersist s'applique aux connexions utilisant l'option ControlMaster qui permettait déjà de multiplexer plusieurs connexions dans une seule session ssh.
Les avantages du multiplexage sont entre autre un accès instantané aux connexions esclaves (c'est vraiment agréable pour l'autocompletion scp ou rsync) une seule session tcp (c'est le conntrack du firewall qui va être content...). Tout ceci est aussi très pratique sur les connexions utilisée comme proxy SSH – avec l'option -W évidemment...
Les inconvénients sont : la connexion maître doit rester ouverte tant qu'il y a des esclaves sur la socket (un simple ^D ne ferme que le shell mais laisse la connexion ouverte en général sans retour ou prompt local par contre, il ne faut pas fermer le terminal...), les commandes « escape » sont renvoyées sur la connexion maître (gênant quand il y a un vi ouvert, un tail qui défile ou autre sur ce terminal)
L'option ControlPersist permet de s'affranchir du premier inconvénient en créant la connexion maître en arrière plan sans terminal associé ni processus père (peut-être déjà possible avec quelque chose du genre « ssh -fT » mais je n'ai pas essayé). Le second peut-être compensé par l'option « -O forward », les redirections créées sont affectées à la connexion maître et survivent à la fermeture de toutes les sessions. Attention si on met cette option est à yes, la connexion restera ouverte indéfiniment jusqu'à ce quelle soit tuée ou qu'on lui envoie la commande d'arrêt « ssh -O exit », il vaut certainement mieux lui affecter un délai (1d chez moi) au bout duquel elle se ferme si aucun terminal n'est utilisé...
Côté serveur, il n'y a pas vraiment de différence avec cette option, je m'attendais à un fork supplémentaire, mais ce n'est pas le cas, donc pas vraiment d'impact négatif (à part des connexions qui peuvent rester ouvertes sans qu'on s'en aperçoive).
# ControlPersist...
Posté par Hobgoblins Master . En réponse à la dépêche OpenSSH 5.6 est disponible. Évalué à 10.
Les avantages du multiplexage sont entre autre un accès instantané aux connexions esclaves (c'est vraiment agréable pour l'autocompletion scp ou rsync) une seule session tcp (c'est le conntrack du firewall qui va être content...). Tout ceci est aussi très pratique sur les connexions utilisée comme proxy SSH – avec l'option -W évidemment...
Les inconvénients sont : la connexion maître doit rester ouverte tant qu'il y a des esclaves sur la socket (un simple ^D ne ferme que le shell mais laisse la connexion ouverte en général sans retour ou prompt local par contre, il ne faut pas fermer le terminal...), les commandes « escape » sont renvoyées sur la connexion maître (gênant quand il y a un vi ouvert, un tail qui défile ou autre sur ce terminal)
L'option ControlPersist permet de s'affranchir du premier inconvénient en créant la connexion maître en arrière plan sans terminal associé ni processus père (peut-être déjà possible avec quelque chose du genre « ssh -fT » mais je n'ai pas essayé). Le second peut-être compensé par l'option « -O forward », les redirections créées sont affectées à la connexion maître et survivent à la fermeture de toutes les sessions. Attention si on met cette option est à yes, la connexion restera ouverte indéfiniment jusqu'à ce quelle soit tuée ou qu'on lui envoie la commande d'arrêt « ssh -O exit », il vaut certainement mieux lui affecter un délai (1d chez moi) au bout duquel elle se ferme si aucun terminal n'est utilisé...
Côté serveur, il n'y a pas vraiment de différence avec cette option, je m'attendais à un fork supplémentaire, mais ce n'est pas le cas, donc pas vraiment d'impact négatif (à part des connexions qui peuvent rester ouvertes sans qu'on s'en aperçoive).