Bewährte Methoden zur Vermeidung von SSH-Timeout-Problemen

SSH-Timeouts treten normalerweise auf, wenn Ihr Terminal nach einigen Minuten Inaktivität einfriert und dann einen Fehler wegen unterbrochener Pipe oder Verbindungsabbruch anzeigt. Die Ursache ist oft eine Firewall, ein NAT-Gateway, ein VPN oder ein Load Balancer, der inaktive TCP-Sitzungen beendet, bevor Ihr SSH-Client dies bemerkt.

Die nützlichste Lösung sind SSH-Keepalives von Ihrem Client aus. Auch serverseitige Einstellungen können helfen, dienen jedoch einem anderen Zweck und können inaktive Clients trennen, wenn Sie sie zu aggressiv einstellen.

Grundlegendes Verständnis der Ursache von SSH-Timeouts

Ein SSH-Timeout tritt auf, wenn die Kommunikationsverbindung zwischen Client und Server unterbrochen wird, weil keine Seite für eine bestimmte Dauer Aktivität festgestellt hat. Dies liegt normalerweise nicht an der SSH-Software selbst, sondern an zwischengeschalteten Netzwerkgeräten (Firewalls, Router und NAT-Tabellen), die inaktive Verbindungen aggressiv entfernen, um Ressourcen zu schonen.

Wenn eine Firewall für einige Minuten keinen Datenverkehr auf einer bestimmten TCP-Verbindung gesehen hat, nimmt sie an, dass die Sitzung beendet ist, und verwirft den Verbindungsstatus. Wenn der SSH-Client das nächste Mal versucht, Daten zu senden, erreicht der Server diese nie, was zu einem Einfrieren der Sitzung und schließlich zu einem Timeout-Fehler führt.

Die Lösung besteht darin, SSH so zu konfigurieren, dass es regelmäßig Keep-Alive-Signale (kleine, nicht datentragende Pakete) sendet, um sicherzustellen, dass zwischengeschaltete Geräte die Verbindung als aktiv erkennen.

1. Clientseitige Lösungen: Der ServerAliveInterval

Die häufigste und einfachste Lösung zur Vermeidung von Timeouts ist die Konfiguration des SSH-Clients, um regelmäßig eine Keep-Alive-Nachricht an den Server zu senden. Dies wird durch die Direktive ServerAliveInterval gesteuert.

Wie ServerAliveInterval funktioniert

ServerAliveInterval gibt die Zeit in Sekunden an, nach der der Client ein Null-Paket an den Server sendet, wenn keine Daten vom Server empfangen wurden. Dieser Wert stellt sicher, dass die Client-Seite den Verbindungsstatus aufrechterhält.

Konfiguration über ~/.ssh/config

Diese Methode wird empfohlen, da Sie damit die Konfiguration global oder pro Host festlegen können, die über Neustarts und verschiedene Terminalsitzungen hinweg bestehen bleibt.

Erstellen oder ändern Sie Ihre Client-Konfigurationsdatei, die sich normalerweise unter ~/.ssh/config befindet:

nano ~/.ssh/config

Um die Einstellung global (für alle Hosts) anzuwenden:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

Erklärung der Werte:

• ServerAliveInterval 60: Der Client sendet alle 60 Sekunden ein Keep-Alive-Paket, wenn die Verbindung inaktiv ist.
• ServerAliveCountMax 3: Wenn der Client 3 aufeinanderfolgende Keep-Alive-Nachrichten sendet, ohne eine Antwort vom Server zu erhalten, beendet der Client die Verbindung. (Gesamte Timeout-Dauer: 60 Sekunden * 3 Versuche = 180 Sekunden).

Konfiguration über die Befehlszeile

Wenn Sie eine temporäre Lösung benötigen oder die Einstellung nur für eine einzelne Sitzung anwenden möchten, verwenden Sie die Option -o während der Verbindung:

ssh -o "ServerAliveInterval 60" benutzer@remote_host

Tipp: Ein Wert von 30 bis 60 Sekunden ist normalerweise ideal, da er häufig genug ist, um die meisten Firewall-Regeln (die oft auf etwa 5 Minuten eingestellt sind) zu umgehen, aber nicht so häufig, dass übermäßiger Netzwerk-Overhead entsteht.

2. Serverseitige Lösungen: Erzwingen von Keep-Alives

Während die clientseitige Lösung (ServerAliveInterval) normalerweise ausreicht, möchten Administratoren, die Server verwalten, auf die viele Benutzer zugreifen, möglicherweise Keep-Alive-Einstellungen zentral erzwingen oder harte Grenzen für inaktive Verbindungen festlegen. Dies geschieht in der SSH-Daemon-Konfigurationsdatei /etc/ssh/sshd_config.

Verwendung von ClientAliveInterval und ClientAliveCountMax

Diese Direktiven sind die serverseitigen Gegenstücke zu den Client-Einstellungen. Sie weisen den Server an, zu überprüfen, ob der Client noch verbunden ist.

1. Öffnen Sie die Konfigurationsdatei des SSH-Daemons:

   sudo nano /etc/ssh/sshd_config
   

2. Fügen Sie die folgenden Zeilen hinzu oder ändern Sie sie:

   # Server sendet eine Client-Alive-Nachricht nach 300 Sekunden ohne Client-Datenverkehr.
   ClientAliveInterval 300
   
   # Trennen nach 3 unbeantworteten Client-Alive-Nachrichten.
   ClientAliveCountMax 3
   

Hinweis zu ClientAliveCountMax:

ClientAliveInterval-Nachrichten sind SSH-Level-Probes, keine einfache Einstellung "nach dieser Inaktivitätszeit trennen". Mit ClientAliveInterval 300 und ClientAliveCountMax 3 trennt der Server erst nach etwa 15 Minuten unbeantworteter Probes. In OpenSSH deaktiviert ClientAliveCountMax 0 diese Server-Keepalive-Nachrichten, daher ist es kein gutes Beispiel für die Durchsetzung von Timeouts.

1. Starten Sie den SSH-Dienst neu, damit die Änderungen wirksam werden:

   sudo systemctl reload sshd
   # oder
   sudo service ssh reload
   

3. Fortgeschrittene Strategien zur Ausfallsicherheit

Während SSH-Keepalives kurze Inaktivitätsphasen abdecken, führt eine vollständige Netzwerkunterbrechung (z. B. Wechsel des WLAN-Netzwerks oder vorübergehender Signalverlust) immer noch zum Abbruch der TCP-Verbindung. Für echte Ausfallsicherheit verwenden Sie Sitzungsverwaltungstools.

Verwendung von Terminal-Multiplexern (tmux oder screen)

Terminal-Multiplexer sind der ultimative Schutz gegen Verbindungsabbrüche. Sie führen eine Sitzung auf dem entfernten Server aus, die auch dann bestehen bleibt, wenn Ihre Client-Verbindung unterbrochen wird. Sie können die Sitzung trennen, später erneut verbinden (vom selben oder einem anderen Client) und wieder anhängen, um genau dort fortzufahren, wo Sie aufgehört haben.

Grundlegender tmux-Workflow:

1. Stellen Sie eine Verbindung zum Server her:

   ssh benutzer@remote_host
   

2. Starten Sie eine neue tmux-Sitzung auf dem Server:

   tmux new -s meine_sitzung
   

3. Arbeiten Sie innerhalb der tmux-Sitzung.
4. Wenn die Verbindung unterbrochen wird oder Sie gehen müssen, trennen Sie die Sitzung (Strg+B, dann D).
5. Stellen Sie die Verbindung zum Server erneut über SSH her.
6. Hängen Sie sich wieder an Ihre bestehende Sitzung an:

   tmux attach -t meine_sitzung
   

Unterscheidung von SSH-Keep-Alives und TCP-Keep-Alives

Es ist möglich, den zugrunde liegenden TCP-Keep-Alive-Mechanismus des Betriebssystems zu verwenden, der oft über die Direktive TCPKeepAlive yes in sshd_config konfiguriert wird. SSH-Level-Keep-Alives (ServerAliveInterval) werden jedoch im Allgemeinen bevorzugt, weil:

1. Portabilität: SSH-Direktiven funktionieren unabhängig von der zugrunde liegenden OS-Kernel-Tuning konsistent.
2. Anwendungsschicht: SSH-Keep-Alives arbeiten auf der Anwendungsschicht und stellen sicher, dass der SSH-Daemon reaktionsfähig bleibt.
3. Firewall-Bewusstsein: TCP-Keep-Alives können manchmal von Firewalls oder NAT-Geräten stillschweigend blockiert werden, die nur die Nutzlastaktivität überprüfen, während SSH-Keep-Alives speziell dafür entwickelt wurden, diese Schichten erfolgreich zu durchqueren.

Wenn Sie sich für TCPKeepAlive yes entscheiden, denken Sie daran, dass die tatsächliche Intervallzeitsteuerung vom Betriebssystem (z. B. Linux' net.ipv4.tcp_keepalive_time) und nicht von der SSH-Konfiguration gesteuert wird.

Zusammenfassung der bewährten Methoden

Problem	Konfigurationsdirektive	Ort	Empfohlener Wert	Zweck
Client-Timeouts	ServerAliveInterval	~/.ssh/config (Client)	30 - 60 Sekunden	Sendet Null-Pakete vom Client an den Server, um Firewall-Abbruch zu verhindern.
Client-Trennschwelle	ServerAliveCountMax	~/.ssh/config (Client)	3 - 5	Anzahl der verpassten Antworten, bevor der Client die Verbindung trennt.
Server-Inaktivitätsdurchsetzung	ClientAliveInterval	/etc/ssh/sshd_config (Server)	300 Sekunden (5 Min.)	Sendet Überprüfungen vom Server an den Client, um die Aktivität zu überwachen.
Verbindungsausfallsicherheit	N/A	Server-Sitzung	tmux oder screen	Ermöglicht Sitzungspersistenz trotz Netzwerkausfall.

Beginnen Sie mit ServerAliveInterval in Ihrer Client-Konfiguration. Führen Sie für lang laufende Migrationen, Paket-Upgrades oder Protokolluntersuchungen die Arbeit in tmux oder screen aus, damit ein unterbrochener Netzwerkpfad den Job nicht beendet.