Genera automáticamente un proceso en segundo plano ControlMaster en el primer acceso a un sistema remoto ssh

9

Últimamente, a menudo uso la función ControlMaster del cliente SSH, que me permite usar una única conexión SSH-TCP para múltiples shells y reenvíos de puertos al mismo sistema remoto. Lo más molesto de esto es que el proceso del primer shell que se abre se convierte automáticamente en ControlMaster. Eso significa que, si este proceso se termina, todos los demás shells y reenvíos de puertos que utilizan la conexión maestra de control dejan de estar disponibles.

Realmente me gustaría cuando el primer comando ssh para un sistema remoto generara un proceso en segundo plano adicional que mantiene la conexión siempre que todavía haya conexiones que usen la conexión ControlMaster, por lo que simplemente podría cerrar los shells reales sin tener que arriesgarme a bloquear otros conexiones Idealmente, el proceso de ControlMaster en segundo plano sería incluso configurable para esperar una cantidad de tiempo para que los nuevos shells o reenvíos de puertos utilicen el ControlMaster antes de finalmente cerrarse.

¿Hay alguna manera de hacer que el cliente ssh haga tal cosa? Sé que podría crear dicha conexión manualmente antes de usar ssh para crear el primer shell, pero quiero explícitamente que esto suceda automáticamente porque de lo contrario seguramente me olvidaría de hacerlo de vez en cuando.

Dejar que un script de envoltura lo haga tampoco sería tan fácil porque a menudo uso shorthands configurados para nombres de servidores remotos en .ssh / config y el socket ControlMaster se crea usando USERNAME @ NETWORK_NAME: NETWORK_PORT como nombre. Por lo tanto, una envoltura necesitaría entender .config / ssh perfectamente para funcionar según lo previsto.

aef
fuente

Respuestas:

10

Debe usar la opción de configuración 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 es el comportamiento predeterminado, que es como usted describe. Uso ControlPersist 4h para permitir que las sesiones en segundo plano se limpien periódicamente.

Daniel Lawson
fuente
¿Está disponible en RHEL?
ewwhite
1
@ewwhite No tengo RHEL, pero CentOS debería ser el mismo. Está en CentOS 7, pero parece que no está en CentOS 6.5. El registro de cambios de openssh sugiere que se agregó en openssh 5.6, y CentOS 6.x solo tiene 5.3 (7.0 tiene openssh 6.4)
Daniel Lawson