Bug 3243 - Introduce multiplex timeout configuration
Summary: Introduce multiplex timeout configuration
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 8.2p1
Hardware: Other Linux
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-15 21:16 AEDT by thomas.hartwig
Modified: 2020-12-31 23:10 AEDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description thomas.hartwig 2020-12-15 21:16:45 AEDT
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.
Comment 1 Damien Miller 2020-12-16 09:29:02 AEDT
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?
Comment 2 thomas.hartwig 2020-12-31 23:10:48 AEDT
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.