When a control master is running because it still has clients, but the command that that master originally ran has already exited, a client will incorrectly exit 255. It will otherwise work correctly. > cat ~/.ssh/config ControlMaster auto ControlPath ~/.ssh/mux/%r@%h:%p > ssh -f remote-host sleep 60 Password: > ssh -n remote-host sleep 300 & [3] 9166 > ssh -vv remote-host date OpenSSH_5.1p1, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /home/xxx/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: auto-mux: Trying existing master Tue Mar 10 12:31:01 GMT 2009 debug2: Received EOF from master debug2: Received exit status from master 0 > echo $? 0 > sleep 60 > ssh -vv remote-host date OpenSSH_5.1p1, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /home/xxx/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: auto-mux: Trying existing master Tue Mar 10 12:32:14 GMT 2009 debug2: Received EOF from master debug2: Control master terminated unexpectedly > echo $? 255
Created attachment 1617 [details] vs 5.2p1 - Don't recycle channel id 0 The attached patch prevents channel id 0 from being reused. This causes client_input_channel_req to correctly forward the exit value to the mux client.
Created attachment 1719 [details] prefer to dispatch exit statuses via mux control fd I think this approach is better: this implicitly identifies mux channels that have recycled the initial session ID by preferring to dispatch exit statuses via ones that have a control FD (i.e. mux channels) to ones that don't (i.e. the initial session).
Put this on the list for openssh-5.4
patch applied. The fix will be in OpenSSH 5.4 - thanks for the detailed report.
With the release of 5.4p1, this bug is now considered closed.