[gelöst] Trotz KeepAlive yes SSH-Verbindungsabbrüche

[floogy]

Ich möchte von saarge nach etch upgraden (vserver, virtuozzo, ssh). Ich habe bedenken, da sowohl mit putty, als auch mit ssh auf der Linuxconsole die Verbindung des öfteren abgebrochen wird, und das trotz KeepAlive yes .

Code: Alles auswählen

~$ egrep KeepAlive /etc/ssh/sshd_config
KeepAlive yes

Code: Alles auswählen

:~$ ssh -V
OpenSSH_4.2p1 Debian-5, OpenSSL 0.9.8a 11 Oct 2005
~$ apt-cache policy ssh
ssh:
  Installiert:1:4.2p1-5
  Mögliche Pakete:1:4.2p1-5
  Versions-Tabelle:
 *** 1:4.2p1-5 0
        100 /var/lib/dpkg/status
     1:3.8.1p1-8.sarge.6 0
        500 ftp://ftp.freenet.de sarge/main Packages
        500 http://security.debian.org sarge/updates/main Packages

Das Dilemma resultiert aus der Konfiguration des Providers
Wie würde es um ein Downgrade stehen, oder ist in etch die Version höher?
Ich mache mir Sorgen wegen fehlender Sicherheitsupdates.
Allerdings findet rkhunter ssh ok:

Code: Alles auswählen

* Application version scan
   - GnuPG 1.4.1                                              [ Old or patched version ]
   - Bind DNS 9.2.4                                           [ OK ]
   - OpenSSL 0.9.7e                                           [ Old or patched version ]
   - PHP 4.3.10                                               [ Old or patched version ]
   - Procmail MTA 3.22                                        [ OK ]
   - ProFTPd 1.2.10                                           [ OK ]
   - OpenSSH 4.2p1                                            [ OK ]

Wie kann ich die Timeouts und Verbindungsabbrüche während des upgrades verhindern?

[Eliteforce]

gibts die Option KeepAlive überhaupt?
ich sehe nur TCPKeepAlive in der sshd_config man page

wenn du hinter einem router bist, kann es auch sein dass die verbindung nach einer bestimmten zeit ohne aktivitäten abbricht -> ClientAliveInterval / ClientAliveCountMax setzen

[mistersixt]

Wie kann ich die Timeouts und Verbindungsabbrüche während des upgrades verhindern?

Arbeite mit "screen": damit kannst Du eine Console-Session starten und bei einem Verbindungsabbruch wieder "resumen". Also "apt-get install screen", dann einfach "screen" ausführen, einen Befehl ausführen (beispielsweise "apt-get dist-upgrade"), dann mit STRG-A-D die Session "detachen" und mit "screen -r" wieder resumen. Bzw. wenn die SSH-Verbindung wegfliegt, mit "screen -r" die alte Session wieder resumen (ein STRG-A-D ist quasi wie ein "Verbindungsabbruch )...


Gruss, mistersixt.

[floogy]

Hallo MisterSixt. Das hört sich interessant an, aber ich kann es mir nicht vorstellen.

Ich rufe also ssh$USER@vserver-im-netz.de auf, dort rufe ich su auf, und als root screen. screen läuft also im ssh-terminal in einer shell auf dem vserver, während ich vor der Kiste sitze von der aus ich ssh aufrief.

Nun fliegt mir die Verbindung weg. Wie bitte kann ich dann screen auf dem vserver dazu bringen, mit STRG-A-D die Session zu "detachen" und mit "screen -r" wieder zu resumen?

Ich denke, Ich habe Dich nicht ganz verstanden.

@Eliteforce

ich sehe nur TCPKeepAlive in der sshd_config man page

Hmm... sollte das noch von woody kommen, und daher nicht funktionieren?
Wie gehe ich das an?
Ich ändere das in der config, und gebe /etc/init.d/ssh reload an?

[Eliteforce]

restart, nicht reload
oder seperat stop und dann wieder start

zu der screen frage: wenn die verbindung getrennt wird bist du ja schon "detached", dann brauchst du dich nur mehr neu zu verbinden die session wieder aufnehmen (ich verwende dazu screen -D -R)

edit: du kannst das kommando auch bei putty unter connection - ssh - remote command eintragen, dann wird es immer nach dem verbinden ausgeführt

[floogy]

Aber mit restart verliere ich ja die Verbindung. Ist es sicher, dass das script dann noch weiter abgearbeitet wird, und ssh wieder gestartet wird?

[Eliteforce]

deine verbindung wird nicht getrennt, es wird nur der haupt-sshd prozess neu gestartet soweit ich weiß

[floogy]

Aber sshd ist doch der Prozess, der die Bindung hält?

Also ich kapier da gar nichts:

Code: Alles auswählen

root@ubuntu:~# ssh user@server-im-netz.de
Password: 
Last login: Fri Apr 13 14:50:29 2007 from pd9e146846.dip0.t-ipconnect.de on pts/0
Linux p0.server-im-netz.de 2.6.9-023stab043.1-smp #1 SMP Mon Mar 5 16:35:19 MSK 2007 i686 GNU/Linux
You have new mail.
Last login: Fri Apr 13 16:04:37 2007 from pd9e146846.dip0.t-ipconnect.de
user@p0:~$ who
user  pts/0        Apr 13 14:50 (pd9e146846.dip0.t-ipconnect.de)
user  pts/1        Apr 13 16:04 (pd9e146846.dip0.t-ipconnect.de)
user@p0:~$ su
p0:/home/user# screen
[detached]
p0:/home/user#
p0:/home/user# ps axu|grep screen
p0:/home/user#

Es gibt ja nicht mal einen Prozess screen, der nun läuft, wie soll denn dann darin das upgrade ungestört weiterlaufen. Außerdem bin ich noch immer per ssh verbunden. Wenn nun die Verbindung abbricht, kann ich wie resumen?

EDIT: Ich habe es jetzt mal mit top probiert, und hier@home mal den ssh-clienten mit killall ssh abgeschossen.
Danach konnte ich mit ssh wieder die Verbindung zu dem server herstellen, und tatsächlich rief screen -D -A wieder die session mit laufendem top auf. Das heißt aber nicht, dass ich das verstehe...

[armin]

man screen oder http://www.google.de/search?q=screen+howto
Kennt die beiden Freunde niemand mehr?
Screen läuft auf dem entferntenRechner, ist also komplett unabhängig, von deiner abgebrochenen SSH-Session.

[floogy]

Code: Alles auswählen

p0:/home/user# ps axu|grep screen
p0:/home/user#

Dann war das wohl ein anderer Fehler. Da hätte dann doch wohl screen weiterlaufen müssen, oder?
Hmmm... Obwohl screen offensichtlich funktioniert läuft der Prozess nicht, wenn ich mich nach der abgebrochenen Session wieder am vserver anmelde. Ich nehme mal an, dass screen nur die Verbindung zum alten Terminal wiederaufnimmt, d.h., dass die Prozesse nicht innerhalb screens laufen, sondern auf der detatchten pts/0 oder so ähnlich, die wird ja auch weiterhin angezeigt, daher ja auch zwei sessions, die who anzeigt.

Werde mir mal die manpage oder das howto durchlesen, danke.

Bleibt die Frage, weshalb reload nicht reicht, zum einlesen der veränderten sshd Konfiguration.

[floogy]

@Eliteforce, mistersixt + Trigger

Es muss TCPKeepAlive heißen.
Ein restart läuft problemlos ohne Unterbrechung der Verbindung durch.
Screen funktioniert auch so, wie ihr es mir erklärt habt.

Ob ich das nun verstehe sei mal dahingestellt. Ich setze den thread mal auf gelöst.

[tapferesschneiderlein]

Code: Alles auswählen

p0:/home/user# ps axu|grep screen
p0:/home/user#

Dann war das wohl ein anderer Fehler. Da hätte dann doch wohl screen weiterlaufen müssen, oder?.

Der "Master"-Prozeß heißt SCREEN, was beispielsweise ein `grep -i screen` zeigt.

Du kannst Dir nach einem Reconnect laufende Screen-Sessions mit `screen -ls` anzueigen lassen.