nach reboot kein root login mehr möglich
nach reboot kein root login mehr möglich
hallo
hier kurz das setup:
es handelt sich um einen pentium III betriebenen, mit compaq hardware raid betriebenen rechner, der als server für ca. 40 clients dient. bisher lief woody und kernel 2.2 ohne probleme.
da der rechner aber seit bestimmt 200 tagen nicht mehr rebootet wurde, sind so allerhand security upgrades drüber gelaufen. bei dem versuch jetzt auf kernel 2.4 umzusteigen passiert folgendes:
der neu kernel bootet normal ohne weitere fehlermeldungen. doch nach dem bootvorgang sind keine logins mehr möglich. auf der konsole wird zwar das root-passwort als richtig erkannt, aber es wird keine bash zur verfügung gestellt. es scheint so, als ob diese auf /bin/false gesetzt sei. es wird anch korrektem login erneut ein neuer login bereitgestellt. bei falschem passwort erscheint "authentication failed" oder derart.
booted man nun den kernel mit init=/bin/bash als bootoption sind keine partitionen gemountet, keine kernelmodule geladen, keine dienste gestartet. das kann aber auch an der sache mit der bootoption an sich liegen.
aber: ein mount -a scheitert, weil existierende module nicht geladen werden können. jedes verzeichnis und partition muss händisch nachgemounted werden.
UND: das gleiche phänomen tritt nach dem reboot auch bei dem alten kernel auf, der zuvor ohne probleme lief.
es scheint, als ob eines der software upgrades irgendwas zerschossen hat, was ich hier nicht erkennen kann.
kennt jemand das problem, hat es selber gehabt und gelöst? oder hat jemand tips?
ob dieser forenzweig der richtige ist, ist mir unklar, aber das wird schon klappen
also im voraus dank
hier kurz das setup:
es handelt sich um einen pentium III betriebenen, mit compaq hardware raid betriebenen rechner, der als server für ca. 40 clients dient. bisher lief woody und kernel 2.2 ohne probleme.
da der rechner aber seit bestimmt 200 tagen nicht mehr rebootet wurde, sind so allerhand security upgrades drüber gelaufen. bei dem versuch jetzt auf kernel 2.4 umzusteigen passiert folgendes:
der neu kernel bootet normal ohne weitere fehlermeldungen. doch nach dem bootvorgang sind keine logins mehr möglich. auf der konsole wird zwar das root-passwort als richtig erkannt, aber es wird keine bash zur verfügung gestellt. es scheint so, als ob diese auf /bin/false gesetzt sei. es wird anch korrektem login erneut ein neuer login bereitgestellt. bei falschem passwort erscheint "authentication failed" oder derart.
booted man nun den kernel mit init=/bin/bash als bootoption sind keine partitionen gemountet, keine kernelmodule geladen, keine dienste gestartet. das kann aber auch an der sache mit der bootoption an sich liegen.
aber: ein mount -a scheitert, weil existierende module nicht geladen werden können. jedes verzeichnis und partition muss händisch nachgemounted werden.
UND: das gleiche phänomen tritt nach dem reboot auch bei dem alten kernel auf, der zuvor ohne probleme lief.
es scheint, als ob eines der software upgrades irgendwas zerschossen hat, was ich hier nicht erkennen kann.
kennt jemand das problem, hat es selber gehabt und gelöst? oder hat jemand tips?
ob dieser forenzweig der richtige ist, ist mir unklar, aber das wird schon klappen
also im voraus dank
-- tuxmas
- Six
- Beiträge: 8071
- Registriert: 21.12.2001 13:39:28
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Siegburg
Da fallen mir ein paar Möglichkeiten ein.
Checke mal, was in der Datei /etc/security/access.conf steht. Die Syntax ähnelt der von sudo.
Dein Server scheint ja schon was älter zu sein, daher checke auch /etc/default/login, falls vorhanden. Unter dem Parameter CONSOLE sind alle ttys aufgeführt, auf denen sich root anmelden darf.
Checke, ob in /etc/passwd als letzter Eintrag eine Shell steht.
Prüfe, ob die Datei /etc/securetty vorhanden und unbeschädigt ist. Hier sollten mindestens die ttys stehen.
Das wär's im Augenblick. Da war noch was mit PAM, aber ich weiß nicht mehr genau wie das ging. Warum ich das weiß? Weil mir vor ein paar Wochen eine Systemplatte abgeraucht ist und die Backupplatte zwar startetet, mich aber nicht als root dran ließ. Gute Sache, daß ich immer schön meinen Feuerwehrmann-User habe
Checke mal, was in der Datei /etc/security/access.conf steht. Die Syntax ähnelt der von sudo.
Dein Server scheint ja schon was älter zu sein, daher checke auch /etc/default/login, falls vorhanden. Unter dem Parameter CONSOLE sind alle ttys aufgeführt, auf denen sich root anmelden darf.
Checke, ob in /etc/passwd als letzter Eintrag eine Shell steht.
Prüfe, ob die Datei /etc/securetty vorhanden und unbeschädigt ist. Hier sollten mindestens die ttys stehen.
Das wär's im Augenblick. Da war noch was mit PAM, aber ich weiß nicht mehr genau wie das ging. Warum ich das weiß? Weil mir vor ein paar Wochen eine Systemplatte abgeraucht ist und die Backupplatte zwar startetet, mich aber nicht als root dran ließ. Gute Sache, daß ich immer schön meinen Feuerwehrmann-User habe
hallo zusammen:
boot-parameter "S" ??? bevor ich mich ergoogle, was bringt der? hab ich noch nie gehört
in /var/log/auth.log steht kein fehlercode oder irgendwas, was auf einen fehler hindeuten würde. es erscheint nur bei falscher eingabe des passwortes ein "authentication failure".
in /etc/security/access.conf sind alle einträge auskommentiert, d.h. jeder darf alles. außerdem ist sie von 2002 !!! d.h. da hat sich nichts verändert.
/etc/default/login ist nicht vorhanden
der letzte eintrag in /etc/passwd lautet
also hier könnte es haken.
was genau berwirkt das? bedeutet das, dass am ende ALLEN der login verweigert wird?
in /etc/securetty sind alle ttys aufgelistet
der kommentar zu PAM würde mich schon interessieren, weil ich hier ebenso schon öfters probleme mit irgendwelchen pam geschichten hatte
boot-parameter "S" ??? bevor ich mich ergoogle, was bringt der? hab ich noch nie gehört
in /var/log/auth.log steht kein fehlercode oder irgendwas, was auf einen fehler hindeuten würde. es erscheint nur bei falscher eingabe des passwortes ein "authentication failure".
in /etc/security/access.conf sind alle einträge auskommentiert, d.h. jeder darf alles. außerdem ist sie von 2002 !!! d.h. da hat sich nichts verändert.
/etc/default/login ist nicht vorhanden
der letzte eintrag in /etc/passwd lautet
Code: Alles auswählen
+:!:0:0:::/bin/false
was genau berwirkt das? bedeutet das, dass am ende ALLEN der login verweigert wird?
in /etc/securetty sind alle ttys aufgelistet
der kommentar zu PAM würde mich schon interessieren, weil ich hier ebenso schon öfters probleme mit irgendwelchen pam geschichten hatte
-- tuxmas
- Six
- Beiträge: 8071
- Registriert: 21.12.2001 13:39:28
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Siegburg
Ich schätze, das startet den Single-User Mode. Traditionell benutzt man dafür auch die "1".tuxmas hat geschrieben:hallo zusammen:
boot-parameter "S" ??? bevor ich mich ergoogle, was bringt der? hab ich noch nie gehört
K. A., einen solchen Eintrag habe ich noch nie gesehen. Die man-Page von passwd(5) schweigt sich auch aus. Evtl. kommentierst du die Zeile einfach mal aus und guckst, was passiert.der letzte eintrag in /etc/passwd lautetalso hier könnte es haken.Code: Alles auswählen
+:!:0:0:::/bin/false
was genau berwirkt das? bedeutet das, dass am ende ALLEN der login verweigert wird?
Zu der PAM-Geschichte fällt mir leider nichts ein.
- KBDCALLS
- Moderator
- Beiträge: 22455
- Registriert: 24.12.2003 21:26:55
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Dortmund
-
Kontaktdaten:
Das hab ich in etwa in einer Anleitung zur Konfiguration eines anonymen Apches gefunden
In passwd sollen nur diejenigen Einträge erscheinen, die für den Anonymous-Betrieb sinnvoll sind:
http://netzmafia.de/skripten/server/server5.html
In passwd sollen nur diejenigen Einträge erscheinen, die für den Anonymous-Betrieb sinnvoll sind:
Code: Alles auswählen
root:*:0:0::/:/bin/false
bin:*:2:2::/:/bin/false
ftp:*:40:100::/:/bin/false
ftpadm:*:99:100::/:/bin/false
Auch etc/group hat nur wenige Einträge:
users:x:100:root
bin:*:2:root
root:*:0:root
http://netzmafia.de/skripten/server/server5.html
Was haben Windows und ein Uboot gemeinsam?
Kaum macht man ein Fenster auf, gehen die Probleme los.
EDV ist die Abkürzung für: Ende der Vernunft
Bevor du einen Beitrag postest:
Kaum macht man ein Fenster auf, gehen die Probleme los.
EDV ist die Abkürzung für: Ende der Vernunft
Bevor du einen Beitrag postest:
- Kennst du unsere Verhaltensregeln
- Lange Codezeilen/Logs gehören nach NoPaste, in Deinen Beitrag dann der passende Link dazu.
Code: Alles auswählen
+:!:0:0:::/bin/false
So hab ich das zumindest noch dunkel in Erinnerung.
nach reboot kein root login mehr möglich
Hallo,
was mich hier eher irritiert ist das Ausruhfungszeichen in der /etc/passwd/.
Ich hatte auch schon mal so einen Fall - leider ohne mich konkret daran erinnern
zu können. Ich meine aber, das das ! ein Konto deaktiviert. Hier also von "+" ?
Deaktiviere doch mal dieses Konto, und schau mal was dann passiert.
Gruß
Matthias
was mich hier eher irritiert ist das Ausruhfungszeichen in der /etc/passwd/.
Ich hatte auch schon mal so einen Fall - leider ohne mich konkret daran erinnern
zu können. Ich meine aber, das das ! ein Konto deaktiviert. Hier also von "+" ?
Deaktiviere doch mal dieses Konto, und schau mal was dann passiert.
Gruß
Matthias
- KBDCALLS
- Moderator
- Beiträge: 22455
- Registriert: 24.12.2003 21:26:55
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Dortmund
-
Kontaktdaten:
Irgendwie scheint das ein verunglückter Eintrag zu sein.
http://www.linuxfibel.de/nis_cli.htm
Er soll mal das Datei posten
http://www.linuxfibel.de/nis_cli.htm
Er soll mal das Datei
Code: Alles auswählen
/etc/asswd
Was haben Windows und ein Uboot gemeinsam?
Kaum macht man ein Fenster auf, gehen die Probleme los.
EDV ist die Abkürzung für: Ende der Vernunft
Bevor du einen Beitrag postest:
Kaum macht man ein Fenster auf, gehen die Probleme los.
EDV ist die Abkürzung für: Ende der Vernunft
Bevor du einen Beitrag postest:
- Kennst du unsere Verhaltensregeln
- Lange Codezeilen/Logs gehören nach NoPaste, in Deinen Beitrag dann der passende Link dazu.
naja, der rest der passwd ist in ordnung...Er soll mal das Datei
Code:
/etc/asswd
posten
der oben genannte eintrag kommt dann zum tragen, wenn die clients NIS nutzen, das ist bei uns aber nicht so, so dass ich den eintrag gelöscht habe keine veränderung.
bin nun echt ratlos, warum der nach dem booten diese probleme macht.
weiß jemand, ob die openwall-patches sowas verursachen können?
resticted proc macht ja manchmal probleme, aber wirkt sich das so aus?[/quote]
-- tuxmas