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:
- Sprawdź proces potomny ssh (
check on child ...
) - Sprawdź drugi koniec !!! (operacja przypominająca ping przez tunel)
- Uświadom sobie, że tunel jest opuszczony
- Zatrzymaj proces ssh
- Spróbuj ponownie utworzyć tunel
- 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
źródło
dev tun
obu ustawień i konfiguracjiremote
klienta. 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.Odpowiedzi:
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
ClientAliveInterval
in/etc/ssh/sshd_config
na serwerze (patrzman 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 poClientAliveInterval * ClientAliveCountMax
kilku 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 * ServerAliveCountMax
kilku 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
ExitOnForwardFailure
opcji po stronie klienta (patrzman ssh_config
), aby ssh wyszedł, jeśli nie może ustanowić tunelu, a następnie autossh może spróbować ponownie uruchomić ssh.źródło
-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