ssh/sshfs/sshfs-win nervige Verbindungsabbrüche nach kurzer Zeit

CyborgBeta

Captain
Registriert
Jan. 2021
Beiträge
3.210
Hallo, hat jemand eine Idee, woran das liegen könnte?

Ich verbinde mich von einem Windows 11-Computer mit einem Linux-Rechner via SSH bzw. mounte ein entferntes Filesystem.

Bisher ging das eigentlich ganz gut, aber die URL zu meinen Linux hatte sich mal geändert, und nun kommt es nach ein paar Minuten (ohne viel Aktivität) zu Verbindungsabbrüchen.

Oder bin ich gar nicht daran schuld, sondern evtl. "das Internet" oder IPv4?

Ich habe nur die Vermutung, dass Windows auf irgendeine Art mit dem Hostname-Wechsel nicht klargekommen ist ... oder hat das damit nicht zu tun?

Danke für jede Info

1733428865775.png


1733428794651.png
 
Ich würde ja sagen, dass Du auf der Linux-Maschine dem SSH-Server mal "Keep Alive" eintrichten müsstest.
Klingt nämlich verdächtig danach, dass die Verbindung gekappt wird, weil der verbunde Client ja nicht permanant Datenpakete sendet/abfragt und der Server denkt, dass die Verbindung nicht mehr erforderlich ist.
 
  • Gefällt mir
Reaktionen: BeBur, Gizzmow, dafReak und 3 andere
@Zer0DEV Danke.

Ist jetzt an:

1733430137847.png


ClientAliveCountMax
Sets the number of client alive messages which may be sent
without sshd(8) receiving any messages back from the client.
If this threshold is reached while client alive messages are
being sent, sshd will disconnect the client, terminating the
session. It is important to note that the use of client alive
messages is very different from TCPKeepAlive. The client alive
messages are sent through the encrypted channel and therefore
will not be spoofable. The TCP keepalive option enabled by
TCPKeepAlive is spoofable. The client alive mechanism is valu-
able when the client or server depend on knowing when a connec-
tion has become unresponsive.

Siehe auch diese Antwort https://stackoverflow.com/a/37330274

Ich werde jetzt mal beide Seiten neu starten und dann beobachten, ob es weiterhin noch diese Verbindungsabbrüche gibt ... Melde mich gleich noch mal
Ergänzung ()

Danke, das war es. War gerade eine rauchen und es gab keine Verbindungsabbrüche seit 21:32 Uhr. :)
 
Zuletzt bearbeitet:
Ich frag mich auch grad, wieso der Default so ist. ssh keepalive ist ja auf Applikationsebene. Vllt. verbraucht das mehr ressourcen als ein tcp keepalive?
TCP keepalive ist ja jedenfalls auf Verbindungsebene. Du ziehst kurz dein Netzwerkkabel raus oder du fährst durch ein Funkloch -> TCP Verbindung bricht ab.
ssh ist auf Applikationsebene. Du schreibst nichts mehr -> bei sshd kommt nichts(?) an. Der Server erhält aber noch pakete über die TCP Verbindung (eben z.B. solche keepalive Pakete).
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: CyborgBeta
Funkloch = Abbruch wäre nicht so schlimm, mich hat eher der Abbruch "bei Inaktivität" gestört, also wenn keine (oder nur wenige) TCP-Pakete gesendet werden. Aber ja, vermutlich geht es da um weniger Ressourcen = besser.
 
Ich mache auf beiden Seiten die ich kontrolliere (Server/Client) TCPKeepAlive immer aus und aktiviere ClientAlive und ServerAlive.
Zum Unterschied sagt die manpage:
Code:
        It is important to note that the use of client alive
        messages is very different from TCPKeepAlive. The client alive
        messages are sent through the encrypted channel and therefore
        will not be spoofable. The TCP keepalive option enabled by
        TCPKeepAlive is spoofable. The client alive mechanism is valu-
        able when the client or server depend on knowing when a connec-
        tion has become unresponsive.

Der Keep-Alive mechanismus von TCP sendet quasi leere Pakete an die Gegenstelle um zu verhindern dass eine ruhende Verbindung von irgendeinem Router/Firewall auf dem Weg wegen Inaktivität gedroppt wird. Die Pakete kann aber jeder schicken, auch ein Angreifer dem es vielleicht irgendwie nützt Verbindungen noch beliebig lange offen zu halten. Die Nachrichten von ServerAlive/ClientAlive gehen durch den SSH Kanal und müssen wie tatsächliche Kommunikation ordentlich verschlüsselt und signiert sein. Das können nur der echte Client und Server leisten. Ist also einer der beiden irgendwann nicht mehr an der Verbindung beteiligt weiß das die Gegenstelle auch nach maximal AliveCountMax*AliveInterval Sekunden, egal was ein Angreifer macht.

Praktische Relevanz von dem Unterschied... eher gering. Aber fahre ohne TCPKeepAlive und mit ClientAlive+ServerAlive (Interval 30, CountMax 3) sehr gut, SSH Verbindungen brechen nie unerwartet ab, also warum nicht 🤷‍♂️
 
  • Gefällt mir
Reaktionen: CyborgBeta
Hieße das, Server- und ClientAlive wären unidirektional und TCPAlive würde bidirektional funktionieren? Sprich, TCPAlive wären einfach leere Pakete, die jeder senden kann; und Server- und ClientAlive wären zwar auch leere, aber ordentlich verpackte Pakete, die nicht jeder senden kann, und die auch nicht gespooft werden könnten?

Dann wäre TCPAlive tatsächlich nicht sinnvoll, wenn man keine "Zombie"-Verbindungen haben möchte.

Marco01_809 schrieb:
und mit ClientAlive+ServerAlive (Interval 30, CountMax 3) sehr gut
Jetzt könnte man sich wieder streiten. 3x30 wären 1,5 Minuten ... also wenn so lange die Verbindung unterbrochen wäre, würde der Server "Tschö" sagen. Aber vielleicht würden auch schon 2x60, also 2 Minuten, genügen. Ich glaube irgendwie nicht, dass die Werte in der Antwort auf Stack Overflow nicht gut durchdacht gewesen wären. Bei mir genügt es jedenfalls, wenn nur jede Minute einmal ein "Ack" gesendet wird, damit die Verbindung nicht unterbrochen wird.
 
Zurück
Oben