☰

ServerAliveCountMax в SSH

tag-icon • tag-icon ssh
ServerAliveCountMax в SSH

Что на самом деле делает ServerAliveCountMax в SSH?

Я пытаюсь убедиться, что при подключении к моему серверу через SSH соединение остается открытым в течение длительного периода времени, а не разрывается после короткого периода бездействия. Вот пример

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 2

Я слышал отодин источникчто указанная выше настройка всегда будет отправлять ответ на сервер каждые 60 секунд, пока сервер получает этот ответ. Однако если по какой-либо причине ответ не доходит до сервера, он попытается отправить другое сообщение. Если и это сообщение не доходит, то он закроет соединение. (Я считаю, что это неправильно)

TheвторойитретийИсточник, однако, говорит нечто иное. Они утверждают, что сообщение будет отправляться на сервер каждые 60 секунд, если будет период бездействия, но он отправит только через 2 запроса, а затем закроет соединение.

Так что же именно делает ServerAliveCountMax?

решение1

Ваше ощущение, что «это неправильно», верно.См. страницу руководства:

 ServerAliveCountMax
         Sets the number of server alive messages (see below) which may be
         sent without ssh(1) receiving any messages back from the server.
         If this threshold is reached while server alive messages are
         being sent, ssh will disconnect from the server, terminating the
         session.  It is important to note that the use of server alive
         messages is very different from TCPKeepAlive (below).  The server
         alive messages are sent through the encrypted channel and there‐
         fore will not be spoofable.  The TCP keepalive option enabled by
         TCPKeepAlive is spoofable.  The server alive mechanism is valu‐
         able when the client or server depend on knowing when a connec‐
         tion has become inactive.

         The default value is 3.  If, for example, ServerAliveInterval
         (see below) is set to 15 and ServerAliveCountMax is left at the
         default, if the server becomes unresponsive, ssh will disconnect
         after approximately 45 seconds.  This option applies to protocol
         version 2 only.

 ServerAliveInterval
         Sets a timeout interval in seconds after which if no data has
         been received from the server, ssh(1) will send a message through
         the encrypted channel to request a response from the server.  The
         default is 0, indicating that these messages will not be sent to
         the server.  This option applies to protocol version 2 only.

решение2

Сообщения Server alive полезны, когда сервер SSH настроен на закрытие соединений после определенного периода времени без трафика (например, провайдеры общего веб-хостинга, предлагающие доступ по SSH, почти всегда так делают). Установка этих двух параметров отправляет пакет каждую ServerAliveIntervalсекунду, в течение максимального количества ServerAliveCountMaxраз, таким образом, поддерживая сеанс в активном состоянии.

Чтобы ответить на комментарии о неопределенности установки любого из вариантов в значение 0, я прочитал исходный код реализации openssh, и вот что я вижу...

  • При выборе ServerAliveIntervalзначения 0пакеты НЕ будут отправляться, но сеанс будет поддерживаться в активном состоянии неограниченное время, при условии, что соединение не будет разорвано из-за истечения времени ожидания TCP и что сервер не настроен на отключение неактивных клиентов.

  • Установка ServerAliveCountMaxзначения 0имеет тот же эффект, что и установка ServerAliveIntervalзначения 0.

  • Установка любого из значений, отрицательного или большего INT_MAX(например, 2 147 483 647), приведет к"целое число..."ошибка.

  • Установка значения ServerAliveCountMaxот INT_MAX/1000+1(т. е. 2 147 484) до INT_MAX(т. е. 2 147 483 647) также будет эквивалентна установке любого из значений на 0.

Итак, по сути, наибольшее количество тайм-аутов, которые вы можете получить (при отправке пакетов), составляет INT_MAX/1000(т. е. 2 147 483). При тайм-ауте 1и полном отсутствии трафика в сеансах это даст вам почти 25 дней.

Очевидно, что другие реализации SSH могут дать иные результаты.

Связанный контент