Limit czasu SSH systemu Linux [zamknięty]

Walczę z przekroczeniem limitu czasu kilku systemów po X minutach bezczynności i nie jestem pewien, jak to naprawić.

Mam skrzynkę CentOS w moim biurze. Połącz z SSH nie może go dotknąć przez 2 godziny i nadal działa, gdy coś uruchomię.

Jednak połącz się z tym samym urządzeniem w domu i czasem upłynie limit czasu po kilku sekundach, a czasem po kilku minutach.

Myślę, że to moje połączenie internetowe, ale jeśli aktywnie korzystam z urządzenia, pozostanie ono połączone.

Jednak jeśli przestanę pisać coś w Google, wyświetli się rozłączony komunikat i muszę połączyć się ponownie.

Czy mogę coś sprawdzić, aby zobaczyć, co się dzieje?

Pierwszą rzeczą, na którą powinieneś zwrócić uwagę, jest ustawienie ServerAliveInterval. Należy to ustawić na stacji roboczej.

W klientach Linux lub OSX możesz utworzyć plik konfiguracyjny dla swojego użytkownika w ~ / .ssh / config na stacji roboczej. Dodaj następującą dyrektywę. W moim przypadku chcę, aby wpłynęło to na wszystkie hosty, dlatego umieściłem go pod Host *.

Host *
    ServerAliveInterval 60

Spowoduje to wysłanie instrukcji noop co 60 sekund, aby utrzymać połączenie otwarte. Możesz dostosować wartość do swoich potrzeb.

Po stronie serwera upewnij się, że TCPKeepAlive jest ustawione na tak.

grep TCPKeepAlive /etc/ssh/sshd_config
TCPKeepAlive yes

Jeśli korzystasz z systemu Windows, musisz odwołać się do dokumentacji klienta.

Linux nie przekracza limitów czasu bezczynnych połączeń SSH. Możesz pozostawić połączenie SSH otwarte przez czas nieokreślony, i dopóki żaden punkt końcowy nie zostanie zrestartowany ani nie otrzyma nowego adresu IP, połączenie będzie nadal działać po uzyskaniu dostępu do niego po długim czasie bezczynności.

Jednak jeśli istnieją jakieś stanowe skrzynki pośrednie (NAT, zapora ogniowa itp.), Prawdopodobnie przekroczą one czas bezczynności połączeń. Powoduje to, że chociaż połączenie jest żywe na obu końcach, dwa punkty końcowe nie mogą się już komunikować, ponieważ skrzynka środkowa odmawia przekazania jakichkolwiek pakietów, dopóki klient SSH nie otworzy nowego połączenia.

Jeśli wiesz, czas oczekiwania na middlebox, można obejść ten problem przez skonfigurowanie ClientAliveIntervalsię /etc/ssh/sshd_configna serwerze lub ServerAliveIntervalw ~/.ssh/configna kliencie. W celu optymalnego wykrywania przerwanych połączeń zaleca się włączenie obu ustawień. Wykryje to również zerwane połączenia, gdy którykolwiek punkt końcowy został ponownie uruchomiony lub uzyskał nowy adres IP.

Ponieważ wskazujesz, że czas oczekiwania wydaje się być tak krótki, jak kilka sekund, może to nie wystarczyć do rozwiązania problemu. Bardzo niski pozorny limit czasu może być spowodowany przeciążeniem lub nieprawidłową konfiguracją CGN. Musisz sprawdzić ruch w różnych punktach ścieżki komunikacyjnej, aby dowiedzieć się, czy CGN jest odpowiedzialny za awarie.

Jeśli okaże się, że awarie są spowodowane przez twojego ISP robiącego coś niemądrego, takiego jak połączenia z równoważeniem obciążenia przez wiele CGN, które nie współużytkują stanu połączenia, nie możesz sam rozwiązać problemu, po prostu dostosowując konfigurację SSH.

Jeśli zdarzy ci się utknąć z dostawcą usług internetowych z niewiarygodnym CGN, którego odmawiają naprawy, jedynymi pozostałymi opcjami, które znam, są albo uaktualnienie klienta i serwera do wersji jądra ze wsparciem MPTCP, albo użycie rozwiązania tunelowego zaprojektowanego tak, aby tolerować spontaniczne zmiany w mapowaniu portów na NAT.