https://bugzilla.mindrot.org/show_bug.cgi?id=3243
Damien Miller <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from Damien Miller <[email protected]> --- There are two possible situations that you're describing here: 1) The main multiplexing session has exited, leaving a stale ControlPath socket This happens if the ssh process doesn't get a change to exit gracefully, e.g. an abnormal exit, sudden reboot, laptop ran out of power, etc. In this case, the new ssh connection should notice the stale socket and reconnect immediately. 2) The main multiplexing session has stuck, leaving a valid but unresponsive ControlPath I suspect this is what you're experiencing - the connection might become stuck because you switched networks, unsuspended a laptop, etc. In this case, the ssh client will try to interact with the main multiplexing connection but, because it can no longer communicate with the peer sshd, nothing good happens. There already exist settings to detect and fix this: ServerAliveInterval and ServerAliveCountMax. These control protocol-level timeouts that will kill the connection if the server is persistently unresponsive. Setting them is a balance between responsiveness to stuck connections and tolerance of transient network problems. I use ServerAliveInterval 30 ServerAliveCountMax 8 In my ~/.ssh/config to set a 4 minute timeout for unresponsive connections. Does this help you? -- 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. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
