Освойте инструменты и лучшие практики DevOps — Центр знаний DevOps Освойте инструменты и лучшие практики DevOps — Центр знаний DevOps

Лучшие практики предотвращения проблем с тайм-аутом SSH

Предотвратите разрывы бездействующих SSH-соединений с помощью клиентских keepalive, разумных настроек сервера и tmux или screen для длительной работы.

Лучшие практики предотвращения проблем с тайм-аутом SSH

Тайм-ауты SSH обычно проявляются, когда ваш терминал зависает после нескольких минут бездействия, а затем выводит ошибку разрыва соединения или сброса подключения. Причиной часто является брандмауэр, NAT-шлюз, VPN или балансировщик нагрузки, которые разрывают бездействующие TCP-сессии до того, как ваш SSH-клиент заметит это.

Наиболее полезным решением является использование SSH keepalive со стороны клиента. Настройки на стороне сервера также могут помочь, но они служат другой цели и могут отключать неактивные клиенты, если установлены слишком агрессивно.

Понимание коренной причины тайм-аутов SSH

Тайм-аут SSH возникает, когда канал связи между клиентом и сервером разрывается, поскольку ни одна из сторон не обнаружила активности в течение определенного времени. Обычно это не само SSH-программное обеспечение, а промежуточные сетевые устройства (брандмауэры, маршрутизаторы и NAT-таблицы), которые агрессивно обрезают бездействующие соединения для экономии ресурсов.

Когда брандмауэр не видит трафика по определенному TCP-соединению в течение нескольких минут, он предполагает, что сессия мертва, и сбрасывает состояние соединения. При следующей попытке SSH-клиента отправить данные сервер их не получает, что приводит к зависанию сессии и последующей ошибке тайм-аута.

Решение состоит в том, чтобы настроить SSH на регулярную отправку сигналов keep-alive (небольших пакетов без данных), гарантируя, что промежуточные устройства распознают соединение как активное.

1. Решения на стороне клиента: ServerAliveInterval

Наиболее распространенное и простое решение для предотвращения тайм-аутов — настройка SSH-клиента на периодическую отправку keep-alive сообщения на сервер. Это контролируется директивой ServerAliveInterval.

Как работает ServerAliveInterval

ServerAliveInterval задает время в секундах, по истечении которого клиент отправляет нулевой пакет на сервер, если от сервера не было получено никаких данных. Это значение гарантирует, что клиент поддерживает состояние соединения.

Конфигурация через ~/.ssh/config

Этот метод рекомендуется, так как позволяет установить конфигурацию глобально или для конкретного хоста, сохраняясь после перезагрузок и в разных сессиях терминала.

Создайте или измените файл конфигурации клиента, обычно расположенный по адресу ~/.ssh/config:

nano ~/.ssh/config

Чтобы применить настройку глобально (ко всем хостам):

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

Пояснение значений:

  • ServerAliveInterval 60: Клиент будет отправлять keep-alive пакет каждые 60 секунд, если соединение бездействует.
  • ServerAliveCountMax 3: Если клиент отправит 3 последовательных keep-alive сообщения без получения ответа от сервера, клиент разорвет соединение. (Общая продолжительность тайм-аута: 60 секунд * 3 попытки = 180 секунд).

Конфигурация через командную строку

Если вам нужно временное решение или вы предпочитаете применить настройку только для одной сессии, используйте опцию -o при подключении:

ssh -o "ServerAliveInterval 60" user@remote_host

Совет: Значение от 30 до 60 секунд обычно является идеальным, так как оно достаточно частое, чтобы обойти большинство правил брандмауэра (часто установленных около 5 минут), но не настолько частое, чтобы создавать избыточную сетевую нагрузку.

2. Решения на стороне сервера: принудительное использование Keep-Alive

Хотя решения на стороне клиента (ServerAliveInterval) обычно достаточно, администраторы, управляющие серверами, к которым обращаются многие пользователи, могут захотеть централизованно применять настройки keep-alive или установить жесткие ограничения на бездействующие соединения. Это делается в файле конфигурации SSH-демона /etc/ssh/sshd_config.

Использование ClientAliveInterval и ClientAliveCountMax

Эти директивы являются серверными аналогами клиентских настроек. Они указывают серверу проверять, все ли еще подключен клиент.

  1. Откройте файл конфигурации SSH-демона:

    sudo nano /etc/ssh/sshd_config

  2. Добавьте или измените следующие строки:

    # Сервер отправляет сообщение client-alive через 300 секунд без трафика от клиента.
ClientAliveInterval 300

# Отключить после 3 неотвеченных сообщений client-alive.
ClientAliveCountMax 3

Примечание по ClientAliveCountMax:

Сообщения ClientAliveInterval — это зонды на уровне SSH, а не простая настройка "отключить после такого-то времени бездействия". С ClientAliveInterval 300 и ClientAliveCountMax 3 сервер отключается только примерно через 15 минут неотвеченных зондов. В OpenSSH ClientAliveCountMax 0 отключает эти серверные keep-alive сообщения, поэтому это не хороший пример принудительного тайм-аута.

  1. Перезапустите службу SSH, чтобы изменения вступили в силу:

    sudo systemctl reload sshd
# или
sudo service ssh reload

3. Продвинутые стратегии обеспечения отказоустойчивости

Хотя SSH keep-alive справляются с короткими периодами бездействия, полное прерывание сети (например, смена Wi-Fi сетей или временная потеря сигнала) все равно приведет к разрыву TCP-соединения. Для настоящей отказоустойчивости используйте инструменты управления сессиями.

Использование терминальных мультиплексоров (tmux или screen)

Терминальные мультиплексоры — это идеальная защита от разрывов соединения. Они запускают сессию на удаленном сервере, которая сохраняется, даже если ваше клиентское соединение разорвано. Вы можете отсоединиться от сессии, переподключиться позже (с того же или другого клиента) и снова присоединиться, чтобы продолжить с того же места.

Базовый рабочий процесс tmux:

  1. Подключитесь к серверу:
    ssh user@remote_host
  2. Запустите новую сессию tmux на сервере:
    tmux new -s my_session
  3. Работайте внутри сессии tmux.
  4. Если соединение разорвано или вам нужно уйти, отсоедините сессию (Ctrl+B, затем D).
  5. Переподключитесь к серверу по SSH.
  6. Снова присоединитесь к существующей сессии:
    tmux attach -t my_session

Различие между SSH Keep-Alive и TCP Keep-Alive

Можно использовать механизм TCP Keep-Alive базовой операционной системы, часто настраиваемый с помощью директивы TCPKeepAlive yes в sshd_config. Однако SSH-keep-alive (ServerAliveInterval) обычно предпочтительнее, потому что:

  1. Переносимость: Директивы SSH работают одинаково независимо от настроек ядра базовой ОС.
  2. Уровень приложения: SSH keep-alive работают на уровне приложения, гарантируя, что SSH-демон остается отзывчивым.
  3. Осведомленность брандмауэра: TCP keep-alive иногда могут быть молча заблокированы брандмауэрами или NAT-устройствами, которые проверяют только активность полезной нагрузки, тогда как SSH keep-alive специально разработаны для успешного прохождения через эти уровни.

Если вы решите использовать TCPKeepAlive yes, помните, что фактический интервал времени контролируется операционной системой (например, net.ipv4.tcp_keepalive_time в Linux), а не конфигурацией SSH.

Сводка лучших практик

Проблема Директива конфигурации Местоположение Рекомендуемое значение Цель
Тайм-ауты клиента ServerAliveInterval ~/.ssh/config (Клиент) 30 - 60 секунд Отправляет нулевые пакеты от клиента к серверу для предотвращения сброса брандмауэром.
Порог отключения клиента ServerAliveCountMax ~/.ssh/config (Клиент) 3 - 5 Количество пропущенных ответов, после которых клиент отключается.
Принудительное бездействие сервера ClientAliveInterval /etc/ssh/sshd_config (Сервер) 300 секунд (5 мин) Отправляет проверки от сервера к клиенту для мониторинга активности.
Отказоустойчивость соединения Н/Д Сессия сервера tmux или screen Позволяет сохранять сессию при сбое сети.

Начните с ServerAliveInterval в конфигурации вашего клиента. Для длительных миграций, обновлений пакетов или расследований логов запускайте работу внутри tmux или screen, чтобы разрыв сетевого пути не убил задачу.