Jakie dokładnie opcje `ServerAliveInterval` i` ClientAliveInterval` w sshd_config?

Znalazłem to pytanie , ale przepraszam, nie do końca rozumiem ustawienia dwóch zmiennych ServerAliveIntervali ClientAliveIntervalwspomniane w zaakceptowanej odpowiedzi. Jeśli mój serwer lokalny kończy limit czasu, czy powinienem ustawić tę wartość na zero? Czy to nigdy nie przekroczy limitu czasu? Czy zamiast tego powinienem ustawić 300 sekund czy coś w tym rodzaju?

Moje pytanie brzmi po prostu: niektóre z moich połączeń tracą ważność, kiedy zawieszam, a następnie zawieszam laptopa z odpowiedzią, Write failed: Broken pipea niektóre nie. Jak mogę poprawnie skonfigurować lokalny sshd, aby nie zawiódł przy uszkodzonej rurze?

ServerAliveInterval : liczba sekund, które klient będzie czekał przed wysłaniem pakietu zerowego na serwer (aby utrzymać połączenie przy życiu).

ClientAliveInterval : liczba sekund, przez którą serwer będzie czekał przed wysłaniem pakietu zerowego do klienta (aby utrzymać połączenie przy życiu).

Ustawienie wartości 0 (domyślnie) spowoduje wyłączenie tych funkcji, więc połączenie może zostać zerwane, jeśli będzie zbyt długo bezczynne.

ServerAliveInterval wydaje się być najczęstszą strategią utrzymywania połączenia przy życiu. Aby zapobiec problemowi z uszkodzoną rurą, oto konfiguracja ssh, której używam w moim pliku .ssh / config:

Host myhostshortcut
     HostName myhost.com
     User barthelemy
     ServerAliveInterval 60
     ServerAliveCountMax 10

Powyższe ustawienie będzie działać w następujący sposób:

1. Klient będzie czekał bezczynnie przez 60 sekund (czas ServerAliveInterval), a następnie wyśle ​​do serwera „zerowy pakiet zerowy” i oczekuje odpowiedzi. Jeśli nie otrzyma żadnej odpowiedzi, będzie próbować powyższego procesu aż do 10 (ServerAliveCountMax) razy (600 sekund). Jeśli serwer nadal nie odpowiada, klient rozłącza połączenie ssh.

ClientAliveCountMax po stronie serwera może również pomóc. Jest to limit czasu, przez jaki klient może pozostawać bez odpowiedzi przed rozłączeniem. Wartość domyślna to 3, jak w trzech ClientAliveInterval.

Jest to wyjaśnione w sshd_configmanual ( man sshd_config):

ClientAliveInterval

Ustawia limit czasu w sekundach, po upływie którego nie otrzymano żadnych danych od klienta, sshd wyśle ​​wiadomość przez zaszyfrowany kanał z prośbą o odpowiedź od klienta. Wartość domyślna to 0, co oznacza, że ​​te wiadomości nie będą wysyłane do klienta. Ta opcja dotyczy tylko protokołu w wersji 2.

ClientAliveCountMax

Wartość domyślna to 3. Jeśli ClientAliveInterval(patrz poniżej) jest ustawiona na 15 i ClientAliveCountMaxpozostała domyślna, niereagujący klienci SSH zostaną rozłączeni po około 45 sekundach. Ta opcja dotyczy tylko protokołu w wersji 2.

Aby zapoznać się z opcjami klienta, zobacz wyjaśnienie w man ssh_config:

ServerAliveInterval

Ustawia limit czasu w sekundach, po którym, jeśli nie otrzymano żadnych danych z serwera, sshwyśle ​​wiadomość przez zaszyfrowany kanał z prośbą o odpowiedź z serwera. Wartość domyślna to 0, co oznacza, że ​​te wiadomości nie będą wysyłane na serwer. Ta opcja dotyczy tylko protokołu w wersji 2.

ServerAliveCountMax

Wartość domyślna to 3. Jeśli, na przykład, ServerAliveIntervaljest ustawiona na 15 i ServerAliveCountMaxpozostanie domyślna, jeśli serwer przestanie odpowiadać, sshrozłączy się po około 45 sekundach. Ta opcja dotyczy tylko protokołu w wersji 2.

W oparciu o powyższe 0 oznacza, że ​​jest wyłączone. Dlatego należy ustawić te wartości na tyle, aby uniknąć błędu Broken pipe .

Odpowiedź Barthelemy jest fajna, ale tak naprawdę nie dochodzi do sedna problemu. Zawieszasz komputer i chcesz, aby sesja SSH nadal działała podczas uruchamiania komputera.

Nie ma takiej konfiguracji dla ssh, która utrzymywałaby połączenie w ten sposób. SSH używa TCP, na początek potrzebujesz trójdrożnego uzgadniania, a następnie utrzymuj się przy życiu po pewnym czasie bezczynności. Po wyłączeniu / hibernacji wszystkie połączenia TCP są zamykane za pomocą FIN. Nie da się tego pokonać.

Aby uzyskać brudne obejście, możesz użyć VPS lub innego urządzenia online z ekranem, aby zachować połączenie. Moja rada nie rób tego ze względów bezpieczeństwa.

Ponieważ nie możesz zagwarantować, że połączenie SSH (będące TCP) pozostanie aktywne, gdy jeden koniec przestanie wysyłać ACK do otrzymanych pakietów, osobiście korzystam z http://www.harding.motd.ca/autossh/, aby zrestartować wszystkie moje połączenia SSH prawie jak tylko się zawieszam.

Ponieważ GNU Screen będzie używany po stronie serwera, ponowne podłączenie prowadzi mnie tam, gdzie byłem wcześniej.

Możesz mieć nasłuchiwanie na dodatkowych portach, aby stale sprawdzać, czy połączenia są nadal aktywne, ale osobiście uważam, że działa wystarczająco dobrze z tym wyłączonym i polegając tylko na własnym SSH ServerAliveInterval/ ServerAliveCountMax.

Inną opcją jest http://mosh.mit.edu/, która wykorzystuje UDP i bezproblemowo odzyskuje po długotrwałym braku łączności.

Możesz także uruchamiać polecenia, nohupjeśli chcesz, aby były uruchamiane niezależnie od połączenia SSH.

na przykład

$ nohup tar -xzf some_huge.tar.gz &

&Jest, jak sądzę, nie jest konieczne, ale jest wygodne, ponieważ to sprawia, przebiegu procesu w tle, dzięki czemu można robić inne rzeczy.

Zawsze używam nohup do każdego procesu, który zajmuje trochę czasu, więc nie muszę zaczynać od nowa, jeśli stracę połączenie z jakiegokolwiek powodu - przerwa w zasilaniu (w mojej zdalnej lokalizacji, oczywiście nie na hoście), przerwa w sieci, cokolwiek.

Umieść swoją długotrwałą sesję na ekranie Zobacz szczegóły na ekranie -h

W ten sposób możesz ponownie połączyć się z maszyną za pomocą ssh i ponownie podłączyć się do sesji ekranowej