SSH Problem

L

Lobster

New Member
ich habe ein sehr suspektes Problem, bei einigen Kunden funktionieren die SSH Zugänge nicht :confused:
putty schließt nach Prüfung des PW sofort die Session ... ein Zugriff über SFTP ist auch nicht möglich (es wird gemeldet - nicht konfiguriert)
bei neu angelegten Kunden und auch einigen älteren klappt es problemlos
Korrektur: auch bei neuen klappt es nicht immer - VÖLLIG RATLOS - wo ist da bloß der Unterschied
! ich finde einfach nicht woran es liegen könnte !
bei den Kunden wo es nicht klappt bringt auch das löschen des ssh users und neu anlegen nichts, genausowenig wie einen weiteren enlegen...
in der shell_users Tabelle sieht alles gleich aus...
jemand eine idee ???

das Problem existierte schon vor dem Update auf 3.0.4 und jetzt immer noch :cool:
 
Zuletzt bearbeitet:
L

Lobster

New Member
Nov 12 13:56:03 srv0300 sshd[1520]: pam_unix(sshd:session): session opened for user c15ssh_test by (uid=0)
Nov 12 13:56:03 srv0300 jk_chrootsh[1560]: path /var/www/clients/client15/web78/dev/ is not owned by user 0
Nov 12 13:56:03 srv0300 jk_chrootsh[1560]: path /var/www/clients/client15/web78/dev/ is not owned by group 0
Nov 12 13:56:03 srv0300 jk_chrootsh[1560]: abort, /var/www/clients/client15/web78 is not a safe chroot jail.
Nov 12 13:56:04 srv0300 sshd[1520]: pam_unix(sshd:session): session closed for user c15ssh_test

ja, jetzt sehe ich auch den Unterschied in den Rechten
bei dieser webseite geören ALLE Ordner dem user web78 und der Gruppe client15

bei eine Seite wo es funktioniert sind diverse ordner root zugewiesen

drwxr-x--x 2 root root 4,0K 30. Okt 13:48 bin
drwxr-x--x 2 web54 client4 4,0K 30. Okt 13:45 cgi-bin
drwxr-x--x 2 root root 4,0K 12. Nov 01:15 dev
drwxr-x--x 6 root root 4,0K 30. Okt 13:48 etc
drwxr-x--x 5 root root 4,0K 30. Okt 13:49 home
drwxr-x--x 3 root root 4,0K 30. Okt 13:48 lib
lrwxrwxrwx 1 root root 4 30. Okt 13:48 lib64 -> /lib
lrwxrwxrwx 1 web54 client4 38 30. Okt 13:45 log -> /var/log/ispconfig/httpd/ads.if-20.com
drwxr-x--x 2 web54 client4 4,0K 30. Okt 13:45 ssl
drwxrwxrwx 2 web54 client4 4,0K 2. Nov 00:30 tmp
drwxr-x--x 6 root root 4,0K 30. Okt 13:48 usr
drwxr-x--x 3 root root 4,0K 30. Okt 13:48 var
drwx--x--- 13 web54 client4 4,0K 30. Okt 15:35 web

nur wie kann das kommen, wo wird das definiert ???
da fehlt ja wohl eine Aktion beim Anlegen des ssh users ???
hab leider wenig plan davon... :(
 
N

nowayback

Well-Known Member
Nov 12 13:56:03 srv0300 jk_chrootsh[1560]: path /var/www/clients/client15/web78/dev/ is not owned by user 0
Nov 12 13:56:03 srv0300 jk_chrootsh[1560]: path /var/www/clients/client15/web78/dev/ is not owned by group 0
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Das sollte dein Problem lösen:
Code: 
chown root:root /var/www/clients/client15/web78/dev/
user 0 = User: root
group 0 = Gruppe: root

Warum das bei dir nicht gesetzt wird kann ich dir leider nicht sagen. Evtl. muss dir Till da weiterhelfen.

Grüße
nwb
 
L

Lobster

New Member
schon klar, das könnte helfen (aber da sind ja noch mehr Ordner/Dateien die dann root gehören müsten)

ABER :D
nun kann ich es nachvollziehen wie es passiert
und da bist du dann bestimmt gefragt - Till

zwischen
Code: 
drwxr-xr-x 2 root  root    4,0K 12. Nov 17:12 bin
drwxr-x--x 2 web85 client7 4,0K 12. Nov 17:10 cgi-bin
drwxr-xr-x 2 root  root    4,0K 12. Nov 17:12 dev
drwxr-xr-x 6 root  root    4,0K 12. Nov 17:12 etc
drwxr-xr-x 4 root  root    4,0K 12. Nov 17:12 home
drwxr-x--x 3 root  root    4,0K 12. Nov 17:12 lib
lrwxrwxrwx 1 root  root       4 12. Nov 17:12 lib64 -> /lib
lrwxrwxrwx 1 web85 client7   42 12. Nov 17:10 log -> /var/log/ispconfig/httpd/domain.com
drwxr-x--x 2 web85 client7 4,0K 12. Nov 17:10 ssl
drwxrwxrwx 2 web85 client7 4,0K 12. Nov 17:10 tmp
drwxr-xr-x 6 root  root    4,0K 12. Nov 17:12 usr
drwxr-xr-x 3 root  root    4,0K 12. Nov 17:12 var
drwx--x--- 4 web85 client7 4,0K 12. Nov 17:10 web
und
Code: 
drwxr-xr-x 2 web85 client7 4,0K 12. Nov 17:12 bin
drwxr-x--x 2 web85 client7 4,0K 12. Nov 17:10 cgi-bin
drwxr-xr-x 2 web85 client7 4,0K 12. Nov 17:12 dev
drwxr-xr-x 6 web85 client7 4,0K 12. Nov 17:12 etc
drwxr-xr-x 4 web85 client7 4,0K 12. Nov 17:12 home
drwxr-x--x 3 web85 client7 4,0K 12. Nov 17:12 lib
lrwxrwxrwx 1 web85 client7    4 12. Nov 17:12 lib64 -> /lib
lrwxrwxrwx 1 web85 client7   42 12. Nov 17:10 log -> /var/log/ispconfig/httpd/domain.com
drwxr-x--x 2 web85 client7 4,0K 12. Nov 17:10 ssl
drwxrwxrwx 2 web85 client7 4,0K 12. Nov 17:10 tmp
drwxr-xr-x 6 web85 client7 4,0K 12. Nov 17:12 usr
drwxr-xr-x 3 web85 client7 4,0K 12. Nov 17:12 var
drwx--x--- 4 web85 client7 4,0K 12. Nov 17:10 web
wurde NUR das Passwort des ssh users geändert

insgesammt war das Prozedere

  1. admin legt Kunden an
  2. admin legt domain an und weist sie Kunden zu
  3. Kunde legt webseite an mit Auswahl der Domain aus selectbox
  4. Kunde legt ssh zugang an
  5. Kunde legt ftp zugang an
bis hier ist alles OK, aber wenn man das PW des SSH Users ändert werden die Rechte des webXX Ordners überschrieben und sind von da ab kaputt
ob es auch noch andere Aktionen gibt die das verursachen kann ich nicht sagen
__________________
wie könnte man das nun verhindern ?
wie könnte man kaputte webXX Order am besten reparieren ??
ssh löschen und alles außer folgendem löschen ??? (edit: scheint so zu klappen)
Code: 
drwxr-x--x 2 web85 client7 4,0K 12. Nov 17:10 cgi-bin
lrwxrwxrwx 1 web85 client7   42 12. Nov 17:10 log -> /var/log/ispconfig/httpd/domain.com
drwxr-x--x 2 web85 client7 4,0K 12. Nov 17:10 ssl
drwxrwxrwx 2 web85 client7 4,0K 12. Nov 17:10 tmp
drwx--x--- 4 web85 client7 4,0K 12. Nov 17:10 web
 
Zuletzt bearbeitet:
R

Rafael.K

New Member
Reparatur-Shellscript

Hallo,

ich habe hier ein passendes Reparatur-Skript für dich, welches du noch ein wenig anpassen sollst.
Es rattert alle web's durch und ändert Besitzer und Gruppe. Ausserdem kann man noch eigene Kommandos/Aktionen für web's einfügen.

Beachte bitte die Zeile mit " jails="/var/www/clients/client*/web*/bin" ... "

Code: 
#!/bin/bash
###############################################################################################
# IMPORTANT::: CHECK "Costomize" if ISPCONFIG3-SETTINGS are different from defaults
###
# Costomize only if "System" -> "Server Config" -> "Web" -> "Website path" in ISPc-UI modified.
jails="/var/www/clients/client*/web*/bin" #finds all ISPCONFIGs CHROOTs !-> some Jailkits file schould be includet in String, for example "*/bin"!!!
###
###
###############################################################################################
###############################################################################################
iter=0
for jail in ${jails[@]}
do
        if [ -e "$jail" ]
        then
                jails[$iter]=${jail//"/bin"/""}
        else
                jails=""
        fi
        iter=$((iter+1))
done
####
    for jail in ${jails[@]}
    do

        # also $jail/ ist mit jedem Durchlauf anders z.B. /var/www/clients/client1/web1/ und im naechsten ist es schon /var/www/clients/client2/web2/ usw.
        chown root:root -R $jail/bin $jail/dev $jail/etc $jail/lib $jail/usr $jail/var
        chown root:root $jail/home
        ##
        # chmod 710 $jail/xyz oder was auch immer hier eintragen
        # 
        #*V*

    done
exit 0
PS: Es löst zwar das Einloggen-Problem schon jetzt, aber die Rechte für JAILS-Executes sind immernoch falsch gesetzt. Du sollst also diese anpassen nach der "#*V*"-Zeile im Script. Poste bitte das, was du in/im Script eingefügt/geändert hast!!!

Gruß

Rafael.K
 
L

Lobster

New Member
Danke für die Mühe, aber da hätte ich doch meine Skrupel einen solchen Automatismus laufen zu lassen...

bei mir sind es zum Glück nur ein gutes halbes Dutzend webs gewesen bei denen SSH überhaupt freigegeben war und das Problem trat nur bei 4 auf da die ihr PW geändert hatten...
die hatte ich jetzt sowieso schon manuell korrigiert

  1. ssh löschen
  2. alles was in einem korrekten jailkit root zugeordet war löschen
  3. warten
  4. ssh wieder anlegen
@ Till
viel wichtiger wäre es wie kann ich es für die Zukunft verhindern ???
(hab es auch schon als Bug gepostet)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Werbung

Top