sftp: Zugriff verweigert

    So, ich stehe da mal wieder vor einem Problem und mache aktuell wohl mehr kaputt als ganz.

    Ich habe einen neuen Server. Auf dem läuft nun erstmals PHP als FastCGI. Soweit noch kein Problem. Sowohl statische als auch PHP-Files funktionieren.

    Allerdings habe ich nun das Problem, dass mich mein sftp nicht mehr auf den Server lässt -> Zugriff verweigert.

    Dessen Config ist aber identisch mit allen anderen Servern und die funktionieren problemlos. So, nun bin ich ratlos. Irgendwie denke ich, dass das was mit dem FastCGI zu tun hat, aber was? Warum?

    Also im Auth-Log steht auch nur:

    Code
    Aug  2 14:50:05 h20xxx sshd[16129]: Accepted password for wusr01 from xx.xx.xx.xx port 62776 ssh2
Aug  2 14:50:05 h20xxx sshd[16129]: pam_unix(sshd:session): session opened for user wusr01 by (uid=0)
Aug  2 14:50:05 h20xxx sshd[16131]: subsystem request for sftp

    Also das funktioniert. Zugangsdaten sind auch richtig. Nur, ich kann auf mein "public_html" nicht zugreifen.

    Also vielleicht was an den Rechten. Nur das ist ein Thema, wo ich immer wieder wie ein Ochse vorm Berg stehe. Aber wirklich einen Fehler sehe ich da nicht...

    Code
    drwxr-xr-x 2 wusr01 sftponly 4096  2. Aug 12:39 public_html


    Die darin enthaltenen Dateien haben die gleichen Besitzer / Gruppen. CHMOD steht zum Testen sogar schon auf 777. Aber dennoch, ich darf nicht auf den Ordner zugreifen.

    Oder, was mir gerade auch so einfällt. Ist das ein Problem, dass ich für fastcgi und sftp den gleichen User habe? Frage mich daher, da ich den User nicht ändern kann, so lange der Apache aktiv ist - muss den immer erst stoppen.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

    Nein, der Port ist offen und funktioniert. Ich kann mich ja anmelden, das geht ja. Nur dann kommt:
    1. Lese Verzeichnis"/"
    2. Zugriff verweigert

    Guggst Du oben im Auth-Log, die Verbindung wurde angenommen und aufgebaut ;)

    Hab es eben auch schon mal mit deaktiviertem Apache versucht - gleiche Spiel.

    So, hier mal das Debug hinterher:


    Warum oder wieso der Zugriff verweigert wurde steht aber nirgends nur, dass die Verbindung erfolgreich hergestellt wurde.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

    Ja, SSH ist 22, bei mir aber ein anderer. Dieser 63710 hier ist ja nur der, der für die Verbindung ausgehandelt wird ;)

    Beim letzten Versuch war es z.B.

    Code
    Aug  2 16:01:36 h20xxx sshd[16517]: Connection from xx.xx.xx.xx port 64133

    Bei einem SSH-Neustart steht der richtige Port:

    Code
    Aug  2 16:01:31 h20xxx sshd[16486]: Received signal 15; terminating.
Aug  2 16:01:31 h20xxx sshd[16511]: Set /proc/self/oom_adj from 0 to -17
Aug  2 16:01:31 h20xxx sshd[16511]: debug1: [B]Bind to port 22[/B] on 0.0.0.0.
Aug  2 16:01:31 h20xxx sshd[16511]: Server listening on 0.0.0.0 port 22.
Aug  2 16:01:31 h20xxx sshd[16511]: debug1: Bind to port 22 on ::.
Aug  2 16:01:31 h20xxx sshd[16511]: Server listening on :: port 22.

    Über den 22er wird also nur die Verbindung hergestellt, für die Datenverbindung wird ein andere genommen, den der Server selbst aushandelt.

    Bin aber schon einen Schritt weiter, auch wenn mir das nicht wirklich hilft.

    Über den normalen SSH-Login kann ich mich per sftp einloggen. Da lande ich dann zwar in einem komplett anderen Home-Dir, aber es geht. Also bestätigt auch, dass sftp und mein Prog funktioniert. Da scheint was mit dem sftp-User in Verbindung mit fastCGI nicht zu stimmen.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

    Das ist ja eben das, was ich oben sagte. Da stehe ich wie ein Ochse vorm Berg. Ich gehe aber davon aus, dass das passt.

    fcgi-User: wusr01
    sftp-User: wusr01

    Filesystem:
    drwxr-xr-x 2 wusr01 sftponly 4096 2. Aug 12:39 public_html

    Also dieser Ordner gehört genau diesem Benutzer. Nur darf der da eben dennoch nicht drauf zugreifen.

    Wie gesagt, für mich ist das fcgi komplettes Neuland. Vielleicht ist es das Problem, dass beide den gleichen User verwenden. Wenn ich das aber nicht mache, dann wüsste ich nicht, wie fcgi und sftp auf die gleichen Dateien zugreifen könnten / sollten.

    Oder es liegt an der Chroot-Umgebung, keine Ahnung.

    Wie gesagt, die Installation des Servers ist identisch mit 8 anderen. Nur dass der neue Server jetzt mit mod_fcgid läuft und nicht mehr mit mod_php

    So, und der sshd ist genauso konfiguriert wie sonst auch:

    Code
    Subsystem sftp internal-sftp


Match group sftponly
         ChrootDirectory %h
         X11Forwarding no
         AllowTcpForwarding no
         ForceCommand internal-sftp

    Und der User auch:

    Code
    wusr01:x:1000:1002:Mein Name,,,:/var/www/vhosts/h20xxx.domain.net:/usr/lib/sftp-server

    Das hier meldet mein FTP-Prog bei einem anderen Server:

    und das hier beim neuen Server:

    Code
    [16:44:04] Erkannte Server-Software: OpenSSH
[16:44:04] Öffne Kanal 0.
[16:44:04] Kanal erfolgreich geöffnet (Lokal=0, Entfernt=0).
[16:44:04] Subsystem "sftp" anfordern (Lokal=0, Server=0).
[16:44:04] Sending FXP initialization. Protocol version=6.
[16:44:04] SFTP Protokollversion 3
[16:44:04] Ermittle Pfad "/".
[16:44:04] Pfad wurde erfolgreich nach "/" aufgelöst.
[16:44:04] Lese Verzeichnis"/".
[COLOR="#FF0000"][16:44:04] [B]3 Permission denied[/B][/COLOR]

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

    So, also ich bin einen ganz großen Schritt weiter.

    Ein simples

    Code
    chmod 755 h20xxx.domain.net


    war die Lösung für sftp. Nur nun muss ich sehen ob der Rest noch geht, denn das vorher gesetzt 750 war von der fcgi-Installation. Ist aber dennoch seltsam, dass der Apache für fcgi mit genau dem User in das Verzeichnis schreiben / lesen kann, der sftp-User aber nicht, obwohl er der gleiche ist?!

    Ja toll. Zu früh gefreut. Wusste ich doch, dass da 750 sein musste. Mit 755 geht sftp, aber PHP nicht mehr. Suexec mag das gar nicht und sagt nur noch:

    Code
    Internal Server Error

    Das ist wirklich zum Haare ausreisen...
    /var/www/vhosts/h20xxx.domain.net braucht 750, da sonst Suexec seinen Dienst verweigert. Gleichzeitig muss es dem User gehören, auch die Gruppe.

    Im Gegensatz dazu muss die Chroot-Umgebung aber genau auf das Verzeichnis Zugriff haben. Das geht aber nur durch ein 755 oder einen Wechsel der Gruppe.

    755 ist aber wieder "Server-Fehler" durch Suexec
    Und Gruppenwechel wäre ein "Zugriff verweigert für FCGI"

    Nachtrag 2 und Kopfschüttel.. Ich sagte ja, ich stehe da wie ein Ochse....
    Ich dachte eigentlich immer, dass ein User, den man anlegt, auch automatisch seiner Gruppe angehört ??

    Also eben wieder chmod auf 755 und natürlich der Serverfehler. Dann ein "adduser wusr01 wusr01" und siehe da, der Serverfehler ist weg.

    Man muss einen User also manuell seiner Gruppe hinzufügen? Ich dachte echt immer, der wäre automatisch mit dabei *schäm*

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

    So, ich unterhalte mich mal etwas selber. Musste zwar die letzten 60 Minuten Fliesen im Keller suchen und schaue nun aus wie sau, aber das musste wohl so sein.

    Jetzt ist der User wusr01 in der Gruppe sftponly, die Berechtigungen der Verzeichnisse und Dateien entsprechend geändert. www-data ist auch in der Gruppe sftponly und in der vhost ist die SuexecUserGroup geändert. Nun scheint es zu gehen. HTML und PHP geht. SFTP scheint auch zu gehen und der User/Gruppe stimmen bei hochgeladenen Dateien auch.

    So, genug für heute... Morgen geht es weiter.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

    Hmm also suexec läuft aus sicherheitsgründen nicht immer.
    du solltest die owner Rechte prüfen
    und danach chown -R benutzer:benutzergruppe durchlaufen lassen
    ich glaube nicht das chmod dein Freund ist, denn auch da läuft bei besrtimmten Sachen etwas nicht...
    Hast du ein Control Panel, wenn ja welches?

    wenn etwas möglich erscheint mach ich das, wenn das nicht klappt gehts ans unmögliche und ansonsten das undenkbare.

    - nun stolz rauchfrei - Ich denke also Bing ich!

    Support 24h Bereitschaft 0173 6107465 - NUR Für Kunden von SEO NW!

    Zitat

    Hast du ein Control Panel, wenn ja welches?


    Ja, nennt sich Putty :)

    So wie es ausschaut - und aktuell schaut es gut aus - lag es an einer Kombination aus Gruppenrechten und SuexecUserGroup. Natürlich ist Suexec aktiv gewesen ;)

    Problem nur, dass bei Suexec eine andere Gruppe eingetragen war. Diese war auch im Dateisystem hinterlegt. Folge war, dass HTML und PHP funktionierte, SFTP aber nicht.

    SFPT brachte die Gruppe sftpuser, mit der aber FCGI nicht lief. Bei SuexecUserGroup hatte ich:
    Vhost 1: SuexecUserGroup wusr1 wusr1
    Vhost 2: SuexecUserGroup wusr2 wusr2

    Dann war ich halt am chmod, denn ein 755 brachte den SFTP zum Laufen. Allerdings ist 755 bei Suexec nicht erlaubt und er liefert Serverfehler.

    Erst nach dem Fliesensuchen kam mir die Idee, einfach die Suexec-Gruppe zu ändern, denn die Sammelgruppe für die sftpuser brauche ich ja auch (verschiedene sftp-User müssen auf den gleichen Speicherplatz zugreifen können).

    Also hab ich dann eben die vhost geändert in:
    Vhost 1: SuexecUserGroup wusr1 sftpuser
    Vhost 2: SuexecUserGroup wusr2 sftpuser

    Der User war eh schon der gleiche.
    wuser1 ist sowohl für FCGI als auch für sftp (home1)
    wuser2 ist sowohl für FCGI als auch für sftp (home2)

    Dann gibt es da aber noch einen suser1, der ist für den Datenaustausch zwischen den Servern (SCP) und muss auf home1 zugreifen und schreiben können. Da der auch der Gruppe sftpuser angehört ist das möglich.

    Dann alles Gruppen im Filesystem geändert und siehe da, es läuft. Allerdings muss ich erst testen, denn das ist komplettes Neuland für mich.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(