Genera automaticamente un processo in background ControlMaster al primo accesso a un sistema remoto ssh


9

Ultimamente utilizzo spesso la funzione ControlMaster del client SSH, che mi consente di utilizzare una singola connessione SSH-TCP per più shell e port forwarding sullo stesso sistema remoto. La cosa più fastidiosa di questo è che il primo processo della shell che viene aperto diventa automaticamente ControlMaster. Ciò significa che, se questo processo viene terminato, tutte le altre shell e port forwarding che utilizzano la connessione master di controllo diventano non disponibili.

Mi piacerebbe davvero quando il primo comando ssh su un sistema remoto generasse un ulteriore processo in background che mantiene la connessione fintanto che ci sono ancora connessioni che usano la connessione ControlMaster, quindi potrei semplicemente chiudere le shell effettive senza dover rischiare di arrestare altre connessioni. Idealmente, il processo in background di ControlMaster sarebbe persino configurabile in modo da attendere un certo periodo di tempo affinché nuove shell o port forwarding utilizzino ControlMaster prima di chiudere definitivamente.

C'è un modo per fare in modo che il client ssh faccia una cosa del genere? So che potrei creare una tale connessione manualmente prima di usare ssh per creare la prima shell, ma voglio esplicitamente che ciò accada automaticamente perché altrimenti dimenticherei sicuramente di farlo ogni tanto.

Lasciare fare uno script wrapper non sarebbe così facile perché uso spesso shorthands configurati per nomi di server remoti in .ssh / config e il socket ControlMaster viene creato usando USERNAME @ NETWORK_NAME: NETWORK_PORT come nome. Quindi un wrapper dovrebbe capire perfettamente .config / ssh per funzionare come previsto.

Risposte:


10

È necessario utilizzare l'opzione di configurazione 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 è il comportamento predefinito, come descritto. Uso ControlPersist 4h per consentire alle sessioni in background di ripulirsi periodicamente.


È disponibile su RHEL?
ewwhite,

1
@ewwhite Non ho RHEL, ma CentOS dovrebbe essere lo stesso. È in CentOS 7, ma sembra non essere in CentOS 6.5. Il log delle modifiche di openssh suggerisce che è stato aggiunto in openssh 5.6 e CentOS 6.x ha solo 5.3 (7.0 ha openssh 6.4)
Daniel Lawson
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.