Vollwertigen Admin-Konto Ersatz

  • Habe bei mir vor dem Update auf 4.3.4 (also noch mit 4.3.3) getestet: obwohl als "Administrator" angelegt kann man per SSH kein poweroff durchführen 😐.

    Vermutlich erst, wenn der User auch in der sudoers eingetragen ist, das habe ich noch nicht getestet.

    Also ohne weitere Maßnahmen kein echter Admin.


    Gruss

  • ^ Leider die Änderungen bei sudoers ( /usr/etc/sudoers ) ist nicht permanent und bei jeder neustart wird zurückgestzt.


    Gibt es mittlerweile eine Lösung für die "Vollwertigen Admin-Konto Ersatz"?

  • Hallo und willkommen im Forum.


    Mir ist bis dato leider keine Möglichkeit bekannt.

    Es hilft nur der Workaround. Neuen User erstellen und in die Admin-Gruppe schubsen.

    Dann den integrierten Admin deaktivieren. Wenn man ihn braucht einfach wieder aktiveren.

    Schön ist zwar anders aber sonst weiß ich keine andere Lösung.

  • Den admin, root, Administrator wird es immer geben.

    Der für mich größte Knackpunkt an der der Sicherheit der QNAPS ist, dass jeder Dienst, jede App mit admin-Rechten läuft.

    Kann mich da nur anschließen.


    Meine EDV-Erfahrungen beruhen auf Apple Macintosh. Früher gab es mal Mac ohne Benutzerkonten. Erst mit Umstellungen auf OS X kam die Erkenntnis, dass es aufgrund der Struktur einen Superuser root gibt. Den kann man beim Mac seit längerem deaktivieren.
    Leider benötigen viele Qnap-Apps den admin ergo root damit die Sachen laufen. Wie damals viele Software unter Windows XP bis weiss nicht welche Version.


    Aus meiner Sicht müsste Qnap das dringend fixen!

  • Bin gerade hierüber gestolpert.

    Eigentlich geht das alles, nur ist es wegen des Qnap-Startmechanismus etwas frickeliger als unbedingt nötig. Man kann zwar das Admin-Konto weder löschen noch umbenennen, genauso wenig wie man root auf einem Unix-System oder Mac löschen kann, aber man kann komplett mit einem eigenen User auskommen, ohne sich je als Admin einloggen zu müssen.


    Vorgehen:

    1. Neuen Benutzer anlegen (sofern nicht schon vorhanden) und ihn der Gruppe der Administratoren zuweisen
    2. Diesem User alle Rechte für sudo zuweisen. Das geht wie folgt
      • Verzeichnis /usr/etc/sudoers.d anlegen
      • In dieses Verzeichnis eine Datei mit beliebigem Namen und Inhalt "mein-neuer-admin ALL=(ALL) ALL" (eine Zeile, ohne Anführungsstriche) kopieren
      • Damit dies einen NAS-Neustart überlebt, müssen die beiden Aktionen in autorun.sh ausgeführt werden
    3. Jetzt kann der admin deaktiviert werden.

    In der Web-Oberfläche wird der Admin soweit ich weiß dann nicht mehr gebraucht.


    Wenn man in der Shell Admin-Rechte braucht (kommt z. B. beim Backup vor, wenn man Verzeichnisse anderer Benutzer einsehen will), kann man dies mit sudo -i erreichen.


    Noch sicherer wird es, wenn man den ssh-Zugang ausschließlich über ssh-Keys gestattet. Dazu muss man den ssh-Dämon mit einer eigenen Konfigurationsdatei starten (geht auch über autorun.sh, ist aber etwas hakelig). Zur Konfig von ssh siehe Anleitungen (idR. für Linux). Wenn man das macht, sollte man bedenken, dass dann auch die Eintragung AllowUsers aus der neuen Konfigurationsdatei zum Zuge kommt. Nur Benutzer, die dort eingetragen sind, dürfen sich noch einloggen. Die Zugehörigkeit zur Gruppe der Administratoren zählt nicht mehr. Seit kurzem kann man dort den Admin sogar rausschmeißen (scheint Qnap korrigiert zu haben; vorher ist der ssh-Dämon sofort abgestürzt, wenn der Admin hier fehlte). Aber wenn für den Admin keine ssh-Keys (in authorized_keys) gespeichert sind, kann er sich eh' nicht mehr einloggen.


    Eine Stelle gibt es aber, wo man den admin doch noch braucht: Wenn man die Konfiguration für den ssh-Dämon zerschossen hat und dieser nicht mehr startet oder niemanden mehr einlässt, muss man sich per telnet einloggen, und das geht nur mit aktiviertem admin.