ISPConfig 3.0.4.1 Shell User funktionieren nicht

Dieses Thema im Forum "Installation und Konfiguration" wurde erstellt von mattula, 16. Dez. 2011.

  1. mattula

    mattula Member

    Es ist total seltsam. Ich habe zwei unabhaegige ISPConfig Installationen.
    Bei der ersten scheint alles zu funktionieren.

    Bei der zweiten funktionieren z.B. die Shell User nicht weder mit noch ohne Jailkit.

    Fehler im auth.log ist:
    sshd[5720]: debug1: temporarily_use_uid: 5004/5007 (e=0/0)
    sshd[5720]: debug1: trying public key file /var/www/clients/client7/web5/.ssh/authorized_keys
    sshd[5720]: debug1: Could not open keyfile '/var/www/clients/client7/web5/.ssh/authorized_keys': Permission denied

    Fakt ist, das ist tatsaechlich alles nur fuer root lesbar:

    ls -la /var/www/clients/client7/web5/.ssh/
    -rw------- 1 root root 2563 Dec 16 13:54 authorized_keys


    Vergleiche ich mit meiner ersten ISPConfig Installation, dann werde dort Berechtigungen folgendermassen gesetzt:
    -rw------- 1 web3 client1 1622 23. Nov 17:06 authorized_keys

    Dort funktioniert somit auch der SSH Login.

    Zum Setup des zweiten System muss ich sagen, es ist ein Cluster Setup.

    /var/www, /var/lib/mysql und andere Dinge liegen auf einem gemeinsamen NFS Share und sind von dort per Symlink eingehaengt. Konfig wird grossteils per Csync2 synchronisiert.

    Irgendwelche Ideen, was da schief laeuft.
    Ich habe auch testweise schon /var/www wieder lokal kopiert - keine Aenderung am Verhalten

    Gruss,
    Matthias
     
  2. Till

    Till Administrator

    Welche ISPConfig Version verwendest Du? Sind die Rechte der anderen Verzeichnisse und Dateien des Webs in Ordnung?
     
  3. mattula

    mattula Member

    Version 3.0.4.1

    Die uebergeordneten Berechtigungen scheinen zu stimmen, d.h. z.B:
    /var/www/_DOMAIN_/home/_USER_/
    drwxr-xr-x 3 web5 client7 4096 Dec 16 14:44 _USER_

    Aber das .ssh Verzeichnis unterhalb sieht dann so aus:

    drwxr-xr-x 2 root root 4096 Dec 16 14:44 .ssh
    -rw------- 1 root root 1214 Dec 16 14:44 authorized_keys

    Und das ist die Krux, mit 600 fur root auf authorized_keys darf nunmal niemand anderes diese Datei lesen.
     
  4. Till

    Till Administrator

  5. mattula

    mattula Member

    Ok, ich habe es nun nocheinmal mit einer Neuinstallation probiert.
    Debian Squeeze, aktuelles Releaselevel, *kein* Cluster, *kein* NFS, also alles lokal. ISPConfig 3.0.4.1 Installation im Expert Mode durchlaufen lassen.

    Wieder das gleiche Phaenomen:

    Shell User angelegt mit Jailkit und:

    # /etc/passwd
    testfsmwtest:x:5004:5005::/var/www/clients/client2/web1:/bin/false

    ls -la /var/www/clients/client2/web1/.ssh/
    total 12
    drwxr-xr-x 2 root root 4096 Dec 30 10:59 .
    drwxr-xr-x 14 root root 4096 Dec 30 10:59 ..
    -rw------- 1 root root 1214 Dec 30 10:59 authorized_keys


    Damit gibt es beim SSH Connect ein: Permission denied (publickey).

    gruss,
    Matthias
     
  6. Till

    Till Administrator

    Warum hast Du denn neu installiert? Steht doch im Bugreport dass es in der 4.0.1 nicht geht da die Rechte nicht stimmen, wird in 3.0.4.2 gfixt.
     
  7. mattula

    mattula Member

    Na ja, im Bugreport stand ein Satz. Ich hab das nicht so aufgefasst, als ob damit der Bug schon bestaetigt waere.
    Aber die Neuinstallation war sowieso angesagt, da es im Cluster mit NFS und versymlinkten Verzeichnissen auch noch andere Probleme gibt und wir jetzt erstmal eine saubere Basisinstallation moechten, bevor es ans Clustern geht.

    Btw, es stimmen nicht nur die .ssh/authorized_keys Berechtigungen nicht, sondern die vom ganzen User-Home sind falsch.

    Matthias
     
  8. Till

    Till Administrator

    Status ist new und nicht unconfirmed, also ist er bestätigt.
     
  9. mattula

    mattula Member

    Hi Till,

    ich hab mir mal angeschaut, was sich zw. 3.0.4 und 3.0.4.1 geaendert hat und dabei zwei Stellen gefunden, die in 3.0.4 noch aktiv und in 3.0.4.1 auskommentiert sind, die mit den Home Permissions zu tun haben:

    server/plugins-available/shelluser_base_plugin.inc.php Zeile 276
    und
    server/plugins-available/shelluser_jailkit_plugin.inc.php Zeile 445:

    An beiden Stellen wird (bzw. sollte) ein chown ausgefuehrt werden.

    Ich habe in beiden Dateien die jeweilige Zeile mal aktiviert und nun lassen sich wieder Shell User anlegen, bei denen die Berechtigung zu stimmen scheint. Zumindest funktioniert so auf Anhieb ein Login per SSH *und* der User kann tatsaechlich auch im eigentlichen Webhome lesen und schreiben.

    Ob nun irgendwas anderes nicht so ist, wie es sein soll, kann ich auf die Schnelle nicht sagen. Ich werde weiter testen und die Version 3.0.4.1 voraussichtlich mit diesem Patch (*) in Betrieb nehmen.

    (*) siehe angehaengte Patch Datei


    Gruesse,
    Matthias
     

    Anhänge:

  10. Till

    Till Administrator

    Die Zeilen müssen auskommentiert sein, denn sie zerstören das komplette jailkit jail so dass nach dem nächsten Update des users kein login mehr möglich ist. Schau mal ins svn stable, da ist der Bug bereits richtig gepatcht.
     
  11. mattula

    mattula Member

    OK, danke. Du meinst mit stable den Branch hier?
    svn://svn.ispconfig.org/ispconfig3/branches/ispconfig-3.0.4/

    Empfiehlst es sich gleich den ganzen Branch zu nehmen, oder sollte ich erstmal nur die beiden shelluser Scripte ersetzen?

    gruss,
    Matthias
     
  12. Till

    Till Administrator

    Ich würde Dir raten den ganzen Branch mit:

    svn export svn://svn.ispconfig.org/ispconfig3/branches/ispconfig-3.0.4/

    herunterzuladen und dann das update.php script im install Verzeichnis auszuführen, dann hast Du auch gleich die Bugfixes für die Webseitenrechte mit dabei. Die Dienste müssen nicht rekonfiguriert werden.
     
  13. mattula

    mattula Member

    Super. Danke. Hat geklappt - bin schon wieder am Testen.
    gruss,
    Matthias
     
  14. mattula

    mattula Member

    SSH Benutzer anlegen mit und ohne Jailit funktioniert jetzt.
    Die Berechtigungen scheinen auch soweit zu passen.
    Ebenso das Zusammenspiel auf Verzeichnis- und Dateiebene von FTP, SSH mit und ohne Jailkit Benutzern.
    Sehr schoen. :)
     
  15. Alex71

    Alex71 New Member

    Update auf 3.0.4.2: Neue Shell User funktionieren nicht

    Hallo,

    ich habe heute per Shell-Script ein Update auf 3.0.4.2 durchgeführt. Vorher hatte ich 3.0.4.1 laufen, habe dort aber keine neuen Shell User angelegt und weiß daher nicht, ob das Problem schon in 3.0.4.1 bestand. Es gab aber bereits Shell User vor der Aktualisierung auf 3.0.4.1.

    Nun das Problem:

    Die alten Shell User funktionieren Einwandfrei; wenn ich aber nun einen neuen Shell User anlege, so wird die Verbindung mit dem Hinweis "Server refused our key" abgelehnt. Chroot oder nicht ist egal; auch wenn ich die Dateirechte denen der funktionierenden Shell User anpasse (.SSH: client*:web* 0755 / authorized_keys: root:root 0644), komme ich einfach nicht weiter.

    Über einen hilfreichen Tipp würde ich mich extrem freuen - ach ja: ISPConfig läuft auf OpenSuSE.
     
  16. Till

    Till Administrator

    Die Shelluser funktionierten in 3.0.4.1 nicht richtig, das Problem wurde in 3.0.4.2 behoben. Es kann aber sein dass User die mit 3.0.4.1 erstellt wurde davon weiterhin betroffen sind. Ich würde Dir raten den Shelluser mal zu löschen und dann neu anzulegen.

    Ein häufiger Grund für den Fehler "Server refused our key" ist ein falsch formatierter key, wenn z.B. Zeilenumbrüche drin sind oder die Domain des Keys falsch ist.
     
  17. Alex71

    Alex71 New Member

    Hallo Till,

    zunächst einmal vielen Dank für die schnelle Antwort. Leider bin ich noch nicht viel weiter...

    Ich habe aus Verzweiflung inzwischen den ganzen Kunden gelöscht und neu angelegt. Das wäre also schon mal ausgeschlossen.

    Um dies auszuschließen, bin ich bisher (und so auch in diesem Fall) so vorgegangen, dass ich die Datei "authorized_keys" von einem "funktionierenden" Kunden kopiert und dann die richtigen Dateirechte im neuen Kunden gesetzt habe. Ich muss dazu sagen, dass ich SSH nur für mich als Admin anlege und daher das File "authorized_keys" bei allen von mir administrierten Kunden gleich aussieht.

    ALLERDINGS:
    Ich bin, nachdem ich das Prozedere heute nochmal durchlaufen habe (Kunde löschen und alles neu anlegen), auf folgende Fragestellungen gestoßen:


    1. Wenn ich einen SSH-User anlege und das Feld für die Signatur leer lasse, wird offensichtlich ein authorized_keys-File mit dem File des Users root beim Kunden angelegt - soll das so sein?
    2. Bei diesem neuen Kunden ist mir aber noch etwas viel Interessanteres aufgefallen, was wahrscheinlich Kern des Problems ist: irgendwie verwendet der neue Kunde "komische" UIDs - normalerweise sollte die UID bei Gruppe und Eigentümer doch eigentlich identisch sein; bei den bisherigen Kunden ist das auch so, also z. B. client16 [5012] / web19 [5012]. Bei meinem neuen Kunden weicht die UID jedoch ab, sieht also so aus: client26 [5021] / web45 [5019]. Ein kurzer Blick per Yast in die "User and Group Administration": eine UID 5021 existiert dort nicht.
    Das Problem scheint also schon bei der Anlage des Kunden kräftiog Anlauf zu nehmen... :(
     
  18. Till

    Till Administrator

    1) ja, das soll so sein, damit sich der root user auch mit anderen accounts einloggen kann.

    2) uid und gid hängen nicht zusammen, können also unterschiedliche ids haben. Wenn es die uid nicht gibt, dann konnte ispconfig den user nicht anlegen. Wie men sowas debuggen kann, steht im ispconfig faq.
     
  19. Alex71

    Alex71 New Member

    Soweit erstmal besten Dank für die Infos. Ich habe mir also die entsprechende FAQ zu Herzen genommen und getan was man mir auftrug. Allerdings sehen die Ausgaben nicht so aus, als könnten sie helfen:

    Kunde angelegt, Script ausgeführt:
    which: no tw_cli in (/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin)
    --> diese Meldung soll laut "allwissender Müllhalde" unkritisch sein, richtig?
    /usr/bin/fail2ban-client
    /sbin/iptables
    /usr/sbin/ip6tables
    finished.

    Domain beim Kunden angelegt, Script ausgeführt:
    Syntax OK

    Shell-Benutzer angelegt:
    finished.

    Kunde gelöscht, Script ausgeführt
    groupdel: GID `5022' is primary group of `web46'.
    groupdel: GID `5022' is primary group of `test4711shell'.
    groupdel: Cannot remove user's primary group.
    no crontab for test4711shell
    no crontab for web46
    finished.

    Die Große Preisfrage lautet also:
    Was kann ich nun noch tun?
     
  20. Till

    Till Administrator

    Poste bitte die kompletten und vollständigen Debugmeldungen, die Du auf der Shell beim ausführen vom server.sh Script erhalten hast.
     

Diese Seite empfehlen