Sometimes, when issuing a remote command via a multiplexed connection, it doesn't finish until I hit <ENTER>. Most of the times it terminates normally. This occurs approximately 1 out of 10 times. This affects the usage of multiplexed connections in scripts.

Adding -vvv to the "slave" connection shows: 

    debug3: mux_client_request_session: entering
    debug3: mux_client_request_alive: entering
    debug3: mux_client_request_alive: done pid = 5485
    debug3: mux_client_request_session: session request sent
    debug1: mux_client_request_session: master session id: 3
    <Have to hit ENTER here>
    debug3: mux_client_read_packet: read header failed: Broken pipe
    debug2: Received exit status from master 0

I checked out the code (commit 775f8a23f2353f5869003c57a213d14b28e0736e) and, after adding some additional log messages to mux.c, I notice the flow was blocking in mux_client_read(), in the call to poll():

    1428 static int                                                                       
    1429 mux_client_read(int fd, Buffer *b, u_int need)                                   
    1430 {                                      
    ...
    1450                         case EAGAIN:                                             
    1451                                 (void)poll(&pfd, 1, -1); <<<<<<<<<<<
    1452                                 /* FALLTHROUGH */                                

Steps to reproduce:
1. In a terminal, issue: 
   ssh -M -S $TMPDIR/master <host>
2. In another terminal, issue:
   for i in `seq 30`; do ssh -vvv -o ControlPath=$TMPDIR/master <host> ls; done

Expected behavior: the command finishes running without user interaction.

Actual behavior: approx. 1 out of 10 times it's necessary to press <ENTER> (no other key works) to continue executing the command.

WORKAROUND:

Notice that redirecting STDIN to /dev/null works around the problem (e.g., for i in `seq 30`; do ssh -vvv -o ControlPath=$TMPDIR/master <host> ls < /dev/null; done