ssh Computer wach halten

[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.

[pferdefreund]

Oder einfach auf dem Server ein screen laufen lassen. Nach Abbruch neu verbinden screen -dr und gut ist. Was anderes ist bei Wackelnetzen nicht wirklich sinnvoll.
Oder, was ich auch schon mal gebastelt hatte - dem Server die Befehle per e-mail schicken und dort auswerten, ausführen, Ergebnismail schreiben und zurücksenden. Ist natürlich etwas aufwendiger aber hat bei mir sogar für das Steueren einer Linux-Kiste aus dem IBM Großrechner Z/OS funktioniert.