Welche Optionen "ServerAliveInterval" und "ClientAliveInterval" in sshd_config genau tun?


161

Ich habe diese Frage gefunden , aber es tut mir leid, dass ich die Einstellungen für die beiden Variablen nicht ganz verstehe ServerAliveIntervalund ClientAliveIntervalin der akzeptierten Antwort erwähnt habe. Sollte ich diesen Wert auf Null setzen, wenn mein lokaler Server eine Zeitüberschreitung aufweist? Wird es dann nie eine Auszeit geben? Soll ich es stattdessen auf 300 Sekunden einstellen oder so?

Meine Frage ist einfach, einige meiner Verbindungen laufen ab, wenn ich meinen Laptop mit der Antwort aussetze Write failed: Broken pipeund einige nicht. Wie kann ich ein lokales SSHD richtig konfigurieren, damit es nicht mit einer kaputten Pipe ausfällt?

Antworten:


202

ServerAliveInterval : Anzahl der Sekunden, die der Client wartet, bevor ein Nullpaket an den Server gesendet wird (um die Verbindung aufrechtzuerhalten).

ClientAliveInterval : Anzahl der Sekunden, die der Server wartet, bevor ein Nullpaket an den Client gesendet wird (um die Verbindung aufrechtzuerhalten).

Wenn Sie den Wert 0 (Standardeinstellung) festlegen, werden diese Funktionen deaktiviert, sodass Ihre Verbindung unterbrochen werden kann, wenn sie zu lange inaktiv ist.

ServerAliveInterval scheint die gängigste Strategie zu sein, um eine Verbindung am Leben zu erhalten. Um das Problem der unterbrochenen Leitung zu vermeiden, verwende ich in meiner .ssh / config-Datei die folgende ssh-Konfiguration:

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

Die obige Einstellung funktioniert folgendermaßen:

  1. Der Client wartet 60 Sekunden im Leerlauf (ServerAliveInterval-Zeit) und sendet ein "No-Op-Null-Paket" an den Server und erwartet eine Antwort. Wenn keine Antwort eingeht, wird der obige Vorgang bis zu 10 (ServerAliveCountMax) Mal (600 Sekunden) wiederholt. Wenn der Server immer noch nicht antwortet, trennt der Client die SSH-Verbindung.

ClientAliveCountMax auf der Serverseite kann ebenfalls hilfreich sein. Dies ist die Grenze dafür, wie lange ein Client nicht mehr reagiert, bevor die Verbindung getrennt wird. Der Standardwert ist 3, wie in drei ClientAliveInterval.


Ok, also würde ich null Sekunden interpretieren, um zu implizieren, dass "nicht am Leben bleiben", weshalb der Client / Server nicht abgefragt wird?
M. Tibbits

3
yup 0 = Sende kein Null-Paket. Ein weiterer Unterschied besteht darin, dass ServerAliveInterval in der Client-Konfiguration festgelegt wird, während ClientAliveInternal in der Server-Konfiguration festgelegt wird.
Barthelemy

8
Dies scheint ein guter Rat zu sein, um Zeitüberschreitungen durch Nichtstun zu vermeiden, aber ich verstehe nicht, in welchem ​​Zusammenhang dies mit der OP-Frage der Verhinderung von Rohrbrüchen beim Anhalten des Clients steht. Wenn der Client schläft, kann er kein Null-Paket senden. Ist diese Einstellung also fehlerhaft?
Sparhawk

Der ServerAlive-Teil ist sicherlich. Hier hilft ClientAliveInterval / ClientAliveCountMax.
Javawizard

1
Wenn ich auf diese alte Antwort zurückblicke, habe ich vermutlich auf die Frage im Titel und nicht auf die Frage im zweiten Absatz geantwortet, daher sind die Kommentare zu ServerAliveInternal nicht hilfreich für die Unterbrechung, mit denen ich einverstanden bin. @JonasWielicki ClientAliveInterval kann in einem Suspend-Fall fehlerhaft sein, da der suspendierte Client dem Server nicht antwortet und der Server den Client schließlich nach ClientAliveCountMax trennt.
Barthelemy

18

Dies wird in sshd_configmanual ( man sshd_config) erklärt:

ClientAliveInterval

Legt ein Zeitlimit in Sekunden fest, nach dessen Ablauf sshd eine Nachricht über den verschlüsselten Kanal sendet, um eine Antwort vom Client anzufordern, wenn keine Daten vom Client empfangen wurden. Der Standardwert ist 0, was angibt, dass diese Nachrichten nicht an den Client gesendet werden. Diese Option gilt nur für Protokollversion 2.

ClientAliveCountMax

Der Standardwert ist 3. Wenn ClientAliveInterval(siehe unten) auf 15 gesetzt ist und ClientAliveCountMaxder Standardwert beibehalten wird, werden nicht reagierende SSH-Clients nach ca. 45 Sekunden getrennt. Diese Option gilt nur für Protokollversion 2.

Informationen zu den Client-Optionen finden Sie in der Erläuterung unter man ssh_config:

ServerAliveInterval

Legt ein Zeitlimit in Sekunden fest, nach dessen sshAblauf eine Nachricht über den verschlüsselten Kanal gesendet wird, um eine Antwort vom Server anzufordern, wenn keine Daten vom Server empfangen wurden . Der Standardwert ist 0, was angibt, dass diese Nachrichten nicht an den Server gesendet werden. Diese Option gilt nur für Protokollversion 2.

ServerAliveCountMax

Der Standardwert ist 3. Wenn beispielsweise ServerAliveInterval15 festgelegt ist und ServerAliveCountMaxdie Standardeinstellung beibehalten wird, sshwird die Verbindung nach ca. 45 Sekunden getrennt , wenn der Server nicht mehr reagiert . Diese Option gilt nur für Protokollversion 2.

Basierend auf dem obigen Wert bedeutet 0, dass es deaktiviert ist. Daher sollten Sie diese Werte hoch genug einstellen, um einen Rohrbruchfehler zu vermeiden .


Hilfreicher Beitrag. Aber ich bin so frustriert. Ich stelle überall große Intervalle ein und meine Verbindung wird nach nur wenigen Minuten immer noch unterbrochen. (unter Ubuntu OpenSSH verwenden, nicht sicher, ob das relevant ist)
Sridhar Sarnobat

1
@ user7000 Konfigurieren Sie sowohl den Client (ssh) als auch den Server (sshd). Dies kann helfen: So beheben Sie Probleme mit "Die SSH-Verbindung wurde vom Remote-Ende unerwartet geschlossen" .
Kenorb

Ich glaube, ich komme irgendwohin. Es könnte sein, dass ich vorher kein Leerzeichen ServerAliveIntervalin meine Konfigurationsdatei eingefügt habe.
Sridhar Sarnobat

16

Die Antwort von Barthelemy ist cool, aber sie geht dem Problem nicht wirklich auf den Grund. Sie unterbrechen Ihren Computer und möchten, dass die SSH-Sitzung noch aktiv ist, wenn Sie Ihren Computer starten.

Es gibt keine solche Konfiguration für ssh, die die Verbindung so am Leben erhält. SSH verwendet TCP. Zunächst benötigen Sie den Drei-Wege-Handshake, um nach einer gewissen Leerlaufzeit am Leben zu bleiben. Beim Herunterfahren / Ruhezustand werden alle Ihre TCP-Verbindungen mit FIN geschlossen. Keine Möglichkeit, das zu überwinden.

Für eine fehlerhafte Problemumgehung können Sie VPS oder eine andere Online-Box mit Bildschirm verwenden, um die Verbindung aufrechtzuerhalten. Mein Rat tut das aus Sicherheitsgründen nicht.


1
Dies ist in der Tat die einzige Antwort auf die Frage.
Calimo

1
Dies ist in der Tat eine schreckliche Sicherheitslösung, tun Sie das niemals.
jahrichie

14

Da Sie nicht garantieren können, dass eine SSH-Verbindung (TCP) am Leben bleibt, wenn kein Ende mehr ACKs an empfangene Pakete sendet, benutze ich persönlich http://www.harding.motd.ca/autossh/ , um alle meine SSH-Verbindungen neu zu starten fast sobald ich nicht mehr suspendiere.

Da der GNU-Bildschirm auf der Serverseite verwendet wird, kann ich durch erneutes Anhängen dorthin gelangen, wo ich vorher war.

Sie können es zusätzliche Ports abhören lassen, so dass es ständig prüft, ob die Verbindungen noch bestehen, aber ich persönlich finde, dass es mit diesen deaktivierten Ports gut genug funktioniert und sich nur auf SSHs eigenes ServerAliveInterval/ verlässt ServerAliveCountMax.

Eine weitere Option ist http://mosh.mit.edu/, die UDP verwendet und sich nahtlos von einem langfristigen Mangel an Konnektivität erholt.


5

Sie können Befehle auch mit ausführen, nohupwenn Sie möchten, dass sie unabhängig von Ihrer SSH-Verbindung ausgeführt werden.

z.B

$ nohup tar -xzf some_huge.tar.gz &

Das &ist, denke ich, nicht notwendig, aber es ist praktisch, da es den Prozess im Hintergrund laufen lässt, so dass Sie andere Dinge tun können.

Ich benutze immer nohup für jeden Prozess, der eine Weile dauert, damit ich nicht von vorne anfangen muss, wenn ich die Verbindung aus irgendeinem Grund verliere - Stromausfall (an meinem entfernten Standort, nicht offensichtlich am Host), Netzwerkausfall, was auch immer.


Beachten Sie, dass nohup auf zsh nicht richtig funktioniert!
Sridhar Sarnobat

@ user7000 was ist daran falsch?
Buttle Butkus

Ich erinnere mich nicht, ich glaube, es hat den Prozess nach dem Trennen der Verbindung zum Client nicht mehr am Laufen gehalten. Es war vor ein paar Jahren und ich habe aufgehört, Nohup zu verwenden und habe stattdessen Disown verwendet.
Sridhar Sarnobat

2
Ich denke, zshBenutzer sollten disown -hstattdessen bleiben nohup, es sei denn, das Problem wurde seitdem behoben.
Buttle Butkus

0

Platzieren Sie Ihre lange laufende Sitzung auf dem Bildschirm. Siehe Bildschirm -h für Details

Auf diese Weise können Sie mit ssh die Verbindung zum Computer wiederherstellen und erneut eine Verbindung zur Bildschirmsitzung herstellen


Ich frage mich, wie viel Prozent der Leute, die einen Bildschirm vorschlagen, ihn tatsächlich selbst verwenden.
Sridhar Sarnobat

Ich denke , tmux besseren Vorschlag ist, prüfen Sie den Code Änderungsdatum github.com/tmux/tmux vs git.savannah.gnu.org/cgit/screen.git/log
Suhaib
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.