Beim ersten Zugriff auf ein ssh-Remote-System wird automatisch ein ControlMaster-Hintergrundprozess erzeugt

In letzter Zeit verwende ich häufig die ControlMaster-Funktion des SSH-Clients, mit der ich eine einzelne SSH-TCP-Verbindung für mehrere Shells und Portweiterleitungen an dasselbe Remote-System verwenden kann. Das nervigste daran ist, dass der Prozess der ersten Shell, der geöffnet wird, automatisch zum ControlMaster wird. Das heißt, wenn dieser Prozess beendet wird, sind alle anderen Shells und Portweiterleitungen, die die Control Master-Verbindung verwenden, nicht mehr verfügbar.

Ich würde wirklich gerne, wenn der erste ssh-Befehl an ein Remote-System einen zusätzlichen Hintergrundprozess auslösen würde, der die Verbindung hält, solange noch Verbindungen über die ControlMaster-Verbindung bestehen, sodass ich einfach die eigentlichen Shells schließen könnte, ohne das Risiko eingehen zu müssen, andere zum Absturz zu bringen Verbindungen. Im Idealfall kann der ControlMaster-Hintergrundprozess sogar so konfiguriert werden, dass einige Zeit gewartet wird, bis neue Shells oder Portweiterleitungen den ControlMaster verwenden, bevor er endgültig heruntergefahren wird.

Gibt es eine Möglichkeit, den SSH-Client dazu zu bringen, so etwas zu tun? Ich weiß, dass ich eine solche Verbindung manuell erstellen kann, bevor ich ssh zum Erstellen der ersten Shell verwende, aber ich möchte ausdrücklich, dass dies automatisch geschieht, da ich sonst sicherlich ab und zu vergessen würde, dies zu tun.

Es wäre auch nicht so einfach, ein Wrapper-Skript ausführen zu lassen, da ich häufig konfigurierte Abkürzungen für Remote-Servernamen in .ssh / config verwende und der ControlMaster-Socket mit USERNAME @ NETWORK_NAME: NETWORK_PORT als Name erstellt wird. Ein Wrapper muss also .config / ssh perfekt verstehen, um wie beabsichtigt zu funktionieren.

Sie sollten die Konfigurationsoption ControlPersist verwenden.

 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 ist das Standardverhalten, das Sie beschreiben. Ich verwende ControlPersist 4h , damit sich die Hintergrundsitzungen regelmäßig bereinigen können.