openssh bugs - Jul 2015 - [Bug 2437] New: ssh with ControlMaster and ControlPath hangs on 2nd session in same terminal

https://bugzilla.mindrot.org/show_bug.cgi?id=2437

            Bug ID: 2437
           Summary: ssh with ControlMaster and ControlPath hangs on 2nd
                    session in same terminal
           Product: Portable OpenSSH
           Version: 6.7p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: uwe+mindrot at kleine-koenig.org

with two terminals a hang can be reproduces as follows:

 - In terminal 1 do:

     ssh -o "ControlMaster auto" -o "ControlPath
~/.ssh/sshctrl-%l-%h-%p-%r" localhost

 - In terminal 2 do the same:

     ssh -o "ControlMaster auto" -o "ControlPath
~/.ssh/sshctrl-%l-%h-%p-%r" localhost

 - Then back in terminal 1 again:

     logout

   This doesn't terminate the ssh-command to keep the control socket
   open. Then pressing Ctrl-Z and run bg to send the ssh into the
   background.

 - The "remote" shell in the 2nd terminal is still working.

 - Now repeat the ssh command in the first terminal:

    ssh -o "ControlMaster auto" -o "ControlPath
~/.ssh/sshctrl-%l-%h-%p-%r" localhost

Both sessions don't react any more. The only way I found to resolve up
to now is to kill all related ssh sessions with kill(1).

Note that just exiting the first shell after sending the ssh process
that created the control socket in the background works fine. Also
adding new sessions in a third terminal works then.

Note this is already reported to the Debian bug tracker under
https://bugs.debian.org/794063 and I was asked to forward it here.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2437

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org
             Status|NEW                         |ASSIGNED

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
I'm not sure how I missed this report at the time, but this bug is
reproducible.

The problem seems to be tty related and adding

+       ssh_signal(SIGTTIN, SIG_IGN);
+       ssh_signal(SIGTTOU, SIG_IGN);

to ssh.c makes it a little better: the 2nd window no longer hangs but
the first one still does.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2437

Nikola <zlatistiv at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zlatistiv at gmail.com

--- Comment #2 from Nikola <zlatistiv at gmail.com> ---
Created attachment 3876
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3876&action=edit
bugzilla 2437

Causes regression in connection-timeout.sh

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2437

--- Comment #3 from Nikola <zlatistiv at gmail.com> ---
Attached patch "fixes" it by dropping the client to a normal
connection
if it connects from the same terminal.

I suppose there is no other way since the master being in the
background will always get a SIGTTIN/OU when it tries to read from the
terminal of the client (which is also its own terminal).

The attachment causes regression in connection-timeout.sh which I'm yet
to figure out why.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.