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

15

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

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

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

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

— gareth_bowles
источник

6

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

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

ssh -o TCPKeepAlive=yes

или:

ssh -o TCPKeepAlive=no -o ServerAliveInterval=15

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

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

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

— Дэйв Драгер
источник

Спасибо, Дэйв, опция ServerAliveInterval работала отлично.

— gareth_bowles

@ Дэйв Я слышал, что некоторые администраторы сервера недовольны этой практикой, так как это может быть (а) угроза безопасности или (б) неоправданная загрузка сервера. Является ли любая из этих проблем действительной, IYHO?

— Джонатан Дэй

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

— Дэйв Драгер

@Dave: я ввел эту команду, но получил следующее использование: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [порт bind_address:]] [-e escape_char] [-F configfile] [- I pkcs11] [-i имя_файла] [-L [адрес_привязки:] порт: хост: имя_хоста] [-l имя_пользователя] [-m mac_spec] [-O ctl_cmd] [-o опция] [-p порт] [-R [ bind_address:] порт: хост: hostport] [-S ctl_path] [-W хост: порт] [-w local_tun [: remote_tun]] [пользователь @] имя хоста [команда]

— user1050619

Это исправление сработало и для PuTTY. Единственная опция, которую я должен был установить, была в Соединении -> Секунды между Keepalive: 15. Сеанс SSH был жив и хорошо в течение более 8 часов (Comcast), хотя обычно он отключался через <30 минут.

— Дан Даскалеску

2

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

— радиус
источник

Я сделал TcpKeepAlive на стороне клиента (в моем ~ / .ssh / config) - я думал, что это решит проблемы с локальным брандмауэром, но время ожидания истекло.

— gareth_bowles

По умолчанию он включен на стороне сервера, но проверьте sshd_config, чтобы убедиться, что он не отключен.

— Радиус

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

— TomOnTime

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

— TomOnTime

Вот настройки, которые я использовал для исправления: TCPKeepAlive no, ClientAliveInterval 300, ClientAliveCountMax 3

— Мэтт Симмонс

2

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

— sysadmin1138
источник

1

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

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

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

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

— Nik
источник

0

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

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

TCPKeepAlive=no
ServerAliveInterval=15

— Дан Дакалеску
источник