ssh daemon Fehler nach Kernelupdate

mille

New Member
Hallo, ich habe einen V-Server, der nach einem Kernelupdate nicht mehr ganz korrekt arbeitet.
Kernel ist nun 2.6.18-028stab070.5

Ich erhalte folgende Fehlermeldung:

sshd[4028]: error writing /proc/self/oom_adj: Operation not permitted
sshd[4028]: Server listening on xx.xx.xx.xx port 22.
sshd[4028]: Received signal 15; terminating.
sshd[5289]: error writing /proc/self/oom_adj: Operation not permitted
sshd[5289]: error: Bind to port 22 on xx.xx.xx.xx failed: Cannot assign requested address.
sshd[5289]: fatal: Cannot bind any address.

Hat jemand einen Rat?
 
Welche Virtualisierung wird verwendet und welche Distribution? Von welchem auf welchem Kernel wurde geupdatet?
 
Verwendet wird Virtuozzo. System ist Debian 5.0 und der bisherige Kernel war der 2.6.18-028stab070.2
 
Hi!

Habe scheinbar dasselbe Problem, vermutlich beim selben Hoster.

Der neue Kernel ist zumindest derselbe, mit einem Compiledatum vom 17. September.
Das System ist auch ein Debian 5.0, und vorher funktionierte auch alles super.

Am 23. September wurde laut syslog der vServer fuer ein paar Minuten runtergefahren.

Danach tritt seitdem das Problem mit dem SSH Daemon auf.

In der /etc/ssh/sshd_config hab ich mal von der recovery console aus LogLevel auf DEBUG3 gesetzt, durch diese Einstellung erzaehlt /var/logauth.log aber leider nicht viel mehr.

Der Daemon scheitert immer wieder am Binding des Ports und kriegt dann ein Signal 15 (SIGTERM).
Fast immer liegt das wohl daran, dass bereits ein anderes Programm diesen Port belegt.
Es koennte sogar SSH Daemon selber sein, soweit ich das von anderen gelesen hab, z.B.:

* Ein Monitoringprogramm checkt das Laufen von SSHd bzgl. eines falschen Ports und versucht vergeblich immer wieder, SSHd zu starten.

* Ein PID file von SSHd von vor dem reboot liegt noch wo rum (konnte keines finden)

* Eine Firewall blockiert das Starten von SSHd an diesen Ports (konnte nix passendes finden, und auch andere Ports alleine gingen nicht)

Dann habe ich im rc.local Skript noch "uname -a" und "netstat -tln" in eine Datei loggen lassen. Heraus kam jedoch, dass _kein_ Programm auf den SSHd ports horcht.
=> hae?

Der Stand ist also wie folgt: seit Kernel-Update kriegt SSHd die ports nicht mehr gebunden, weil sie angeblich schon belegt sind, jedoch laesst nicht feststellen, durch was und wieso.

Weiss da jemand schon mehr oder hat eine Idee, was man noch pruefen koennte?

Danke!
 
Hallo!
Und auf diesem Port (8443) lauscht definitiv auch kein anderes Programm (Plesk installiert?)?

mfG
Thorsten
 
Nein, kein Plesk o.ae., nur Debian 5.0, bin reiner Konsolenadmin.
Hatte SSH monatelang auf 22 und 8443 laufen, problemlos.

Hatte dann testweise 22 rausgenommen, also nur 8443.

Um sicherzugehen, dass kein - bzw. um rauszufinden, welches - andere Prog den Port(s) schon belegt, hab ich eben netstat Ausgaben gesammelt, aber da sieht man nix...
 
Apache Instanzen laufen auf den unteschiedlichsten Ports (80, 443, 40080, ...) weiterhin problemlos.

Die HTTPS-Verbindung auf Port 443 unter Apache tut es auch weiterhin. Es kann also nicht eigentlich nicht sein, dass irgendwas alle sicheren Verbindungsversuche kappen will.
(Ausser OpenSSH und Apache nutzt sonst auf dem Server nichts anderes SSL.)

Dennoch ereignet sich auch das Folgende:

Habe nun dropbear (alternativer schlanker SSH2-Server) statisch kompiliert und ueber die recovery console installiert und per /etc/rc.local auf Port 18443 ausfuehren lassen.

Die geloggten netstat Ausgaben zeigen auch an, dass auf dem Port gehorcht wird, jedoch bewirkt ein "ssh user@m.y.i.p -p 18443" sowie "telnet m.y.i.p 18443" das gleiche wie bei Port 22 bzw. 8443.

Das macht das ganze noch kurioser.

Schade, dass sich der OP hier nicht mehr meldet - vielleicht hat er es bereits geloest?

Eine support mail an den Hoster hat nach drei Tage dauernder Antwort leider nur offensichtliche Infos gebracht a la "Ihr SSH Server laeuft wohl nicht".

In mittlerweile zwei anderen Foren gibt es vergleichbare Berichte/Hilfegesuche bzgl. dieses Themas und desselben Hosters.
Da der Hoster einer der groessten ist, muessten eig. viel mehr Leute ein Problem haben...
Zum Verzweifeln... :(

Hat jemand noch eine andere Idee?

PS: es alles nur IPv4 Adressen, also kein Problem mit Versuchen von Port-Doppelbelegungen (IPv4 + IPv6), was sonst ja auch zu Problemen fuehren kann
 
Update:

Ueber den per dropbear servierten port komme ich nun ploetzlich doch auf den server.

Von dort aus kann ich den OpenSSH daemon aber ganz normal per init script starten.

Danach hab ich mir mal die init scripts angeschaut.

Das ssh init script wird in den runlevels 1-5 zu einem frueheren Zeitpunkt gestartet als das networking init script.

In meiner /etc/ssh/sshd_config verwende ich allerdings explizite IPs als ListenAddress options, von denen das OS aber zum Zeitpunkt des Aufrufs des ssh init scripts also noch nix wissen kann.

ListenAddress 0.0.0.0:12345 in der sshd_config zu verwenden hat erstmal geholfen, das Problem erstmal loszuwerden. Vielleicht nutzt das aber nicht jedem was.

Mir ist dann noch aufgefallen, dass die links in /etc/rc*, die auf das networking init script zeigen, einen Zeitstempel haben, der nur wenige Minuten frueher ist als der Zeitstempel der ersten boot-Meldungen von jenem boot, mit dem das SSH-Problem begann.

Per sehr freundlicher Hilfe im IRC channel dieses Forums wurde ich hingewiesen, dass ein Skript der Virtualisierungsmachinerie (virtuozzo 4) beim boot die default /etc/rc* links auf das /etc/init.d/networking script erstellt, _falls_ diese links fehlen.

Ich frage mich, wieso diese links vorher gefehlt haben sollten, das waere bei fruehern boots ja auch aufgefallen, und muesste das SSH-Problem ja vorher ausgeloest haben.
In anderen Foren aber haben die Leute ja aber auch jetzt erst dieses Problem bei diesem hoster.

Fuer mich ist eine Loesung also erstmal gefunden, vielleicht nutzt es ja jemand anderem auch.
 
Hallo zusammen,

ich habe genau das gleiche Problem, wohl genau beim gleichen Provider.

Habe dort sogar ingesamt 2 V-Server, bei beiden tritt das Problem auf.

Leider bin ich kein Linux-Spezi und weiß mir nun nicht so richtig zu helfen.
Alle Tipps zu dem Fehler die ich bisher gefunden haben helfen nicht.

Aber wenn ich das hier so lese, scheint das Problem ja ziemlich (Hoster)spezifisch zu sein...

Auf meine Mail zum Support habe ich bisher noch keine Antwort erhalten, beim Anruf habe ich nur den Hilfreichen Tipp bekommen "recovery system zu booten und in die error log zu schauen"... danke ...

wenn jemand mal eine lösung hat, die sich nicht über umwege zugang zum system verschafft, wäre ich dem sehr dankbar.

EDIT: wo wird dieses fehlerbild denn noch besprochen ?
 
Last edited by a moderator:
wenn jemand mal eine lösung hat, die sich nicht über umwege zugang zum system verschafft, wäre ich dem sehr dankbar.
===> (1)

EDIT: wo wird dieses fehlerbild denn noch besprochen ?
===> (2)

@ (1):

Wie willst es denn sonst loesen, wenn nicht ueber die Rettungskonsole? Es ist doch grad SSH, wo es streikt. Das ist dann auch kein Umweg, sondern nunmal genau der Weg, der fuer sowas gedacht ist.

@ (2):

Na gut, also dann Transparenz:

Ich liste jetzt nur die auf, die sich mit gr. Wahrscheinlichkeit auch auf den besagten als gleich vermuteten provider beziehen, also welche ich vorher schonmal andeutete:

Hier der aus der ersten Woche der Vorfalls, noch ohne Loesung:
http://meinews.niuz.biz/ssh-t586542.html (cookies anschalten, ist ne daemliche Seite, sonst kommt mit Firefox nicht mal zum Lesen)

Hier der aus der zweiten Woche des Vorfalls, Loesung scheint in dieselbe Richtung gegangen zu sein wie bei mir:
http://www.klamm.de/forum/showthread.php?p=5920279

Es gibt noch zahlreichen andere Threads woanders, die sich bzgl. konkreter Fehlermeldungen in den Logs befassen.

.
.
.

Was hast du denn schon alles ausprobiert, was hier im Thread schon steht? Bzw. was davon hast du dir bei deinen Systemen schon naeher angeschaut?
 
Hey,

danke für deine Antwort.
Wir haben uns gestern dann noch den ganzen Nachmittag mit unserem Spezi ransetzen müssen und haben da viel probiert und getestet um der Ursache auf den Grund zu gehen.

So richtig konnten wir den Fehler nicht ausfindig machen, wissen nun aber unter welchen Umständen das Problem auftritt.

Wir wollten nun nicht, wie du es zB gelöst hast, einen anderen SSH-Dienst installieren und über "Umwege" auf das System kommen. Wir wollen den Standard wieder herstellen, wie es vor dem Fehler war. Und wir haben nachweislich diesen Fehler nicht verursacht, sondern unser Hoster - ja, sagt es doch, es ist Strato ;) - demnach muss Strato dafür sorgen, dass es auch wieder normal läuft, so wie vorher...

Daher haben wir folgende Mail an den Support geschrieben, die ich hier mal reinkopiere, weil dort alle unsere Erkenntnisse von gestern drin stehen und ich sie nich nochmal formulieren muss :)


Strato-Mail said:
Guten Tag,

seit kurzer Zeit ist es auf allen Ihren virtuellen Servern nicht mehr möglich, die SSHd Konfiguration anzupassen. Ich administriere einige virtuelle Server von Ihnen für Geschäftkunden und auf allen konnte ich das selbe Fehlerbild feststellen. Ebenfalls gibt es im Internet bereits seit 1-2 Wochen Posts mit dem gleichen zusammenhang.

Es ist nur noch möglich die sshd_config mit absoluten Standardwerten beim boot starten zu lassen. Wenn man z.B. den Port oder die IP-Adresse (auf korrekte Werte) ändert, wird folgender Fehler beim Neustart in der auth.log protokolliert

sshd[4028]: Server listening on xx.xx.xx.xx port 1234.
sshd[4028]: Received signal 15; terminating.
sshd[5289]: error: Bind to port 1234 on xx.xx.xx.xx failed: Cannot assign requested address.
sshd[5289]: fatal: Cannot bind any address.

Sobald man den Port und/oder die ListenAdress ändert startet der SSH-Deamon nicht mehr beim boot. Einzige Möglichkeit den Server wieder per SSH ansprechen zu können ist, das Recovery System zu booten, die SSH-Konfig Files in /repair/etc/ssh/* zu löschen und aus dem Recovery System /etc/ssh/* wieder rüber zu kopieren.

Damit sind aber wieder die SSH-Standardeinstellungen aktiv.
Aus Sicherheitsgründen haben alle meine Server zwei IP-Adressen.
Auf der "öffentlichen" Adresse, die z.B. Apache oder FTP nutzt, soll kein SSH ansprechbar sein. Die zweite, nicht öffentlich bekannte und genutzt Adresse, dient nur zur Administration (z.B. durch SSH). Ebenfalls ist überall der Standardport angepasst worden auf 1234.
Mit diesen normalen(!) Konfigurations-Änderungen, ListenAdress auf eine bestimmte IP festlegen und Port ändern, ist es nicht mehr möglich, dass SSH bei Ihren Servern beim Boot startet.

Im ersten Schritt habe ich das kürzlich durchgeführte Kernel-Update dafür verantwortlich gemacht. Mir ist aber aufgefallen, dass das wohl doch nicht direkt im Zusammenhang steht.
Durch meine mehreren Servern, die alle zu unterschiedlichen Tagen geupdatet werden/worden, konnte ich beobachten, dass alle Server dieses Problem aufweisen, auch an den Servern wo noch kein Kernel-Update durchgeführt wurde.

Als Beispiel wurde auf dem Server, zu diesem Paket, das Update am 04.10. zwischen 7-8Uhr eingespielt. Das SSH Problem ist mir aber bereits am 01.10. aufgefallen und ich habe alle Server darauf geprüft und auf alle Server kam ich nicht mehr rauf.

Ausnahme war hier ein Testsystem, mit einer nicht anpassten Standard-Konfiguration. Dort gab es diese Probleme nicht. Und auf allen anderen Servern gab es in den letzten 1-2 Monaten keine Systemänderungen und Updateinstallationen.

Also kurz zusammengefasst heißt es, dass man auf Ihren virtuellen Servern aus irgendwelchen Gründen seit 1-2 oder 3 Wochen keine angepasste SSH Konfuguration mehr fahren kann.

Ich hoffe Sie nehmen sich dieses Problem an oder wurden ggf. schon drauf hingewiesen. Wie gesagt taucht das Problem in manchen Foren bereits seit mehr als einer Woche auf - jedenfalls bei denen die SSH-Anpassungen durchgeführt haben.

Zur Zeit läuft der RemoteZugang über den Work-Around der Standardeinstellungen, ist aber aufkeinen Fall eine Dauerlösung für professionell eingesetze Server-Systeme.
 
Hi,

ist bei jemandem die Erklaerung fuer das ganze evtl. noch konkreter geworden?

Mich wuerde echt interessieren, woran das ganze denn nun wirklich letztendlich lag/liegt.

Danke!
 
Hallo DjoserX,

gibt es schon irgendeine Form von Response auf den ausführliche Mail an "Deutschlands kundenorientiertesten Dienstleister 2010" (Zitat vom Logo auf der Rechnung)?

Allmählich müssten die doch mal aus dem Knie kommen ...

Mir persönlich ist es ähnlich gegangen:

1 x angerufen = Empfehlung mit der Notfallkonsole + Logfiles
2 x gemailt und Problem mit sshd und smtp(d) (den ich ebenfalls auf die
an venet0:1 gebundene IP-Adresse umgebogen hatte) ausführlich
geschildert.

Antwort 4 Tage später (Zitat aus der ersten, automatisch generierten Antwort "Wir werden Ihnen so schnell wie möglich antworten, gewöhnlich innerhalb von einem Tag. Selbstverständlich werden alle Anfragen persönlich und individuell beantwortet."):
"Sehr geehrter Herr ...,

vielen Dank für Ihre Anfrage, die ich Ihnen gerne beantworte.

Bitte haben Sie Verständnis, dass wir für die Konfiguration Ihres Servers keinen Support übernehmen können.

Die Konfiguration der Server liegt im Aufgabenbereich des Kunden. Bitte beachten Sie, dass wir aufgrund des günstigen Preises des Produktes keinen Support für die Konfiguration des Systems oder externer Software übernehmen können.

Wir versuchen zwar stets, bei grundlegenden Fragen trotzdem eine anfängliche Hilfestellung zu gewähren, können aber hier leider nicht Ihre Serverkonfiguration überprüfen.

Für weitere Fragen stehen wir Ihnen selbstverständlich gerne zur Verfügung.

Ihre Meinung über unseren Kundenservice ist uns sehr wichtig! Bitte nehmen Sie sich etwas Zeit für unseren Fragebogen - damit wir zukünftig noch besser auf Ihre Wünsche eingehen können. Das Ausfüllen dauert nur ca. 3 Minuten. "

Und nachdem ich im Kundenservice meine Meinung zu dieser Art von "Support" kund getan, sprich eben diesen mit negativen Bewertungen überhäuft habe, erfahre ich nach Abschluss der Umfrage, wie toll der Support ist und man bedankt sich dafür, dass ich ihn so gut bewertet habe. Ironie?

Wie auch immer. Ich habe an der Config meines V-Servers nichts geändert. Nur regelmäßig via apt-get die Security-Fixes / Patches eingespielt. Der Server lief über ein Jahr problemlos - bis zum Kernel-Update am 27.09.2010.

Ich versteh ja auch, dass die Jungs beim Level 1 (?) - Support nicht unbedingt jeden Service Case abdecken können. Aber die Kunden so für dumm zu verkaufen, dazu gehört schön eine gehörige Portion Arroganz, Bornierheit oder Gleichgültigkeit.

Denn nicht jeder, der einen V-Server anmietet, ist ein Vollidiot. Und die Option, dass der Kunde vielleicht sogar mehr Wissen haben könnte, als der Support scheint in den Trainings-Manuals bzw. -Workshops für eben diesen nicht vorgesehen zu sein.

Vielleicht sollte der Provider selber mal einen Service Call beim Hersteller des V-Server-Kernels eintüten und dem statt seinen Kunden die Meinung sagen.

Was mich persönlich an der ganzen Sache am meisten nervt, ist weniger das technische Problem an sich. Shit happens, solange es Systeme wie Computer gibt. Was mich wesentlich mehr stört ist die Form, wie der Support des Providers darauf reagiert, d.h. jegliches Fehlverhalten auf seiner Seite kategorisch abstreitet und versucht, das ganze Problem auf die Dummheit oder technische Unwissenheit des Kunden abzuwälzen. Das zeugt für mich nicht gerade von "Kundenorientierung", Auszeichnungen dafür (s.o.) hin oder her!

Ich jedenfalls habe meine Lehren daraus gezogen: Kündigung meines V-Servers und aller Zustatzleistungen bei diesem Provider, Wechsel zu einem anderen, etwas Service freundlicheren (der hier im Forum schon öfter dafür gelobt wurde) hin und weg vom V-Server. Daheim ja, aber "in the wild" wo andere am Kernel rumdrehen - nein, das bitte nicht mehr, Preis hin oder her. Lieber 10,- € mehr im Monat und dafür selbst der Herr im Haus, auch wenn es auf etwas älterer Hardware ist.

Dennoch bin ich schon sehr gespannt, ob und wie es hier in diesem Thread weitergeht ;-)
 
Ich habe relativ zeitnah eine Rückmeldung von Strato erhalten, dass die das Problem unter der Ticket-Nr XY weiter bearbeiten und sich melden, sobald es Neuigkeiten gibt.

Seitdem habe ich an der Ecke jedenfalls nichts weiter gehört und es ist unverändert.
Aber da ein Ticket eröffnet wurde, denke ich mal das ich irgendwann eine Rückmeldung erhalten werde.

Sollte ich neues hören, werde ich mich melden.

Ich weiß noch nicht genau, ob es gut oder schlecht ist, dass ich so lange nix gehört habe von einem Ticket ;)
1) Hotline war überfordert und TT versinkt in den Tiefen von Strato
2) Wir sind da auf ein größeres und umfangreiches Problem gestoßen, an dem gearbeitet wird - und so lange dran gearbeitet wird, isses ja ok :)
 
Last edited by a moderator:
Gestern Abend 3 Std Komplettausfall.
Server down, Strato-Config Seite ebenfalls nicht erreichbar - zeitweise komplett down, zeitweise sicher auch überlastet.

Begründung: Stromausfall durch Netzbetreiber. Stromaggregate waren angelaufen und es gab Fehler in der USV. Daher Komplettabschaltung

So langsam mache ich mir wirklich gedanken...
3 Wochen null Reaktion auf ein offenes Ticket (was bedeutet, 3 Wochen deutlich höheres Sicherheitsrisiko meiner Server verursacht durch Strato!)
3 Stunden Ausfall durch fehlerhafte Notstromversorgung.

Hat Strato noch alles im Griff oder werden sie nun auch zu einen Massen-Ramsch-Laden ?
 
Last edited by a moderator:
Nach dem gestrigen Ausfall (peinlich, peinlich) war interessanterweise auch ein vServer betroffen, der den Kernelwechsel inkl. Neustart überlebt hatte. Somit ist wohl kein zwingender Zusammenhang gegeben, vermutlich wurde von irgendeinem Update der Fehler produziert.
Problem war - wie hier auch schon erwähnt - in den Logs recht schnell ausgemacht: networking lief nicht. Also wieder in die rcS.d geworfen, fertig. Fehlerwirkung behoben, Ursache unbekannt.

Seit dem Kernelupdate habe ich aber noch einen anderen vServer (glücklicherweise ein Testserver bevor Änderungen auf die Produktivsysteme gehen), bei dem gar nichts mehr geht. Konfiguration exakt gleich, jedoch weigert er sich zu booten, Logs sind allesamt leer.
 
Back
Top