SSH und Userrechte

    Wenn man einem User SSH rechte geben möchte (bei mir jetzt ein managed System) ist der SSH Zugang durch die neue Rechtestruktur doch recht limitiert. Editoren oder auch MC bringen immer wieder Fehlermeldungen das keine Schreibrechte vorliegen um Ihre Einstellungen zu speichern.


    Soweit ich sehe ist die einzige Möglichkeit den Besitzer des Webroot Ordners auf den dazugehörigen Vertragsuser zu ändern. Dann klappt soweit auch alles. Nur läuft scheinbar hin und wieder da "lcservice.sh" und korrigiert diese Rechte wieder.


    Wann genau läuft eigentlich dieses Korrekturscript? Und gibt es vielleicht noch eine bessere Möglichkeit für SSH User. Weil damit hatte ich bis jetzt noch auf keinem anderen System (cpanel, plesk, directadmin usw.) Probleme.

    Zitat von bfal

    Soweit ich sehe ist die einzige Möglichkeit den Besitzer des Webroot Ordners auf den dazugehörigen Vertragsuser zu ändern.


    NEIN - das sollten Sie besser nicht machen, da das erhebliche Sicherheitsrisiken mit sich bringt. Unter anderem kann der Benutzer dann direkt in der Apache-Konfiguration herumpfuschen indem er eine ~/.httpd.conf anlegt, er kann alle PHP-Einstellungen ändern (indem er ~/conf umbenennt und ein eigenes ~/conf/-Verzeichnis anlegt), usw...


    Damit einzelne Anwendungen im Home-Verzeichnis schreiben dürfen, legen Sie die entsprechenden Verzeichnisse/Dateien als "Dummy" an und geben dem Kunden dafür Schreibrechte, z.B.:

    Code
    touch .viminfo .vimrc
chown web##:web## .viminfo .vimrc


    Viele Grüße


    -Klaus Keppler

    Die Risiken hierbei sind mir bewusst....und in dem einen Fall geht es um einen guten Freund weshalb das tragbar wäre.
    Generell ist das vor anlegen zumindest für die häufig genutzten Programme denkbar....aber das möchte ich ja nicht jedes mal per Hand machen. Außerdem kann dies natürlich auch zum "zumüllen" führen da nicht jeder User alle Programme nutzt.


    Insgesamt finde ich das momentan recht schlecht gelöst...meiner Meinung nach. Ich habe schon überlegt ob ich dies vielleicht mit ACLs abfangen kann....aber das muss ich noch mal näher schauen.

    Wir machen das ja auch nicht, weil wir die Benutzer übermäßig einschränken möchten, sondern weil es schlicht nicht anders geht ohne massiv in das System einzugreifen.
    Für eine sichere Hostingumgebung (suexec/suphp) ist es unumgänglich, dass das Home-Verzeichnis entweder dem Kunden oder "root" gehört. Dem Kunden kann man das nicht übereignen, da sonst o.g. Sicherheitsprobleme auftreten - bleibt also nur die Variante mit "root".
    Eine Alternative würde darin bestehen, die komplette Verzeichnisstruktur aufzudröseln und alle nicht Webspace-relevanten Daten (Logfiles, Statistikdateien, Konfigurationsdateien usw. - praktisch alles außer "apps" und "htdocs") in andere Verzeichnisse zu verschieben. Das bringt dann aber auch wieder andere organisatorische Nachteile mit sich.
    So bleibt es letztendlich also ein Kompromiss aus Sicherheit und Komfort, wie die Verzeichnisse organisiert sind.

    Ja ich kann beide Seiten verstehen......ich habe jetzt ein Super Kompromiss gefunden welcher scheinbar, zumindest unter Debian, recht gut funktioniert.


    Ich habe einfach eine ".profile" ins Homedirectory gepackt mit folgenden Inhalt:


    Code
    HOME=~/priv
HISTFILE=~/.bash_history
export HOME
export HISTFILE


    Somit biege ich damit den Homeordner und das Bash History file auf den PRIV Ordner um. MC z.B. legt seinen ".mc" Ordner dann dort ab.
    Ich muss noch weiter testen aber zumindest konnte ich aktuell keine Seiteneffekte feststellen. Die Berechtigungen können dann bleiben wie Sie sind und da die ".profile" nicht dem User gehören muss ist hier auch kein Eingriff seitens des Users möglich.

    Kleiner Tipp, es ginge auch so :) (etwas kürzer)


    Code
    export HOME="${HOME}/priv" HISTFILE="${HOME}/priv/.bash_history"


    Code
    $ echo "${HOME} ${HISTFILE}"
/var/www/web1/priv /var/www/web1/priv/.bash_history

    Klasse, da soll mal einer behaupten das die "Community" bei der gestaltung eines Produkts wie LiveConfig nicht mitreden kann :D

    - LiveConfig 1.6.0-r2052 (Inaktiv) :: BETA: 1.6.1 - r2142 (Inaktiv)
    [HR][/HR] - CentOS 6.3 x64[HR][/HR]- Apache 2.2.15 - PHP 5.4.12* - mod_suphp 0.7.1** - MySQL 5.5.30*
    - Postfix 2.6.6 - dovecot 2.0.9 - Clamd 0.97.6** - clamav-milter 0.97.6**- postgrey 1.34**
    - vsFTPd 2.2.2 - AWStats 7.0**
    * Aus dem REMI-Repository :: ** Aus dem rpmforge-Repository

    Ich sollte dafür eigentlich /etc/skel einsetzen können, aber leider hat Liveconfig anscheinend nicht den Standard useradd benützt.


    Ich würde bevorzugen zurück zu kehren zum Standard mit Benutzerverzeichnis in /home/ und benützung van useradd um die Behauptung "Minimalinvasiv" wieder wahr zu machen.

    Zitat von ñull

    Ich sollte dafür eigentlich /etc/skel einsetzen können, aber leider hat Liveconfig anscheinend nicht den Standard useradd benützt.


    Ich würde bevorzugen zurück zu kehren zum Standard mit Benutzerverzeichnis in /home/ und benützung van useradd um die Behauptung "Minimalinvasiv" wieder wahr zu machen.


    Ich nicht - obwohl ich auch gerne SSH vernünftig hätte. Aus einem einfachen Grund: Sobald ich einen User in /home/user habe und seinen Vertrag dann in /var/www/user - müsste ich ja jedes Mal da hinein wechseln, wenn ich mich einlogge. Das finde ich überhaupt nicht benutzerfreundlich, ob minimalinvasiv oder nicht.


    Stattdessen sollte IMHO LiveConfig seine eigene Version von useradd implementieren, die den Inhalt von /etc/skel in das priv-Verzeichnis integriert und dann die beschriebene .profile anlegt. Das müsste in Lua eigentlich möglich sein.


    Denn was ich unter diesen Umständen als Server-Admin noch machen würde, wäre, den Zugriff auf das restliche System noch deutlich einzuschränken. Will sagen "chmod o-rwx /proc /sys && chmod o-r /etc" und solche Sachen. SSH-User sollten nicht ziellos auf dem halben System herumlaufen können und eigentlich außerhalb des Webroots nichts sehen.


    Allerdings: Ein Fan von chroot bin ich überhaupt nicht, das gibt nur Symlink-Chaos mit den ganzen Shared Objects - so wie bei Confixx & Co. Und bei einem Paketupdate steht man dann da.

    Diese Lösung ist auch nicht vollkommen. Ich habe gerade bemerkt dass noch immer "mc" seine datei im vorherige home abspeichern will:

    Zitat

    echo "${HOME} ${HISTFILE}"
    /var/www/web1/priv /var/www/web1/priv/.bash_history
    mc
    Cannot create /var/www/web1/.local/share/mc directory

    Für "mc" braucht man etwas mehr:


    Code
    export HOME="${HOME}/priv" HISTFILE="${HOME}/priv/.bash_history" XDG_CONFIG_HOME="${HOME}/priv/.config" XDG_CACHE_HOME="${HOME}/priv/.cache"  XDG_DATA_HOME="${HOME}/priv


    Viel zeit verloren das herauszubekommen. Die Reparaturarbeit wird daher immer größer weil wir abgewichen sind von den Linux Standardverfahren. Konfigurationsdateien sollten in /etc bewahrt werden und der User sollte in seine Home schreiben können.


    Mehr Information über XDG Variablen findet man hier.

    ... eine kleine Änderung in /usr/lib/liveconfig/lua/users.lua :


Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden