openssh bugs - Dec 2020 - [Bug 3243] New: Introduce multiplex timeout configuration

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

            Bug ID: 3243
           Summary: Introduce multiplex timeout configuration
           Product: Portable OpenSSH
           Version: 8.2p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: thomas.hartwig at gmail.com

I use ssh multiplexing, from time to time my IP changes or the internet
connection is reset but the ControlMaster files are still present. When
I try to connect in such a case there is a large timeout until ssh
detects the connection is not valid any more and establishes a new
master connection. I have not found a settings which is shorten this
timeout.

Currently I use a config like this:

ControlPath /tmp/ssh-%r@%h:%p
ControlMaster=auto
ControlPersist=600

As a workaround in such a case I remove the ssh files manually before
new connect.

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
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.

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

--- Comment #2 from thomas.hartwig at gmail.com ---
Thanks for the suggestion, you are right the second pint addresses my
question. I appreciate your hint with keepalive but I am not sure about
it. It is a workaround. IMHO there should be an extra option like
ControlMasterTimeout.

-- 
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=3243

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
(In reply to thomas.hartwig from comment #2)
> Thanks for the suggestion, you are right the second pint addresses
> my question. I appreciate your hint with keepalive but I am not sure
> about it. It is a workaround. IMHO there should be an extra option
> like ControlMasterTimeout.
Depending on what you want, openssh-9.5 made ConnectTimeout apply to
controlmaster connections or openssh-9.2 added UnusedConnectionTimeout
that allows a server to terminate connections without any active
channels.

-- 
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.