Dlaczego mój limit czasu ssh zależy od lokalizacji sieci?

15

Kiedy jestem ssh'ed na jednym z naszych serwerów biurowych (na których działa Fedora 10) z domu, moja sesja kończy się po dość krótkim okresie aktywności (około 5 minut). Próbowałem używać TcpKeepAlivepo stronie klienta, bez skutku.

Nie rozumiem tego, że jeśli jestem w biurze w firmowej sieci LAN, mogę pozostawić sesję nieaktywną przez cały dzień bez przekroczenia limitu czasu, więc zachowanie wydaje się zależeć od mojej lokalizacji.

Wszelkie pomysły, dlaczego tak się dzieje i jak zapobiec przekroczeniu limitu czasu, gdy nie jestem w sieci LAN? Używam klienta terminalu w systemie Mac OSX, jeśli to pomaga.

AKTUALIZACJA - Sugestia Dave'a Dragera, by użyć ServerAliveIntervalzestawu do wartości niezerowych z, TcpKeepAlive=nozadziałało dla mnie. Jeśli chodzi o inne odpowiedzi, ClientAlive... ustawienia nie są akceptowane przez klienta SSH Mac OSX.

— gareth_bowles
źródło

6

Jest dobry writeup na ten problem tutaj .

Polecają:

ssh -o TCPKeepAlive=yes

lub:

ssh -o TCPKeepAlive=no -o ServerAliveInterval=15

Mam jednak problem na mojej stronie pracy, w której jestem odłączony od sesji, gdzie w domu wszystko jest w porządku. Wierzę, że moja zapora ogniowa (SonicWall) może flirtować z TCPKeepAlive, być może z powodu NAT.

Mój klient SSH, SecureCRT, na szczęście ma opcję protokołu „NO-OP”, który, jak sądzę, zasadniczo wysyła polecenie, które nic nie robi na serwer. Dzięki ręcznemu włączeniu mogę pozostać w kontakcie. Nie jestem pewien, co ma terminal klienta MacOSX, który jest podobny do tego. Istnieje opis sposobu implementacji „NO-OP” w wierszu poleceń.

Na koniec możesz użyć Wiresharka lub innego sniffera do obejrzenia rzeczywistego połączenia TCP, aby dowiedzieć się, co się z nim dzieje. To byłby ostatni sposób, aby zobaczyć, dlaczego wciąż się rozłącza.

— Dave Drager
źródło

Dzięki, Dave - opcja ServerAliveInterval działała świetnie.

— gareth_bowles

@Dave Słyszałem, że niektórzy administratorzy serwerów są rozczarowani tą praktyką, ponieważ może to oznaczać (a) ryzyko bezpieczeństwa lub (b) nieuzasadnione obciążenie serwera. Czy którakolwiek z tych obaw jest ważna, IYHO?

— Jonathan Day

Jest to ustawienie punktu końcowego klienta, więc chociaż jesteś w nieprzyjaznym środowisku, może to zwiększyć zdolność kogoś do sfałszowania cię, ale jest bardzo mało prawdopodobne, aby wpłynęło to na bezpieczeństwo połączenia. Naprawdę nie widzę, żeby to powodowało dodatkowe obciążenie.

— Dave Drager

@Dave: Wprowadziłem to polecenie, ale otrzymałem następujące, użycie: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b adres_indeksu] [-c specyfikacja_programu] [-D [adres_indeksu:] port] [-e plik_wyjścia] [-F plik konfiguracyjny] [- I pkcs11] [-i plik_identyfikacji] [-L [adres_powiązania:] port: host: port_portowy] [-l nazwa_logowania] [-m mac_spec] [-O ctl_cmd] [-o opcja] [-p port] [-R [ bind_address:] port: host: hostport] [-S ścieżka ctl] [-W host: port] [-w local_tun [: remote_tun]] [użytkownik @]

— nazwa

Ta poprawka działała również dla PuTTY. Jedyną opcją, którą musiałem ustawić, było Połączenie -> Sekundy między Keepalive: 15. Sesja SSH trwa i trwa już ponad 8 godzin (Comcast), podczas gdy zwykle rozłącza się w <30 minut.

— Dan Dascalescu,

2

Jest to prawdopodobnie spowodowane tym, że gdy łączysz się z domu, przechodzisz przez zaporę sieciową, która zamyka sesję TCP po krótkim czasie. Ale TcpKeepAlive powinien tego unikać. Czy włączyłeś TcpKeepAlive po stronie klienta czy po stronie serwera?

— promień
źródło

Zrobiłem TcpKeepAlive po stronie klienta (w moim ~ / .ssh / config) - myślałem, że to rozwiąże lokalne problemy zapory ogniowej, ale wciąż przekracza limit czasu.

— gareth_bowles

Domyślnie jest on „włączony” po stronie serwera, ale sprawdź sshd_config, aby zobaczyć, czy nie został wyłączony.

— promień

Niektóre zapory ogniowe rozłączają połączenie TCP po pewnym czasie NAWET, jeśli nie są bezczynne.

— TomOnTime,

Niektóre zapory ogniowe rozłączają połączenie TCP po pewnym czasie NAWET, jeśli nie są bezczynne. Sposobem na wykrycie tego jest sprawdzenie, czy konsekwentnie się rozłączasz.

— TomOnTime,

Oto ustawienia, których użyłem do naprawy: TCPKeepAlive nie, ClientAliveInterval 300, ClientAliveCountMax 3

— Matt Simmons

2

Cały czas otrzymuję to przez połączenie Comcast. Problem polega na tym, że interwał utrzymywania aktywności klienta SSH jest zbyt długi dla limitu czasu skonfigurowanego na ścieżce sieciowej. Jeśli korzystasz z systemu Linux, możesz zmodyfikować wartości ServerAliveIntervali ServerAliveCounter, aby były niższe niż ich wartości domyślne. Ta wartość jest ustawiana w sekundach. Ogólnosystemowy plik konfiguracyjny znajduje się (ogólnie) w /etc/ssh/ssh_config. Ustawienie tych dwóch AND TcpKeepAlivepowinno pomóc w utrzymaniu połączenia.

— sysadmin1138
źródło

1

Jak mówi promień, niektóre zapory ogniowe z pełnym stanem zapominają połączenia po pewnym (zwykle konfigurowalnym) czasie i nie pozwalają na dalszą komunikację dla połączenia; spodziewają się, że połączenie zacznie się od TCP SYN (odsyłam do twojej komunikacji SSH tutaj).

Jest inna możliwość. Ścieżka sieciowa między Twoim domem a biurem może mieć straty (w rodzaju pakietu). Podczas próby wpisania na kliencie SSH, jeśli link utknął na jakiś czas, klient może się poddać i zawieść.

Konfiguracja Keepalive na kliencie obsłuży pierwszy przypadek tutaj, ale nie może pomóc w drugim przypadku. Zapora zwykle znajduje się na obrzeżach biura i dlatego może być konfigurowalna. Pomogłoby to również w pierwszym punkcie.

Aby sprawdzić, czy występują przerywane straty łącza, można pozostawić aktywne polecenie ping w tle na komputerze klienta.

— nik
źródło

0

Możesz także dodać ustawienia sugerowane przez innych jako domyślne w ~/.ssh/configpliku, więc nie musisz ich przekazywać za sshkażdym razem, gdy inicjujesz połączenie:

nano ~/.ssh/config i dodaj:

TCPKeepAlive=no
ServerAliveInterval=15

— Dan Dascalescu
źródło