Ubuntu sftp chroot jail path wird nicht gelesen?

517
FireyFly

Ich bin auf ein Problem gestoßen, das ich seit Stunden durcheinandergebastelt habe und nicht verstehe, was passiert. Ich habe Tonnen von Guides zu diesem Thema gelesen, was eine zweiminütige Setup-Aufgabe auf Ubuntu sein sollte, und ich kann es immer noch nicht schaffen, damit es funktioniert.

Das Problem ist:

Ich habe die richtige sshd_config eingerichtet, zumindest hoffe ich, dass ich es richtig gemacht habe ...

Subsystem sftp internal-sftp  Match Group sftpusers ChrootDirectory /var/www AllowTCPForwarding no X11Forwarding no ForceCommand internal-sftp

Beide / var / www haben die Berechtigungen von 755 root: root. Ja, ich habe meinen SSH-Dienst unzählige Male neu gestartet. Ja, ich habe ungefähr 30 stackoverflow-Posts über solche Dinge gelesen, aber noch nie etwas gefunden, das mit meinem Problem in engem Zusammenhang steht.

Jetzt, da ich mit den Voraussetzungen fertig bin, kommt das eigentliche Problem: Wenn ich versuche, mich mit einem SFTP zu verbinden, sehe ich Folgendes im Auth-Log:

Nov 8 22:38:07 hidden_server_name sshd[7436]: Accepted password for wordpress_user from imagine_my_hp_address_here port 49508 ssh2 Nov 8 22:38:07 hidden_server_name sshd[7436]: pam_unix(sshd:session): session opened for user wordpress_user by (uid=0) Nov 8 22:38:07 hidden_server_name systemd: pam_unix(systemd-user:session): session opened for user wordpress_user by (uid=0) Nov 8 22:38:07 hidden_server_name systemd-logind[1462]: New session 241 of user wordpress_user. Nov 8 22:38:07 hidden_server_name sshd[7481]: fatal: bad ownership or modes for chroot directory component "/" Nov 8 22:38:07 hidden_server_name sshd[7436]: pam_unix(sshd:session): session closed for user wordpress_user Nov 8 22:38:07 hidden_server_name systemd-logind[1462]: Removed session 241.

Natürlich ist "wordpress_user" ein Mitglied der Gruppe "sftpusers". Das Problem ist diese Zeile:

Nov 8 22:38:07 hidden_server_name sshd[7481]: fatal: bad ownership or modes for chroot directory component "/"

Warum will es in das Root-Verzeichnis des Servers wechseln, wenn es eindeutig auf / var / www eingestellt ist?

Sogar versuchte das Home-Verzeichnis mehrmals an alle möglichen Dinge des Benutzers anzupassen.

Jemand bitte lindern Sie mich von diesen Kopfschmerzen, es tut weh! : D

0

2 Antworten auf die Frage

0
harrymc

Dies ist beabsichtigt.

Strikte Berechtigungen würden Sie dazu zwingen, das /var/www/Verzeichnis als root mit den Dateien und Unterverzeichnissen zu füllen, die für Ihren Benutzer oder Ihre Gruppe ausgewählt wurden. Das ist nicht optimal.

Es ist besser, ein Unterverzeichnis anzulegen, in dem /var/www/Ihr Benutzer schreiben kann, und /var/www/root bleibt .

Wenn Sie nur einen virtuellen Host auf dem Webserver haben, ist dies ein Beispiel dafür, was Sie tun können.

sudo chown root:root /var/www/ sudo chmod u=rwx,g=rx,o=rx /var/www/  sudo mkdir /var/www/site1/ sudo chgrp sftponly /var/www/site1 sudo chmod u=rwx,g=rwxs,o=rx /var/www/site1/

Fügen Sie in der Konfigurationsdatei Ihres SSH-Servers Folgendes hinzu:

Match group sftponly ChrootDirectory /var/www/ X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp -d site1

Quelle: Seite neu laden ungültiger Besitz oder Modi für das Chroot-Verzeichnis "/ var / www" .

Danke, dass Sie versucht haben zu helfen. Leider immer noch das gleiche Problem :( selbst in dem Artikel, den Sie als Quelle verlinkt haben, hat der Kerl einen Fehler mit: "fatal: falscher Besitz oder Modi für das Chroot-Verzeichnis" / var / www "") ist "/", obwohl das Chroot-Verzeichnis gesetzt ist. FireyFly vor 5 Jahren 0
Versuchen Sie vielleicht, einen Ordner direkt unter `/` zu verwenden, der der Einschränkung gehorcht. harrymc vor 5 Jahren 0
Nichts funktioniert :( Gibt es vielleicht eine Einstellung in der sshd_config, die mich daran hindern könnte, es zu funktionieren? EDIT: Ich meine, es gibt viele andere Einstellungen als diese, aber gibt es eine, die dies tun könnte? FireyFly vor 5 Jahren 0
0
Kenster 
ChrootDirectory /var/www ... bad ownership or modes for chroot directory component "/"

Die ChrootDirectory-Option setzt voraus, dass das Chroot-Verzeichnis und alle übergeordneten Verzeichnisse root gehören. Aus der Dokumentation (Hervorhebung hinzugefügt):

ChrootDirectory
Gibt den Pfadnamen eines Verzeichnisses an, zu dem nach der Authentifizierung chroot (2) werden soll. Beim Sitzungsstart überprüft sshd (8), dass alle Komponenten des Pfadnamens Root-Verzeichnisse sind, die von keinem anderen Benutzer oder keiner Gruppe beschrieben werden können . Nach der chroot ändert sshd (8) das Arbeitsverzeichnis in das Heimatverzeichnis des Benutzers.

In Ihrem Fall beschwert sich der SSH-Server über das Stammverzeichnis "/" des Systems. Anscheinend verfügt das Stammverzeichnis über Berechtigungen, die diese Anforderungen nicht erfüllen.

Die einfachste Lösung besteht darin, das Stammverzeichnis an die Berechtigungen 0755 und den Besitzer des Eigentümers anzupassen. Die einzige Alternative, die ich kenne, wäre , eine eigene Kopie des SSH-Servers mit deaktivierter Prüfung zu erstellen .

ja, die Protokolle sagen das aber: "drwxrwxr-x 24 root root 4.0K 9. November 20:51." FireyFly vor 5 Jahren 0
'drwxrwxr-x' Mit anderen Worten, die Gruppenschreibberechtigung ist aktiviert. Das ist nicht erlaubt. Kenster vor 5 Jahren 0
Ich habe schon versucht, es auf 755 zu setzen, bevor ... es nicht funktioniert hat, und jetzt ist es unglaublich ... Vielen Dank, Sir. FireyFly vor 5 Jahren 0

Verwandte Probleme