Чому час очікування мого ssh залежить від розташування мережі?

15

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

Що я не розумію, це те, що якщо я перебуваю в офісі компанії LAN, я можу залишити сеанс неактивним цілий день без його вичерпання, тому поведінка, здається, залежить від мого місця розташування.

Будь-які ідеї, чому це відбувається і як запобігти тайм-аутам, коли я не в мережі? Я використовую клієнт Terminal на Mac OSX, якщо це допомагає.

ОНОВЛЕННЯ - Пропозиція Дейва Дражера використовувати ServerAliveIntervalнабір не-нульовий, TcpKeepAlive=noдля мене працювала. Щодо деяких інших відповідей, то ClientAlive... налаштування не приймаються клієнтом Mac OSX SSH.

— 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 або іншим sniffer, щоб переглянути своє фактичне TCP-з'єднання, щоб дізнатися, що з ним відбувається. Це був би останній спосіб зрозуміти, чому вона все ще періодично відключається.

— Дейв Драгер
джерело

Дякую, Дейв - варіант ServerAliveInterval чудово працював.

— gareth_bowles

@Dave я чув, що деякі адміністратори сервера нахмурилися на цю практику, оскільки це може бути (а) ризиком безпеки або (b) необгрунтованим завантаженням сервера. Чи дійсне будь-яке з цих питань, IYHO?

— День Джонатана

Це налаштування на кінцевій точці клієнта, тому, якщо ви перебуваєте у ворожій обстановці, це може призвести до того, що хтось може сфабрикувати вас, дуже навряд чи це вплине на безпеку з'єднання. Я також не можу побачити, що це спричиняє додаткове навантаження.

— Дейв Драгер

@Dave: Я ввів цю команду, але отримав наступне, використання: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [bind_address:] порт] [-e escape_char] [-F configfile] [- Я pkcs11] [-iдентифікатор_файлу] [-L [bind_address:] порт: host: hostport] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-R [ bind_address:] порт: хост: hostport] [-S ctl_path] [-W host: port] [-w local_tun [: remote_tun]] [user @] hostname [command]

— user1050619

Це виправлення працювало і для PuTTY. Єдиний варіант, який мені довелося встановити, - це З'єднання -> Секунди між Keepalive: 15. Сеанс SSH був активний та здоровий протягом більше 8 годин (Comcast), хоча він зазвичай відключався за <30 хвилин.

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

2

Це, мабуть, тому, що під час підключення додому ви проходите через брандмауер, який закриває сеанс TCP через невелику кількість часу. Але TcpKeepAlive повинен цього уникати. Чи ввімкнено TcpKeepAlive на стороні клієнта чи на сервері?

— радіус
джерело

Я зробив TcpKeepAlive на стороні клієнта (в моєму ~ / .ssh / config) - я думав, що це вирішить локальні проблеми з брандмауером, але це все-таки вичерпується.

— gareth_bowles

За замовчуванням він стоїть "увімкнено" на стороні сервера, але перевірте sshd_config, щоб перевірити, чи він не був відключений.

— радіус

Деякі міжмережеві стіни відключають TCP-з'єднання через певний час, навіть якщо вони не працюють.

— TomOnTime

Деякі міжмережеві стіни відключають TCP-з'єднання через певний час, навіть якщо вони не працюють. Спосіб виявити це - побачити, якщо ви постійно відключаєтесь.

— TomOnTime

Ось налаштування, які я використовував для виправлення: TCPKeepAlive ні, ClientAliveInterval 300, ClientAliveCountMax 3

— Метт Сіммонс

2

Я отримую це постійно на своєму з'єднанні Comcast. Проблема полягає в тому, що інтервал збереження вашого клієнта SSH занадто довгий для часу очікування, налаштованого у вашому мережевому шляху. Якщо ви на Linux, ви можете змінити ServerAliveIntervalі ServerAliveCounterзначення нижче , ніж за замовчуванням. Це значення встановлюється в секундах. Загальносистемний конфігураційний файл знаходиться (як правило) у /etc/ssh/ssh_config. Налаштування цих двох AND TcpKeepAliveмає допомогти продовжувати зв’язок.

— sysadmin1138
джерело

1

Як каже радіус, деякі брандмауери, повністю заповнені станом, "забувають" про з'єднання через певний (як правило, налаштований) час і не дозволять подальше спілкування для з'єднання; вони очікують, що з'єднання розпочнеться з TCP SYN (я посилаюся на ваше повідомлення SSH тут).

Є ще одна можливість. Мережевий шлях між вашим домом та офісом може мати втрати (типу пакету). Коли ви намагаєтеся ввести клієнт SSH, якщо ваше посилання на деякий час зупинилося, клієнт може відмовитись і вийти з ладу.

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

Щоб перевірити, чи є у вас переривчасті втрати посилання, ви можете підтримувати "ping" у фоновому режимі з вашого клієнтського комп'ютера.

— нік
джерело

0

Ви також можете додати параметри, запропоновані іншими, як за замовчуванням у вашому ~/.ssh/configфайлі, так що вам не доведеться передавати їх sshкожен раз, коли ви ініціюєте з'єднання:

nano ~/.ssh/config і додати:

TCPKeepAlive=no
ServerAliveInterval=15

— Дан Даскалеску
джерело