ssh Computer wach halten

[Artim]

Ich suche nach einer Möglichkeit, unseren Rechner (testing Zweig) wach zu halten, wenn eine aktive ssh Verbindung vorliegt. Oder zumindest eine Wartezeit von 10 Minuten ohne Eingabe zu erzwingen. Ich habe schon an der Konfiguration von gdm3 geschraubt und bin auch der Meinung an ein paar anderen Stellen dies so eingerichtet zu haben, aber ich weiß aus dem Stand nicht mehr, wo ich alles was gemacht habe, bin halt Anleitungen gefolgt, die ich bei Google gefunden habe.
Jedenfalls hat unser Rechner die Lästige Angewohnheit, innerhalb weniger Minuten die Verbindung zu trennen, selbst wenn ich gerade dabei bin, einen Pfad einzutippen und Sekunden vorher noch fröhlich mit der Autovervollständigung gearbeitet habe (was meiner Meinung nach ausreichend Nutzerinteraktion sein sollte). Leider tritt das Problem auch sehr Zufällig auf, was es nicht einfach macht, Logs zu finden.

[mistersixt]

Du loggst Dich also von Remote per SSH auf diesen Rechner ein, und dann bricht die Verbindung plötzlich ab? Geht die Verbindung zu und Du bist im Terminal auf dem Remote-System, oder "hängt" die Session einfach?

Gruss, mistersixt.

[pferdefreund]

Da würde ich erst mal auf beiden Rechnern per journalctl nachschauen ob da was auffällig ist. Ist da eventuell irgend ein Powersaver oder Bildschirmschoner aktiv ? Gibt es da was im Bios ? Wie sieht es aus, wenn man sich mit dem Rechner per ssh ohne !!! X verbindet und nur eine Konsole hat. Bricht es dann auch ab ?

[uname]

Nutzt du eine WLAN-Verbindung und nur diese bricht zusammen? Dann könntest du einfach das WLAN manuell konfigurieren.
Wenn du dir nicht sicher bist teste man mit einem LAN-Kabel. Bricht die Verbindung dann auch zusammen?

Da wo was von /etc/network/interfaces steht. Den PSK (WLAN-Passwort) kannst du auch testweise in Klartext eingeben.
https://wiki.debian.org/WiFi/HowToUse

[Artim]

Du loggst Dich also von Remote per SSH auf diesen Rechner ein, und dann bricht die Verbindung plötzlich ab? Geht die Verbindung zu und Du bist im Terminal auf dem Remote-System, oder "hängt" die Session einfach?

Gruss, mistersixt.

Unterschiedlich. Teilweise hängt die Sitzung einfach random, teils sogar mitten in der Eingabe und ein paar Sekunden später bekomme ich ein "Connection reset by xxx.xxx.xxx.xxx port 22", eben z.B. hat es gerade für das Öffnen der Sitzung und ein cat /etc/fstab gereicht, wenige Sekunden später kam dann direkt wieder die gleiche Meldung.

Da würde ich erst mal auf beiden Rechnern per journalctl nachschauen ob da was auffällig ist. Ist da eventuell irgend ein Powersaver oder Bildschirmschoner aktiv ? Gibt es da was im Bios ? Wie sieht es aus, wenn man sich mit dem Rechner per ssh ohne !!! X verbindet und nur eine Konsole hat. Bricht es dann auch ab ?

Der entfernte PC soll sicher nach einer Weile der inaktivität in den Ruhezustand gehen. Aber eben nicht während eine aktive SSH Verbindung steht, die auch aktiv genutzt wird. Dort im journalctl fällt mir nichts auf, lokal existiert leider keins. Ich nutze lokal ein in WSL installiertes Debian. Und die Verbindungen sind grundsätzlich ohne X Fowarding (u.a. weil ich auch noch nicht herausbekommen habe, wie ich das in aktuellem Debian gebastelt bekomme, da ich nur eine Meldung bekomme vonwegen kann Display nicht öffnen, die diversen export $DISPLAY ansätze helfen auch nicht, aber das ist ein anderes Problem.). Im BIOS muss ich mal nachschauen, aber mir ist da nicht bekannt. Wenn es hilft, der PC ist ein Lenovo m625q.

Nutzt du eine WLAN-Verbindung und nur diese bricht zusammen? Dann könntest du einfach das WLAN manuell konfigurieren.
Wenn du dir nicht sicher bist teste man mit einem LAN-Kabel. Bricht die Verbindung dann auch zusammen?

Da wo was von /etc/network/interfaces steht. Den PSK (WLAN-Passwort) kannst du auch testweise in Klartext eingeben.
https://wiki.debian.org/WiFi/HowToUse

Daran kann es kaum liegen. Der entfernte PC hängt am LAN, am Laptop ist es egal in welchem Netz ich bin. Und wenn die WLAN Verbindung so schlecht wäre, müsste ich noch ganz andere Probleme haben.

[mat6937]

Jedenfalls hat unser Rechner die Lästige Angewohnheit, innerhalb weniger Minuten die Verbindung zu trennen, selbst wenn ich gerade dabei bin, einen Pfad einzutippen und Sekunden vorher noch fröhlich mit der Autovervollständigung gearbeitet habe (was meiner Meinung nach ausreichend Nutzerinteraktion sein sollte). Leider tritt das Problem auch sehr Zufällig auf, was es nicht einfach macht, Logs zu finden.

Welches OS hast Du auf dem entfernten PC (mit dem sshd-Server)? Kann es evtl. sein, dass der sshd-Server die Verbindung trennt?

[Artim]

Jedenfalls hat unser Rechner die Lästige Angewohnheit, innerhalb weniger Minuten die Verbindung zu trennen, selbst wenn ich gerade dabei bin, einen Pfad einzutippen und Sekunden vorher noch fröhlich mit der Autovervollständigung gearbeitet habe (was meiner Meinung nach ausreichend Nutzerinteraktion sein sollte). Leider tritt das Problem auch sehr Zufällig auf, was es nicht einfach macht, Logs zu finden.

Welches OS hast Du auf dem entfernten PC (mit dem sshd-Server)? Kann es evtl. sein, dass der sshd-Server die Verbindung trennt?

Den Debian testing Zweig. Also das was Bullseye werden wird. Das meinte ich im OP. Und sicher kann das sein, die Frage ist nur, wie treibe ich es ihm aus? Ich habe mir die man Page von sshd_config schon angesehen, eigentlich sollte die Standardkonfiguration das nicht tun. Und ich habe da nur Kleinigkeiten geändert wie XForward aktiviert

[mat6937]

Und sicher kann das sein, ...

Dann solltest Du dich anhand der PID des sshd auf dem entfernten PC, vergewissern, bevor Du Änderungen/Optimierungen an der sshd_config machst.

[uname]

Du könntest mal versuchen den Fehler näher zu lokalisieren. Also ein SSH-Server braucht keine Grafik. Beende das ganze gdm3-Zeug falls es läuft. Wenn dann dein Netzwerk nicht mehr läuft (bei WLAN auf dem Server) konfiguriere es manuell.
Auch dein Client braucht keine Grafik. Beende das ganze gdm3-Zeug fall es läuft. Auch hier das Netzwerk evtl. manuell konfigurieren.

Nun rein textuell

Code: Alles auswählen

ssh user@server

Und was passiert?

Vielleicht liegt es am Client. Versuche ein Live-ISO oder Windows und Putty.
Vielleicht liegt es am Server. Kehre die Verbindung um.

[MSfree]

Unterschiedlich. Teilweise hängt die Sitzung einfach random, teils sogar mitten in der Eingabe und ein paar Sekunden später bekomme ich ein "Connection reset by xxx.xxx.xxx.xxx port 22",

Kannst du dich denn dann sofort wieder mit SSH verbinden?

[uname]

Du kannst auch mal strace installieren und das ganze SSH-Zeug serverseitig loggen.

Code: Alles auswählen

strace -ff -o out.txt -p $(cat /var/run/sshd.pid)

[Artim]

Unterschiedlich. Teilweise hängt die Sitzung einfach random, teils sogar mitten in der Eingabe und ein paar Sekunden später bekomme ich ein "Connection reset by xxx.xxx.xxx.xxx port 22",

Kannst du dich denn dann sofort wieder mit SSH verbinden?

teilweise ja, teilweise nein und ich muss erst kurz warten bis es wieder geht (quasi wie wenn der PC schlafen gegangen ist und er erst wieder aufwachen muss).

Und sicher kann das sein, ...

Dann solltest Du dich anhand der PID des sshd auf dem entfernten PC, vergewissern, bevor Du Änderungen/Optimierungen an der sshd_config machst.

kann ich mal drauf achten, wenn es das nächste mal passiert. pgrep zeigt mir für sshd allerdings zwei PIDs an

Du könntest mal versuchen den Fehler näher zu lokalisieren. Also ein SSH-Server braucht keine Grafik. Beende das ganze gdm3-Zeug falls es läuft. Wenn dann dein Netzwerk nicht mehr läuft (bei WLAN auf dem Server) konfiguriere es manuell.
Auch dein Client braucht keine Grafik. Beende das ganze gdm3-Zeug fall es läuft. Auch hier das Netzwerk evtl. manuell konfigurieren.

Was soll bitteschön das Vorhandensein von graphischen Elementen damit zu tun zu haben?
Außerdem:
1. handelt es sich um einen PC, nicht um einen Server, Grafik ist also sehr wohl relevant und ssh muss auch mit laufen können.
2. Weder Windows noch Debian in WSL verfügen über GDM oder andere (Linux) Desktop Environments.

Nun rein textuell

Code: Alles auswählen

ssh user@server

Und was passiert?

Was passieren soll (ich werde erst nach einem Passwort für den Schlüssel gefragt, da diese Authentifizierung auf einigen unserer Server gleicher Domain notwendig ist und ich mir noch nicht die Mühe gemacht habe herauszufinden wie ich die Abfrage für einzelne Hosts abstelle, was ich mit Enter abbreche, gebe mein Passwort ein und dann wird die Verbindung nach zufälligen Zeitabständen gekillt)

Vielleicht liegt es am Client. Versuche ein Live-ISO oder Windows und Putty.
Vielleicht liegt es am Server. Kehre die Verbindung um.

Wie gesagt, ich nutze unter Windows WSL, Putty ist mir zu limitiert. Ein Live-ISO ist gar nicht erst im Spiel, ein Umkehren der Verbindung ist ebenfalls nicht möglich, da Debian unter WSL kein systemd nutzt, ohne scheint es gar nicht möglich zu sein, einen SSH Server zu starten.

[MSfree]

(quasi wie wenn der PC schlafen gegangen ist und er erst wieder aufwachen muss).

Ich denke nicht, daß sich der Rechner zwischendurch schlafen legt. Ich bin mir auch fast sicher, daß ein Rechner, der sich schlafen legt, irgendwelche Einträge im Journal (siehe journalctl) diesbezüglich machen würde, nach denen du suchen könntest. Da ich meine Rechner grundsätzlich ohne Hibernation bzw Suspend-to-X fahre, kann ich dir nicht sagen, welcher Text im Journel zu finden sein müßte, ich würde aber nach hiber und susp suchen.

Ich denke, du bist mit deiner Vermutung, daß der Rechner sich schlafen legt, gewaltig auf dem Holzweg und es handelt sich schlicht um ein Netzwerkproblem.

Ich kenne solche Abbrüche auch, und die hängen in der Regel mit der MTU zusammen, DSL 1492 vs. LAN 1500. Ist dann im Router (warum auch immer) das Do-not-Fragment-Flag gesetzt, können Netzwerkpakete zu groß werden und die Übertragung hängt sich dann schlicht auf.

[Artim]

(quasi wie wenn der PC schlafen gegangen ist und er erst wieder aufwachen muss).

Ich denke nicht, daß sich der Rechner zwischendurch schlafen legt. Ich bin mir auch fast sicher, daß ein Rechner, der sich schlafen legt, irgendwelche Einträge im Journal (siehe journalctl) diesbezüglich machen würde, nach denen du suchen könntest. Da ich meine Rechner grundsätzlich ohne Hibernation bzw Suspend-to-X fahre, kann ich dir nicht sagen, welcher Text im Journel zu finden sein müßte, ich würde aber nach hiber und susp suchen.

Ich denke, du bist mit deiner Vermutung, daß der Rechner sich schlafen legt, gewaltig auf dem Holzweg und es handelt sich schlicht um ein Netzwerkproblem.

Ich kenne solche Abbrüche auch, und die hängen in der Regel mit der MTU zusammen, DSL 1492 vs. LAN 1500. Ist dann im Router (warum auch immer) das Do-not-Fragment-Flag gesetzt, können Netzwerkpakete zu groß werden und die Übertragung hängt sich dann schlicht auf.

Das kann aber nicht sein. Die Verbindung zu unseren Servern, die im gleichen Netz hängen (auf denen Debian 10.2 läuft), läuft zuverlässig. Dort sind mir bisher noch nie solche Abbrüche aufgefallen. Dann kann es höchstens am Netzwerktreiber liegen, aber der läuft eigentlich auch ansonsten zuverlässig.

[MSfree]

Das kann aber nicht sein. Die Verbindung zu unseren Servern, die im gleichen Netz hängen ...

Also, wenn das alles im gleichen Netz läuft, hätte ich schon längst die Füße in die Hand genommen und wäre mal zu der Problemkiste gelaufen und hätte dort alles was nach Journal aussieht gründlich inspiziert.

Netzwerkabbrüche werden da genauso protokolliert wie Subspend-to-X

[mat6937]

pgrep zeigt mir für sshd allerdings zwei PIDs an

OK, dann achte auf die PID des sshd, die die PPID 1 hat.

Z. B.:

Code: Alles auswählen

:~# ps -o ppid= $(pidof sshd)
 4169
 3691
    1

Code: Alles auswählen

:~# ps -o ppid= 4169
    1

[Artim]

pgrep zeigt mir für sshd allerdings zwei PIDs an

OK, dann achte auf die PID des sshd, die die PPID 1 hat.

Z. B.:

Code: Alles auswählen

:~# ps -o ppid= $(pidof sshd)
 4169
 3691
    1

Code: Alles auswählen

:~# ps -o ppid= 4169
    1

Mir ist es jetzt mit einem unserer Server passiert. Mit dem Vorgehen von dir konnte ich zwar nichts in journalctl finden, aber mit der PID eines der Child processes (besser gesagt mit zwei, aber beide zeigen ein identisches log) konnte ich nur folgendes finden:

Code: Alles auswählen

Jan 12 19:21:13 mail sshd[24152]: rexec line 15: Deprecated option UsePrivilegeSeparation
Jan 12 19:21:13 mail sshd[24152]: rexec line 18: Deprecated option KeyRegenerationInterval
Jan 12 19:21:13 mail sshd[24152]: rexec line 19: Deprecated option ServerKeyBits
Jan 12 19:21:13 mail sshd[24152]: rexec line 30: Deprecated option RSAAuthentication
Jan 12 19:21:13 mail sshd[24152]: rexec line 37: Deprecated option RhostsRSAAuthentication
Jan 12 19:21:13 mail sshd[24152]: reprocess config line 30: Deprecated option RSAAuthentication
Jan 12 19:21:13 mail sshd[24152]: reprocess config line 37: Deprecated option RhostsRSAAuthentication                                                                   Jan 12 19:21:17 mail sshd[24152]: Accepted publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2: RSA SHA256:xyz
Jan 12 19:21:17 mail sshd[24152]: pam_unix(sshd:session): session opened for user root by (uid=0)

Es sieht so aus als wäre das Abbrechen der Verbindung nicht von Seiten des Servers eingeleitet worden.
Mal angenommen, der Fehler liegt doch auf meiner Seite, wie kann ich diesen identifizieren? Debian in WSL verfügt ja scheinbar über kein systemd, womit auch journalctl ausscheidet. Kennt sich jemand mit dieser Kombination weit genug aus um sagen zu können, was der genaue Auslöser war?

[mat6937]

Mit dem Vorgehen von dir konnte ich zwar nichts in journalctl finden, ...

Das verstehe ich nicht. Wo habe ich geschrieben, dass Du was in journalctl finden kannst?

[Artim]

Mit dem Vorgehen von dir konnte ich zwar nichts in journalctl finden, ...

Das verstehe ich nicht. Wo habe ich geschrieben, dass Du was in journalctl finden kannst?

Du meintest ich solle mich mit der PID vergewissern. Und wenn da was wäre sollte ja wohl in journalctl was zu finden sein.

Bzw. es sieht alles danach aus, als würde tatsächlich ein Netzwerkproblem vorliegen. Zwar sollen nur WLANs betroffen sein und ich war von Außerhalb per VPN verbunden, aber ich schätze mal bei uns zickt die Leitung in letzter immer wieder mal. Ließen sich die Parameter für die Verbindung so einstellen, dass kleinere Aussetzer besser verkraftet werden, wie z.B. einfach Verlängerung des Timeouts? Das könnte in dem Fall vielleicht ein wenig abhilfe schaffen

[mat6937]

Du meintest ich solle mich mit der PID vergewissern.

Naja, eine Änderung der PID zeigt eindeutig, dass der sshd-Server neu gestartet worden ist. Hast Du das mit Hilfe der PID feststellen können?

... ich war von Außerhalb per VPN verbunden, ...

Welche Software benutzt Du für die VPN-Verbindung? Evtl. kannst Du im Log nachschauen ob die VPN-Verbindung unterbrochen worden ist bzw. neu hergestellt worden ist.

[Artim]

Du meintest ich solle mich mit der PID vergewissern.

Naja, eine Änderung der PID zeigt eindeutig, dass der sshd-Server neu gestartet worden ist. Hast Du das mit Hilfe der PID feststellen können?

... ich war von Außerhalb per VPN verbunden, ...

Welche Software benutzt Du für die VPN-Verbindung? Evtl. kannst Du im Log nachschauen ob die VPN-Verbindung unterbrochen worden ist bzw. neu hergestellt worden ist.

Die Software ist Cisco AnyConnect. Eine Andere ist mir auch nicht bekannt, die bei uns geht. Windows selbst kann es auf jeden fall nicht.
Die PID werde ich mal im Auge behalten

[MSfree]

Naja, eine Änderung der PID zeigt eindeutig, dass der sshd-Server neu gestartet worden ist.

Jein. Auf der Serverseite läuft immer ein sshd als Masterprozeß. Sobald man versucht, sich per SSH anzumelden, wird von diesem Master-sshd ein neuer sshd-Prozeß gestartet, Man bekommt also zwangsläufig mit jeder SSH-Verbindung eine neue PID.

aber ich schätze mal bei uns zickt die Leitung in letzter immer wieder mal. Ließen sich die Parameter für die Verbindung so einstellen, dass kleinere Aussetzer besser verkraftet werden

Du tappst ja wirklich immer noch ziemlich im Dunkeln. Was heißt denn bitte, die Leitung zickt? Wie äussert sich das? Schon mal in den Logs des DSL-Routers geschaut, ob da öfter ein Reconnect stattfindet? Sollte das der Fall sein, bekommt der Router auch jedes Mal eine neue IP-Adresse und dann ist es Essig mit verlängerten Timeouts.

[mat6937]

Jein. Auf der Serverseite läuft immer ein sshd als Masterprozeß.

Dann hast Du nicht gelesen was ich weiter oben geschrieben habe. Ich habe geschrieben, dass es um die PID geht (die beobachtet werden soll), die als PPID die 1 hat.

Z. B.:

Code: Alles auswählen

:~ $ ps -o ppid= $(pidof sshd)
    1
  390
 4126

Code: Alles auswählen

:~ $ ps -o ppid= 390
    1

D. h. hier (im Beispiel) die PID 390, die sich nur dann ändert wenn auch der sshd-Server neu gestartet wird.

[novalix]

autossh ist ein Wrapper, der bei störungsanfälligen Verbindungen automatisch reconnected.
Natürlich sollte man grundsätzlich die Ursache der Störung - solange sie im eigenen Kontrollbereich liegt - beheben.

[polerna]

Letztens habe ich einen Tutorial auf YouTube dazu gesehen, werde es weiterleiten.