ISPConfig 3.0.4.1 Shell User funktionieren nicht

[mattula]

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

 

[Till]

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

 

[mattula]

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

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.

 

[Till]

Siehe auch hier:

FS#1945 : Authorized keys file not readable by shell user

 

[mattula]

Siehe auch hier:

FS#1945 : Authorized keys file not readable by shell user

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

 

[Till]

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.

 

[mattula]

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.

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

 

[Till]

Ich hab das nicht so aufgefasst, als ob damit der Bug schon bestaetigt waere.

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

 

[mattula]

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

 

[Till]

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.

 

[mattula]

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.

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

 

[Till]

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.

 

[mattula]

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.

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

 

[mattula]

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.

 

[Alex71]

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.

 

[Till]

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.

 

[Alex71]

Hallo Till,

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

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.

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

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.

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...

 

[Till]

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.

 

[Alex71]

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?

 

[Till]

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