autossh nie zabija ssh przy łączeniu w dół

10

Rozpocząłem autossh witt czas sondowania 30 s:

AUTOSSH_POLL=30 AUTOSSH_LOGLEVEL=7 autossh -M 0 -f -S none -f -N -L localhost:34567:localhost:6543 user1@server1

I działa dobrze:

Sep  5 12:26:44 serverA autossh[20935]: check on child 23084
Sep  5 12:26:44 serverA autossh[20935]: set alarm for 30 secs

Ale jeśli fizycznie odłączę kabel sieciowy, co oznacza, że ​​tunel nie może już działać, autossh nie zabije demona ssh. Dlaczego? Rozumiem, że autossh nie może nic zrobić, jeśli link jest wyłączony, ale moim zdaniem powinien spróbować wykonać następujące czynności:

  1. Sprawdź proces potomny ssh ( check on child ...)
  2. Sprawdź drugi koniec !!! (operacja przypominająca ping przez tunel)
  3. Uświadom sobie, że tunel jest opuszczony
  4. Zatrzymaj proces ssh
  5. Spróbuj ponownie utworzyć tunel
  6. Uświadom sobie, że to nie działa, i ustaw licznik (wykładniczo rosnący?), Aby sprawdzić ponownie wkrótce

Właśnie dlatego uruchamiam autossh: jeśli coś stanie się z tunelem (problem oprogramowania lub sprzętu), powinien spróbować go zrestartować. Zamiast tego czeka tylko na proces ssh. Czy nie powinno to być próbą ponownego uruchomienia, nawet jeśli nie ma nadziei na ponowne nawiązanie połączenia?

Jakiego rodzaju sprawdzenie wykonuje autossh? Po prostu sprawdź, czy ssh jest uruchomiony? Czy to nie robi jakiejkolwiek kontroli końcowej?

Edytować

Zgodnie z życzeniem dodaję odpowiednią część konfiguracji ssh:

# (see http://aaroncrane.co.uk/2008/04/ssh_faster)
# The ServerAliveInterval tells SSH to send a keepalive message every 60 seconds while the connection is open;
#   that both helps poor-quality NAT routers understand that the NAT table entry for your connection should
#   be kept alive, and helps SSH detect when there’s a network problem between the server and client.
ServerAliveInterval 60
# The ServerAliveCountMax says that after 60 consecutive unanswered keepalive messages, the connection should
#   be dropped. At that point, AutoSSH should try to invoke a fresh SSH client. You can tweak those
#   specific values if you want, but they seem to work well for me.
ServerAliveCountMax 60

TCPKeepAlive yes
Dangonfast
źródło
co powiesz na próbę skrócenia limitu czasu?
Nikolaidis Fotis
Przez pewien czas korzystaliśmy z autossh, ale było to zbyt zawodne w przypadku niestabilnych połączeń, szczególnie w połączeniu z przekierowaniem portów. Używamy teraz OpenVPN i jesteśmy z niego bardzo zadowoleni.
Nils Toedtmann
@NikolaidisFotis: limit czasu jest w porządku. Upłynął limit czasu. Ale to nie robi właściwej rzeczy (imho) za każdym razem, gdy zaczyna się limit czasu, a mianowicie: weryfikacja odległego końca !
dangonfast
@NilsToedtmann: dzięki, spróbuję. Czy to jest łatwe do wdrożenia? Czy masz link do dobrego howto?
dangonfast
OpenVPN jest dość prosty, po prostu „apt-get install” go uruchomiliśmy i uruchomiliśmy z domyślnymi konfiguracjami serwera lub klienta, używając dev tunobu ustawień i konfiguracji remoteklienta. Jedynym irytującym bitem jest zarządzanie certyfikatami. Używamy urzędu certyfikacji „easy-rsa” dostarczanego z OpenVPN. Po uzyskaniu certyfikatów reszta jest łatwa.
Nils Toedtmann

Odpowiedzi:

11

Ale jeśli fizycznie odłączę kabel sieciowy, co oznacza, że ​​tunel nie może już działać, autossh nie zabije demona ssh. Dlaczego?

autossh działa na komputerze klienta, więc nie może bezpośrednio zabić procesu demona ssh na serwerze. Można jednak podać niezerową wartość parametru ClientAliveIntervalin /etc/ssh/sshd_configna serwerze (patrz man sshd_config) i zrestartować usługę sshd na serwerze, aby zastosować zmianę konfiguracji. Następnie w przypadku rozłączenia sieci proces demona ssh zostanie zabity po ClientAliveInterval * ClientAliveCountMaxkilku sekundach (ale nie przez autossh).

Teraz, jeśli chcesz zapytać „Dlaczego autossh nie zabija procesu klienta ssh?” , określiłeś -M 0. Na stronie podręcznika autossh:

Setting the monitor port to 0 turns the monitoring function off, and autossh will only restart ssh upon ssh's exit.

Zamiast używać autossh do monitorowania połączenia, czekasz na wyjście ssh po upływie ServerAliveCountInterval * ServerAliveCountMaxkilku sekund. Zażądałeś 60 sprawdzeń aktywności serwera przed wyjściem ssh, z 60-sekundowym odstępem oddzielającym kolejne sprawdzenia, więc będziesz czekać godzinę przed wyjściem klienta ssh.

Możesz również rozważyć użycie ExitOnForwardFailureopcji po stronie klienta (patrz man ssh_config), aby ssh wyszedł, jeśli nie może ustanowić tunelu, a następnie autossh może spróbować ponownie uruchomić ssh.

James W.
źródło
Dzięki, to ma sens. Rzeczywiście miałem na myśli „proces klienta”, a nie proces serwera.
dangonfast
A po ponownym przeczytaniu strony podręcznika autossh pamiętam teraz, dlaczego ustawiłem -M 0: nie jest łatwo korzystać z portu monitorowania i jest to pośrednio odradzane: pod wieloma względami może to być lepsze rozwiązanie niż port monitorowania
dangonfast,