12
Benutzer ausgesperrt nach chmod
Hallo an Alle,
nach erfolgloser Suche im Web und auch hier, wende ich mich an euch.
IST-Situation:
Bei einem fehlerhaften chmod-Befehl wurden die Rechte auf dem Debian Server verstellt. Mittlerweile wurde alles wieder zum Laufen gebraucht; Apache, Mail etc. läuft alles wieder. Ich habe mit root auch wieder vollen Zugriff per putty und per sftp.
Das Problem ist nun, dass ich mit keinem anderen Benutzer reinkomme.
Die Benutzer sind so eingestellt, dass Ihr Homeverzeichnis das entspr. Verzeichnis im vhosts-Verzeichnis ihrer Homepage ist. Wenn ich mich mit Filezilla per sftp verbinden will, kommt die Fehlermeldung "Server unexpectedly closed network connection". Auch über Putty kommt die Fehlermeldung.
Bitte sagt mir nicht, dass ich das System neu aufsetzen muss, das weiß ich auch, aber dafür muss ich mir erst Hilfe suchen, weil ich noch nicht soweit bin den Server komplett alleine neu aufzusetzen (mit allen Einstellungen).
Ich möchte den Server erstmal soweit haben, dass alles läuft und dann werde ich mich aber schnellst möglich auch daran setzen ihn neu aufzusetzen !
Wahrscheinlich muss nur noch 1-2 Rechte verändert werden, aber ich weiß so langsam nicht mehr welche. Muss proftpd noch zugriff auf irgendwelche Temp-Verzeichnisse haben ?
nach erfolgloser Suche im Web und auch hier, wende ich mich an euch.
IST-Situation:
Bei einem fehlerhaften chmod-Befehl wurden die Rechte auf dem Debian Server verstellt. Mittlerweile wurde alles wieder zum Laufen gebraucht; Apache, Mail etc. läuft alles wieder. Ich habe mit root auch wieder vollen Zugriff per putty und per sftp.
Das Problem ist nun, dass ich mit keinem anderen Benutzer reinkomme.
Die Benutzer sind so eingestellt, dass Ihr Homeverzeichnis das entspr. Verzeichnis im vhosts-Verzeichnis ihrer Homepage ist. Wenn ich mich mit Filezilla per sftp verbinden will, kommt die Fehlermeldung "Server unexpectedly closed network connection". Auch über Putty kommt die Fehlermeldung.
Bitte sagt mir nicht, dass ich das System neu aufsetzen muss, das weiß ich auch, aber dafür muss ich mir erst Hilfe suchen, weil ich noch nicht soweit bin den Server komplett alleine neu aufzusetzen (mit allen Einstellungen).
Ich möchte den Server erstmal soweit haben, dass alles läuft und dann werde ich mich aber schnellst möglich auch daran setzen ihn neu aufzusetzen !
Wahrscheinlich muss nur noch 1-2 Rechte verändert werden, aber ich weiß so langsam nicht mehr welche. Muss proftpd noch zugriff auf irgendwelche Temp-Verzeichnisse haben ?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 205134
Url: https://administrator.de/forum/benutzer-ausgesperrt-nach-chmod-205134.html
Ausgedruckt am: 24.12.2024 um 13:12 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
Die Fehlende Berechtigung für's Homeverzeichnis des Users ist ja nur eine mögliche Fehlerursache bei der Fehlermeldung "Server unexpectedly closed network connection". Also erstmal die Berechtigungen checken (mit ls -l)
Markus
Zitat von @PalRock:
...
Das Problem ist nun, dass ich mit keinem anderen Benutzer reinkomme.
Die Benutzer sind so eingestellt, dass Ihr Homeverzeichnis das entspr. Verzeichnis im vhosts-Verzeichnis ihrer Homepage ist. Wenn
ich mich mit Filezilla per sftp verbinden will, kommt die Fehlermeldung "Server unexpectedly closed network connection".
Auch über Putty kommt die Fehlermeldung.
ja, und wie sehen die Berechtigungen für diese Homeverzeichnisse aus?...
Das Problem ist nun, dass ich mit keinem anderen Benutzer reinkomme.
Die Benutzer sind so eingestellt, dass Ihr Homeverzeichnis das entspr. Verzeichnis im vhosts-Verzeichnis ihrer Homepage ist. Wenn
ich mich mit Filezilla per sftp verbinden will, kommt die Fehlermeldung "Server unexpectedly closed network connection".
Auch über Putty kommt die Fehlermeldung.
Die Fehlende Berechtigung für's Homeverzeichnis des Users ist ja nur eine mögliche Fehlerursache bei der Fehlermeldung "Server unexpectedly closed network connection". Also erstmal die Berechtigungen checken (mit ls -l)
Markus
Hallo,
erst mal danke für die schnelle Antwort.
Die Rechte für die Homeverzeichnisse stehen auf 755, habe aber auch schon mit 775 u. 777 getestet.
Kann das an den temporären Verzeichnissen liegen ?? Oder an den ssh-keys ??
erst mal danke für die schnelle Antwort.
Die Rechte für die Homeverzeichnisse stehen auf 755, habe aber auch schon mit 775 u. 777 getestet.
Kann das an den temporären Verzeichnissen liegen ?? Oder an den ssh-keys ??
Wer ist denn der Besitzer der Homeverzeichnisse?
Markus
Markus
Der Besitzer ist root, aber das htdocs-Verzeichnis darin gehört dann dem enspr. Benutzer.
Das hat aber vorher auch so funktioniert.
Es wurde ja nur was mit chmod verändert nicht mit chown...
Das hat aber vorher auch so funktioniert.
Es wurde ja nur was mit chmod verändert nicht mit chown...
gut, und in den Homeverzeichnissen ist auch jeweils der Benutzer der Besitzer?
Kannst Du denn nachvollziehen, welcher Befehl mit chmod irrtümlich ausgeführt wurde?
Bei Änderungen in den ssh-Keys kommt normalerweise eine Warnung mit der Frage, ob man den neuen Key akzeptiert. Aber das darf durch chmod eigentlich auch nicht geändert worden sein.
Markus
Kannst Du denn nachvollziehen, welcher Befehl mit chmod irrtümlich ausgeführt wurde?
Bei Änderungen in den ssh-Keys kommt normalerweise eine Warnung mit der Frage, ob man den neuen Key akzeptiert. Aber das darf durch chmod eigentlich auch nicht geändert worden sein.
Markus
Der Befehl war "chmod -R 775 images /". (oder 777) Damit sollte das Recht für ein Bild-Verzeichnis (und Unterordner) einer Homepage geändert werden, für den Upload von Dateien.
Das Problem war das Leerzeichen zwischen dem Verzeichnis-Namen und dem "/"...
Ich muss den Server sowieso neu aufsetzen, bzw schauen, wie ich das Back-Up einspiele, aber ich bin nun mal Neuling und der Kollege, der sich sonst drum gekümmert hat, ist weg.
Ich meinte nicht, dass dich der ssh-Key geändert hat, sondern das Recht auf den Dateien, in denen die Keys drinne stehen. Auf dem key ist das Recht 600 und auf dem key.pub ist das Recht 644.
Welches Recht muss den auf die ssh_config ??
Edit:
Das Verzeichnis "homepage.de" gehört root:root mit Recht 777 (hab ich jetzt einfach mal eingestellt)
Darin ist ein htdocs-Ordner der gehört web-homepage:www-data mit dem Recht 775
Das Problem war das Leerzeichen zwischen dem Verzeichnis-Namen und dem "/"...
Ich muss den Server sowieso neu aufsetzen, bzw schauen, wie ich das Back-Up einspiele, aber ich bin nun mal Neuling und der Kollege, der sich sonst drum gekümmert hat, ist weg.
Ich meinte nicht, dass dich der ssh-Key geändert hat, sondern das Recht auf den Dateien, in denen die Keys drinne stehen. Auf dem key ist das Recht 600 und auf dem key.pub ist das Recht 644.
Welches Recht muss den auf die ssh_config ??
Edit:
Das Verzeichnis "homepage.de" gehört root:root mit Recht 777 (hab ich jetzt einfach mal eingestellt)
Darin ist ein htdocs-Ordner der gehört web-homepage:www-data mit dem Recht 775
Zitat von @PalRock:
Der Befehl war "chmod -R 775 images /". (oder 777) Damit sollte das Recht für ein Bild-Verzeichnis (und
Unterordner) einer Homepage geändert werden, für den Upload von Dateien.
Das Problem war das Leerzeichen zwischen dem Verzeichnis-Namen und dem "/"...
Naja, dann lässt sich natürlich der ursprüngliche Zustand nur schwer rekonstruieren. Es gibt eine Möglichkeit mit einem Skript, das muss die ursprünglichen Berechtigungen an einem Vergleissystem ermitteln und dann auf dem zerschossenen System setzen. Hab ich mal drüber gelesen, aber ich weiß nicht, ob das geht.Der Befehl war "chmod -R 775 images /". (oder 777) Damit sollte das Recht für ein Bild-Verzeichnis (und
Unterordner) einer Homepage geändert werden, für den Upload von Dateien.
Das Problem war das Leerzeichen zwischen dem Verzeichnis-Namen und dem "/"...
Ich muss den Server sowieso neu aufsetzen, bzw schauen, wie ich das Back-Up einspiele, aber ich bin nun mal Neuling und der
Kollege, der sich sonst drum gekümmert hat, ist weg.
Ich meinte nicht, dass dich der ssh-Key geändert hat, sondern das Recht auf den Dateien, in denen die Keys drinne stehen. Auf
dem key ist das Recht 600 und auf dem key.pub ist das Recht 644.
Welches Recht muss den auf die ssh_config ??
Kollege, der sich sonst drum gekümmert hat, ist weg.
Ich meinte nicht, dass dich der ssh-Key geändert hat, sondern das Recht auf den Dateien, in denen die Keys drinne stehen. Auf
dem key ist das Recht 600 und auf dem key.pub ist das Recht 644.
Welches Recht muss den auf die ssh_config ??
samsung:~# ls -lh /etc/ssh/ssh_config
-rw-r--r-- 1 root root 1,6K Aug 29 2012 /etc/ssh/ssh_configNun ist das Problem ja nicht alleine ssh, sondern Du hast alle Berechtigungen zerschossen, nämlich von / aus rekursiv. Damit ist das System natürlich anfällig gegen Angriffe. Alleine das Wiederherstellen des Remotezugriffs wird Dir nix nutzen.
Markus
Zitat von @64748:
Naja, dann lässt sich natürlich der ursprüngliche Zustand nur schwer rekonstruieren. Es gibt eine Möglichkeit
mit einem Skript, das muss die ursprünglichen Berechtigungen an einem Vergleissystem ermitteln und dann auf dem zerschossenen
System setzen. Hab ich mal drüber gelesen, aber ich weiß nicht, ob das geht.
Das habe ich auch gelesen, aber ich hab noch weniger Ahnung. Wäre schön wenn man bei einem Befehl mit "/" wenigstens gefragt werden würde: "Soll wirklich für die Wurzel alles umgestellt werden ?"Naja, dann lässt sich natürlich der ursprüngliche Zustand nur schwer rekonstruieren. Es gibt eine Möglichkeit
mit einem Skript, das muss die ursprünglichen Berechtigungen an einem Vergleissystem ermitteln und dann auf dem zerschossenen
System setzen. Hab ich mal drüber gelesen, aber ich weiß nicht, ob das geht.
Nun ist das Problem ja nicht alleine ssh, sondern Du hast alle Berechtigungen zerschossen, nämlich von / aus rekursiv.
Damit ist das System natürlich anfällig gegen Angriffe. Alleine das Wiederherstellen des Remotezugriffs wird Dir nix
nutzen.
Das ist mir klar, deshalb werde ich mir ja schnellstmöglich Hilfe suchen und das System neu aufsetzen, oder, wenn ich es endlich hinbekommen, ein Backup einspielen. Nur das kann ich nicht tagsüber machen, da die Homepages und der E-Mail-Server laufen muss.Damit ist das System natürlich anfällig gegen Angriffe. Alleine das Wiederherstellen des Remotezugriffs wird Dir nix
nutzen.
Und nun möchte jmd gerne auch noch etwas per ftp hochladen und hat keinen Zugriff.
Ich könnte es mit root machen, aber das ist ja auch keine dauerhafte Lösung.
Gibt es vll noch andere Tricks/Tipps/Lösungen ??
Edit:
In der passwd wird ja für den Benutzer u.A. die Shell angegeben, z.B. "/usr/lib/openssh/sftp-server" müssen dort bestimmte Rechte gegeben sein ?
Nochmal Edit:
Ich habe mal Filezilla im Debug-Modus verbinden lassen, dabei kam das hier heraus:
Trace: Server version: SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2
Trace: Using SSH protocol version 2
Trace: We claim version: SSH-2.0-PuTTY_Local:_Nov_29_2012_22:59:17
Trace: Doing Diffie-Hellman group exchange
Trace: Doing Diffie-Hellman key exchange with hash SHA-256
Trace: Host key fingerprint is:
Trace: ssh-rsa ********************
Trace: Initialised AES-256 SDCTR client->server encryption
Trace: Initialised HMAC-SHA1 client->server MAC algorithm
Trace: Initialised AES-256 SDCTR server->client encryption
Trace: Initialised HMAC-SHA1 server->client MAC algorithm
Befehl: Pass: ********************
Trace: Sent password
Trace: Access granted
Trace: Server unexpectedly closed network connection"Access granted" sagt doch dass der Zugriff eigentlich erlaubt wurde, oder ?
Was soll ich sagen? Wenn das System komplett zerschossen ist, und das ist es, dann hilft Dir das Herumfummeln an einzelnen Symptomen wenig.
Blödsinn, weil Du doch den Bildern keine Ausführungsberechtigung geben willst. Die brauchen nur die Verzeichnisse damit man sie öffnen kann. Aber gut, das hilft Dir nicht weiter.
Die sicherste Lösung ist in der Tat den Server neu aufzusetzen und dann die Backups einzuspielen.
Wie die genauen Berechtigungen für die Verzeichnisse auf Deinem System aussehen müssen kann ich Dir leider nicht sagen, ich hab hier kein Debian-System zur Verfügung.
Viel Glück!
Markus
Server unexpectedly closed network connection
Das heißt aber, dass der Server die Verbindung nicht akzeptiert. Das kann verschiedene Ursachen haben, falscher Port oder sonst was.Wäre schön wenn man bei einem Befehl mit "/" wenigstens gefragt werden würde: "Soll wirklich für die Wurzel alles umgestellt werden ?"
Da fällt einem nix mehr ein..... jedenfalls mir nicht. Zum einen ist das nicht Windows zum anderen ist auch der Befehl chmod -R 755 imagesDie sicherste Lösung ist in der Tat den Server neu aufzusetzen und dann die Backups einzuspielen.
Wie die genauen Berechtigungen für die Verzeichnisse auf Deinem System aussehen müssen kann ich Dir leider nicht sagen, ich hab hier kein Debian-System zur Verfügung.
Viel Glück!
Markus
Zitat von @64748:
Wie die genauen Berechtigungen für die Verzeichnisse auf Deinem System aussehen müssen kann ich Dir leider nicht sagen,
ich hab hier kein Debian-System zur Verfügung.
Wie die genauen Berechtigungen für die Verzeichnisse auf Deinem System aussehen müssen kann ich Dir leider nicht sagen,
ich hab hier kein Debian-System zur Verfügung.
Tröste Dich, ich bin Debian Consultant, und auch ich könnte ihm nicht helfen, da er wie so viele hier einfach die wichtigsten Daten "vergessen" hat...
Lonesome Walker
Wie meinst du das, die "wichtigsten Daten vergessen" ?
Ich habe doch das System und die verwendeten Komponenten beschrieben.
Ich bin doch wohl nicht der erste, dem so ein Fehler passiert. Da muss es doch vorläufig eine Lösung geben, um erst einmal alles wieder zum Laufen zu bekommen...
Edit:
Falls jmd die Antwort wissen möchte:
Die Rechte der Ordner hinzu den vhosts, sowie auch der Ornder selbst, muss die Rechte 755 haben, dann klappt es wieder.
Ein Blick in die var/log/auth.log war der Schlüssel...
Ich habe doch das System und die verwendeten Komponenten beschrieben.
Ich bin doch wohl nicht der erste, dem so ein Fehler passiert. Da muss es doch vorläufig eine Lösung geben, um erst einmal alles wieder zum Laufen zu bekommen...
Edit:
Falls jmd die Antwort wissen möchte:
Die Rechte der Ordner hinzu den vhosts, sowie auch der Ornder selbst, muss die Rechte 755 haben, dann klappt es wieder.
Ein Blick in die var/log/auth.log war der Schlüssel...
Zitat von @PalRock:
Wie meinst du das, die "wichtigsten Daten vergessen" ?
Ich habe doch das System und die verwendeten Komponenten beschrieben.
Wie meinst du das, die "wichtigsten Daten vergessen" ?
Ich habe doch das System und die verwendeten Komponenten beschrieben.
Oh doch...
WELCHES Debian, wir haben ja mittlerweile schon ein paar, und nicht alle laufen mit Standard-Kernel oder default-settings, manche vergewaltigen Ihre Kisten mit PLESK, etc...
Lonesome Walker
