Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Lately I'm often using the SSH client's ControlMaster feature, which allows me to use a single SSH-TCP-connection for multiple shells and port forwardings to the same remote system. The most annoying thing about this is, that the first shell's process that is opened becomes automatically the ControlMaster. That means, if this process gets terminated, all other shells and port forwardings using the control master connection become unavailable.

I would really like when the first ssh command to a remote system would spawn an additional background process which holds the connection as long as there are still connections using the ControlMaster connection, so I could simply close the actual shells whithout having to risk to crash other connections. Ideally the background ControlMaster process would even be configurable to wait for an amount of time for new shells or port forwardings to use the ControlMaster before finally shutting down.

Is there a way to make the ssh client do such a thing? I know I could create such a connection manually before using ssh to create the first shell, but I explicitly want this to happen automatically because otherwise I would surely forget to do it every now and then.

Letting a wrapper script do it also wouldn't be so easy because I often use configured shorthands for remote server names in .ssh/config and the ControlMaster socket is created using USERNAME@NETWORK_NAME:NETWORK_PORT as name. So a wrapper would need to understand .config/ssh perfectly to work as intended.

share|improve this question
up vote 7 down vote accepted

You should use the ControlPersist config option.

         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

ControlPersist no is the default behaviour, which is as you describe. I use ControlPersist 4h to allow the background sessions to clean themselves up periodically.

share|improve this answer
Thanks. That works great. – aef Jan 26 '12 at 9:27
Is this available on RHEL? – ewwhite Jul 25 '14 at 4:57
@ewwhite I don't have RHEL, but CentOS should be the same. It's in CentOS 7, but appears not to be in CentOS 6.5. The openssh changelog suggests it was added in openssh 5.6, and CentOS 6.x only has 5.3 (7.0 has openssh 6.4) – Daniel Lawson Aug 7 '14 at 9:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.