Почему время ожидания SSH зависит от сетевого расположения?

Когда я ssh'ed на один из наших офисных серверов (которые запускают Fedora 10) из дома, мой сеанс истекает после довольно короткого периода активности (5 минут или около того). Я пытался использовать TcpKeepAliveна стороне клиента, безрезультатно.

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

Есть идеи, почему это происходит и как предотвратить тайм-ауты, когда я не нахожусь в локальной сети? Я использую Терминальный клиент на Mac OSX, если это поможет.

ОБНОВЛЕНИЕ - предложение Дейва Драгера об использовании ServerAliveIntervalнабора с ненулевым значением TcpKeepAlive=noсработало для меня. Что касается некоторых других ответов, ClientAliveнастройки ... не принимаются SSH-клиентом Mac OSX.

Существует хорошая рецензия на эту проблему здесь .

Они рекомендуют:

ssh -o TCPKeepAlive=yes

или:

ssh -o TCPKeepAlive=no -o ServerAliveInterval=15

Тем не менее, у меня есть проблема на моем рабочем месте, где я отключаюсь от сеансов, где дома они в порядке. Я считаю, что мой брандмауэр (SonicWall) может работать с TCPKeepAlive, возможно, из-за NAT.

Мой SSH-клиент, SecureCRT, к счастью, имеет опцию для протокола «NO-OP», который, я считаю, в основном отправляет команду, которая ничего не делает на сервере. Включив это вручную, я могу оставаться на связи. Не уверен, что клиент терминала MacOSX имеет то, что похоже на это. Существует описание того, как реализовать «NO-OP» в командной строке.

Наконец, вы можете захотеть использовать Wireshark или другой анализатор, чтобы посмотреть ваше фактическое TCP-соединение и выяснить, что с ним происходит. Это был бы последний способ увидеть, почему он все еще время от времени отключается.

Вероятно, это связано с тем, что при подключении из дома вы проходите через брандмауэр, который через некоторое время закрывает сеанс TCP. Но TcpKeepAlive должен избегать этого. Вы включили TcpKeepAlive на стороне клиента или на стороне сервера?

Я получаю это все время на моем соединении Comcast. Проблема в том, что интервал поддержания активности вашего SSH-клиента слишком велик для времени ожидания, настроенного в вашем сетевом пути. Если вы на Linux, вы можете изменить ServerAliveIntervalи ServerAliveCounterзначение ниже , чем по умолчанию. Это значение устанавливается в секундах. Общесистемный файл конфигурации находится (обычно) в /etc/ssh/ssh_config. Установка этих двух AND TcpKeepAliveдолжна помочь поддерживать соединение.

Как говорит радиус, некоторые межсетевые экраны с полным состоянием «забывают» соединение через определенное (обычно настраиваемое) время и не разрешают дальнейшую связь для соединения; они ожидают, что соединение начнется с TCP SYN (я обращаюсь к вашей связи SSH здесь).

Есть еще одна возможность. Сетевой путь между вашим домом и офисом может иметь потери (типа пакета). Когда вы пытаетесь набрать на клиенте SSH, если ваша ссылка на некоторое время остановилась, клиент может сдаться и потерпеть неудачу.

Конфигурация Keepalive на клиенте будет обрабатывать первый случай здесь, но не может помочь во втором случае. Брандмауэр обычно находится по периметру вашего офиса и поэтому может быть настраиваемым. Это также поможет в первом пункте.

Чтобы проверить, есть ли у вас периодические потери ссылок, вы можете поддерживать «пинг» в фоновом режиме со своего клиентского компьютера.

Вы также можете добавить параметры, предложенные другими, в качестве значений по умолчанию в вашем ~/.ssh/configфайле, чтобы вам не приходилось передавать их sshкаждый раз, когда вы устанавливаете соединение:

nano ~/.ssh/config и добавить:

TCPKeepAlive=no
ServerAliveInterval=15