Root kein login möglich

O

ostrohschein

Registered User
Hallo
Nachdem ich mein Rootpasswort für den Support auf Auslieferungszustand zurückgesetzt habe, kann ich mich mit diesem nicht mehr einloggen. 1und1 hat Probleme mit der Cisco -Firewall und hat diese deaktiviert(iptables oder SUSE-FW nicht aktiv). Ich hatte Probleme mit dem ssh-Login, ssh hat mich immer nach eingabe des Pw rausgeschmissen. Ich gehe davon aus, das entweder der Support oder so ein sch**** Hacker den Root gehackt hat. Wie kann ich im Rescue-System mein Passwort zurücksetzten(Root läuft in Rescue). Ich probiere schon seit heute morgen vergeblich im Rescue-System meine Platte zu mounten, bekomme es aber nicht hin. Würdet Ihr mir helfen können? Wäre nett.
SUSE 9.3
 
Du startest das Rescue-System und mountest die Festplatte. Dann chroot-est du und änderst das PW. Anschließend "exit" um aus dem chroot heraus zu kommen.
 
bwar said:
Du startest das Rescue-System und mountest die Festplatte. Dann chroot-est du und änderst das PW. Anschließend "exit" um aus dem chroot heraus zu kommen.
Click to expand...
Das mount -t ext3 /dev/hda1 (denke doch ist die root partition?) geht aber nicht. Sagt mir immer mounten nicht möglich device nicht gefunden.
Ist der Befehl, den ich eingebe vielleicht falsch? Auf der 1und1 FAQ ist es auch beschrieben, geht aber auch nicht. *verzweifel*
 
mount -t ext3 /dev/hda1 /mnt

oder

mount -t ext3 /dev/hda3 /mnt

oder

mount -t ext3 /dev/sda1 /mnt

oder

mount -t ext3 /dev/sad3 /mnt


das dürften wohl die gängigsten sein.
Dannach:
chroot /mnt
dann:
passwd
dann: exit
dann: Neustarten
 
djrick said:
Die Erfahrung lehrt, dass das seltener Zutrifft :)
Click to expand...

Danke für Eure schnelle Hilfe.
Wenn ich die Commandos eingebe, erhalte ich folgenden Fehler bei allen devices die ich Probiere:
rescue:~# mount -t ext3 /dev/hda1 /mnt
mount: /dev/hda1 is not a valid block device

So langsam ist es nichts mehr mit kühlen Kopf bewahren.:confused:
 
djrick said:
Poste mal die Ausgabe von den Befehl 'mount'
Click to expand...

rescue:~# mount
/dev/ram0 on / type ext2 (rw,errors=remount-ro)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
 
Manchmal lohnt es sich doch, dumm in der Gegend herum zu lesen ...
Guin hatte hier eine ganz gute Idee (muss man auch erst drauf kommen). :)
Wenn Du ein software-raid hast (was ich nicht fuer unwahrscheinlich halte), dann kann es sein, dass Du das "raiddevice" in der rescue Umgebung erst aktivieren musst.
Auch heisst ein software-raiddevice anders, es ist keines der ueblichen physikalischen blockdevices sondern heisst dann ueblicherweise /dev/md0 oder /dev/md1 oder so und das muesstest Du wenn dann mounten.
Dummerweise gibt es zwei (Generationen) von Werkzeugen, mit denen so ein software_Raid ueblicherweise angelegt und verwaltet wird.
Wenn bei Dir noch die raidtools eingesetzt werden, dann hilft das hier vllt. http://www.selflinux.org/selflinux/html/software_raid03.html
Wenn bei Dir die juengere Version eingesetzt wird (wovon ich ausgehe), dann kannst Du mit "mdadm -Q /dev/<blockdevicefile>" erfahren, ob und in welchem raiddevice das Blockdevice (hda1, sda1, scd1) existiert.
Wenn Du SCSI Platten hast probier's mit sda1, sdb1, etc. bei IDE mit hda1, hdb1, hdc1 etc.
Mit "mdadm -R /dev/<raiddevicefile>" kann dann das raiddevice gestartet werden und wie ein normales device gemounted werden.

Aber versuch ruhig erstmal einen mount mit "mount -t auto /dev/md0 /mnt" dabei kann der fstype variieren.

Wenn Du Hardware Raid hast schau mal, ob Du bei 1&1 irgendwo herausfinden kannst (faq) hinter welchem Devicefile sich das raidvolume dann versteckt.

Um dein System ein wenig zu "betrachten":
- "cat /proc/pci" -> Wenn Du SCSI Platten hast erwarte ich hier einen SCSI Controller (der Umkehrschluss ist zwar nicht ganz so rund, aber nicht unwahrscheinlich)
- "cat /proc/mdstat" -> Wenn schon software-raiddevices aktiv sind stehn die hier drin.
- "lsmod" -> Wenn Du SCSI hast sollte hier ein entsprechender Treiber auftauchen (bei modernen Distributionen auf scsi_mod gemapped).
- detailliertere Informationen ueber gefundene Hardware findet sich dann unter /proc/scsi und Co.

Ciao,
Mercy.
 
Mercenary said:
- "lsmod" -> Wenn Du SCSI hast sollte hier ein entsprechender Treiber auftauchen (bei modernen Distributionen auf scsi_mod gemapped).
- detailliertere Informationen ueber gefundene Hardware findet sich dann unter /proc/scsi und Co.
Click to expand...
Danke dir, bin etwas weiter gekommen.
Es war mount -t auto /dev/md1 aber jetzt nimmt er das chroot nicht an. Genauso wenig umount um das Laufwerk wieder zu lösen.:confused: :confused:
 
Last edited by a moderator:
rtg said:
Was sagen denn chroot
Click to expand...
chroot wirft keinen Fehler aus, espassiert nach Eingabetaste nix.
Wenn ich nach chroot passwd root eingebe, sagt er, er kennt den Befehl nicht. Habe schon probiert in /etc passwd einzugeben, kommt das gleiche.
umount konnte ich lösen geht wieder.
 
Eigentlich sieht das ja fast so aus, als waerst Du schon im "chroot" gewesen, haettest dann die Sitzung wieder verlassen und dann /mnt unmounten koennen.
"passwd" wirst Du nicht in /etc sondern eher in /usr/bin oder /bin finden.
Einfach nochmal mounten, chrooten, dann in /usr/bin passwd ausfuehren.

So long,
Mercy.
 
Mercenary said:
"passwd" wirst Du nicht in /etc sondern eher in /usr/bin oder /bin finden.
Einfach nochmal mounten, chrooten, dann in /usr/bin passwd ausfuehren.
Click to expand...
Das passiert, wenn ich passwd aufrufe
rescue:~# /bin/bash passwd
passwd: /usr/bin/passwd: cannot execute binary file

Die passwd liegt in /etc bei mir. Ausführen geht leider auch nicht.
 
Last edited by a moderator:
ostrohschein said:
Die passwd liegt in /etc bei mir. Ausführen geht leider auch nicht.
Click to expand...
Jein (:D ) setz mal ein "cat /etc/passwd" ab und vergleich das Ergebnis mit dem, was Du als Inhalt eines binary erwarten wuerdest. ;)
Das ist eine Konfigurationsdatei, das binary liegt woanders heisst nur genau so.

ostrohschein said:
rescue:~# /bin/bash passwd
passwd: /usr/bin/passwd: cannot execute binary file
Click to expand...

Da habe ich was zu gefunden (ich weiss ja nicht wie en detail so ein rescue System von innen aussieht aber warum rufst Du die bash explizit auf?):
http://www.linuxfibel.de/bash.htm
-c Kommandofolge

Die Bash liest und startet die Kommandos aus "Kommandofolge", welche als eine einzelne Zeichenkette anzugeben ist. Alles, was der Zeichenkette folgt, wird als Argument dem letzten Kommando der Kommandofolge übergeben:
user@sonne> bash date -u
date: /bin/date: cannot execute binary file
user@sonne> bash -c date -u
Sam Jul 8 10:16:17 MEST 2000

(Wird der Bash ein Argument übergeben, das keine Option ist, so interpretiert sie das Argument als Datei, die die Kommandos enthält. »date« ist natürlich keine Datei, die Kommandos beinhaltet, also beschwert sich die Bash...). Die Bash in Verbindung mit »-c« arbeitet als nicht-interaktive Shell.
Click to expand...

Probier das mal.

Ciao,
Mercy.
 
Mercenary said:
Probier das mal.

Ciao,
Mercy.
Click to expand...
So langsam bekomm ich Brechreiz, so dämlich bin ich doch auch wieder nicht. Auch das schlägt fehl, ich lass gerade mal ein anderes Rescue-System booten. Mal sehen ob es daran liegt.
 
Root -Login geht wieder

Leider nicht ohne Hilfe des Supports, da ich vermute, das mit dem Rescue-System etwas nicht passt, funktioniert mein rootlogin wieder. Ich bin halt noch zu newbie im Linuxbereich, aber nichts desto trotz bedanke ich mich erstmal für die schnelle und zahlreiche Hilfe. Echt spitze, hoffe ich werde auch mal so helfen können. Danke, danke.
 
You must log in or register to reply here.
Back
Top