Соединение SSH зависает на точке доступа 4G, но не на любом Wi-Fi
Если вы использовали команду rm, то единственный способ узнать, какие файлы доступны для восстановления, — это восстановить их. Я не знаю таких инструментов для Linux, извините. Если вы использовали графический интерфейс, просто загляните в папку, заполненную удаленными элементами.
Я предполагаю, что причиной этого является система, отслеживающая (и забывающая )соединения с сохранением состояния. Когда используется NAT (, а это очень часто бывает, когда не используется IPv6 ), тогда обычно системе, выполняющей NAT, требуется память, чтобы помнить, куда отправлять ответы. Для вашего широкополосного Wi-Fi система, использующая NAT, может иметь больше памяти для запоминания активных соединений (, например, Linux netfilter 's conntrack по умолчанию запоминает TCP-соединения в течение 5 дней, при этом он запоминает UDP-потоки в течение 2-3 минут ). Эквивалентная система, использующая NAT на вашем пути 4G, вероятно, имеет более короткую память, чуть меньше 3 млн.
Чтобы обойти это, как вы нашли и указали в своем вопросе, вы можете установить специальный параметр ssh ServerAliveInterval, который будет периодически отправлять пустые данные (в качестве протокола SSH ), когда нет активности, аналогичной на TCP KeepAlive .Это сделает соединение всегда видимым для системы, выполняющей NAT, и не забудет об этом. Итак, в ваш файл ~/.ssh/configвы можете добавить:
ServerAliveInterval 115
при 115 выбрано значение чуть меньше 2 мин, чтобы оставаться консервативным :значение ниже расчетной продолжительности отслеживания активных подключений на невидимом устройстве NAT на пути, но не слишком мало (см. далее ). Так что в худшем случае, когда состояние отслеживания составляет 5 секунд от того, что его собираются удалить, оно возвращается к предполагаемому сроку службы 120 секунд.
Недостатком является то, что (в любом случае вы используете широкополосный доступ Wi-Fi ), если вы потеряете подключение на некоторое время, а затем восстановите его, это может заставить клиента подумать, что удаленный сервер не работает, и он закроет соединение.. Вы также можете настроитьServerAliveCountMaxдля этого, но в любом случае, если значение по умолчанию равно 3, это потребует примерно 3 *115 = 345 с потери соединения, более 5 минут, прежде чем появится шанс столкнуться с этой проблемой.
На стороне сервера есть эквивалент ClientAliveInterval, который вы можете вместо этого установить в его файле sshd_configдля той же цели. Это имело бы дополнительное преимущество, заключающееся в том, что клиентские соединения ssh-призраков не оставались подключенными в течение некоторого времени, когда клиентская сторона все равно теряла соединение.