Standard Admin PW ändern

[rednag]

Schon vor einiger Zeit wurde mit neuer Firmware ja das Passwort auf die MAC der ersten NIC festgelegt.
Gibt es hierzu keine Möglichkeit dieses zu ändern? Die GUI gibt hierzu nichts her? Und da QNAP ja einen Alternativen Admin haben will, bei deren Umsetzung aber derart geschlampt hat braucht man den Orginal doch hin und wieder.

 

[FSC830]

? Verstehe die Frage nicht ganz.
Du kannst doch den originalen Admin wieder aktivieren?
Und Du kannst auch das PW ändern!?

Ob man auch mit passwd das PW eines deaktivierten Users ändern kann habe ich noch nicht ausprobiert, könnte mir aber vorstellen, das das auch geht.

Gruss

 

[rednag]

Genau das geht eben nicht. Ich kann das PW für den "eingebauten" Admin nicht ändern. Zumindest nicht mit einem angemeldeten alternativen Admin. Die Funktion gibt's hierfür unter "Benutzer" schlichtweg nicht.

 

[FSC830]

Auch in der CLI probiert? Ich fahre gerade meine VM hoch...

Gruss

Edit: In der CLI geht es! In der GUI ist mir noch nicht aufgefallen, das der Button dort fehlt. Scheint auch erst in einer neueren FW der Fall zu sein.
Bei meiner NAS mit v4.3.4 ist der Button da.

 

[rednag]

Ne, über die Shell hab ich es nicht probiert. Mir unverständlich warum man sowas nicht über die GUI machen kann. Und da QNAP unfähig und nicht Willens ist, dies konsequent zu verfolgen braucht man den "eingebauten" Admin doch hin und wieder. Synology kann das. Aber gut, ich bin schon wieder still.

PS: Zum besseren Verständnis:

 

[FSC830]

Viel interessanter finde ich die Frage: wie aktiviert man den Account?
Denn da fehlt in den Eigenschaften des Benutzers die entsprechende Option!?
In der CLI kann man mit sudo passwd das Password ändern, nutzt aber nichts, wenn man den Benutzer nicht aktivieren kann.
Aber: über SSH kann ich mich trotzdem als "admin" anmelden? Bug oder Feature? Von einem deaktivierten Konto erwarte ich eigentlich, das es über alle Protokolle deaktiviert ist.

Was hat QNAP da wieder verbrochen?

Gruss

[~] # ls -lisa
total 36
 2925 0 drwxr-xr-x  2 admin administrators  240 2022-07-05 22:34 ./
    1 0 drwxr-xr-x 23 admin administrators  620 2022-07-05 22:40 ../
 2926 4 -rw-r--r--  1 admin administrators    5 2008-01-11 08:32 .bash_history
 2933 4 -rw-r--r--  1 admin administrators  175 2004-10-09 04:49 .bash_logout
 2928 4 -rw-r--r--  1 admin administrators  161 2004-10-09 04:49 .bash_profile
 2931 4 -rw-r--r--  1 admin administrators 1687 2007-07-18 12:24 .bashrc
 3846 0 lrwxrwxrwx  1 admin administrators    6 2022-07-05 22:24 .BitTornado -> ../tmp/
15111 4 -rw-r--r--  1 admin administrators   36 2022-07-05 22:34 .buzzer_warnning.conf
 2927 8 -rw-r--r--  1 admin administrators 6526 2007-07-11 11:35 index_default.html
 2932 4 -rw-r--r--  1 admin administrators   27 2007-01-29 10:47 .profile
15027 0 lrwxrwxrwx  1 admin administrators   15 2022-07-05 22:34 .ssh -> /etc/config/ssh/
13350 4 -rw-r--r--  1 admin administrators  923 2022-07-05 22:28 .vimrc
[~] # id
uid=0(admin) gid=0(administrators) groups=0(administrators),100(everyone)
[~] # pwd
/root
[~] #

 

[rednag]

Aktivieren geht schon. Der erste Menüpunkt. "Kontoprofil bearbeiten".

Von einem deaktivierten Konto erwarte ich eigentlich, das es über alle Protokolle deaktiviert ist.

Äh, ja. Das würde ich eigentlich auch erwarten. Ist schon wieder sehr schräg. Passt aber symptomisch zu QNAP.

 

[FSC830]

Au weia, das ist auch echt QNAP. Das Profil bearbeiten, dadurch wird die deaktivierung aufgehoben...
Anstatt das einfach über die Option "Dieses Konto deaktivieren" zu machen.

Gruss

 

[tiermutter]

Also ich hab ja nur Testsysteme auf denen es den richtigen admin nicht gibt (ich wüsste auch nicht warum ich den deaktivieren sollte?!?!?)...
Dort konnte ich lediglich feststellen, dass man den richtigen admin mit dem Pseudoadminaccount in der GUI aktivieren kann. Ob das PW auch durch den Pseudo-Admin geändert werden konnte ist fraglich, wäre aber nicht verdrießlich, denn wenn schon jemand auf das NAS / die GUI zugreifen kann, kennt er auch das Default-PW. Hier wäre es sinnvoll, wenn man den admin nur durch Reset an der Hardware aktivieren könnte, aber das Ziel, dass nicht jeder Furzfranz mit "admin / admin" oder "admin / 1. MAC" sein NAS offen im Netz betreibt hat QNAP damit ein Stückweit erreicht, um mehr geht es nicht.

Die Sache dass man sich über SSH trotzdem mit dem admin anmelden kann... oha... böse. Das habe ich noch nicht versucht...

 

[Barungar]

Doch kann ich bestätigen... ob der admin Account in der GUI aktiv ist oder nicht, ist dem SSH egal. War aber schon immer so.
Ein SSH Login als admin geht auch, wenn der Account "deaktiviert" ist.

Und das admin Passwort ändere ich z.B. auf der Shell... einfach nach erfolgtem SSH Login, ein kleines passwd und fertig.

 

[tiermutter]

Auch wenn das ziemlicher Mist ist, hat QNAP das eigentliche Ziel ja dennoch erreicht:
Über HTTP(S), was ja zumeist ausm WAN zugänglich gemacht wird, kann der admin nicht verwendet werden.
Über SSH, was meist ja nicht ausm WAN zugänglich gemacht wird, geht es dennoch, was besonders hilfreich ist wenn die Problemlösung hier erfolgen muss.
Schöner wäre sicherlich, wenn der Pseudo-Admin ein richtiger Admin wäre statt so ein halbberechtigtes Wesen...

 

[Barungar]

Der "admin" ist ein richtiger Admin.. auf der Shell hat er UID 0... was man landläufig als "root" bezeichnet.

 

[rednag]

Ob QNAP hier das Ziel erreicht oder nicht ist nun nebensächlich.
Ich finde es äußerst schräg wenn sich ein gesperrter User per SSH anmelden kann.
Das sollte und dürfte nicht sein. Weder vom WAN noch Intern. Für was gibts denn dann die Möglichkeit den User zu sperren überhaupt?

PS: Wenn man das PW per passwd über die CLI ändert sind diese Änderungen persistent und überleben auch ein Ausschalten als auch ein Reboot? Bei QNAP ist das ja auch nicht sicher.

 

[FSC830]

Das ist bootresistent, garantiert, sonst müsste ich jedesmal wieder das PW ändern.
Und der SSH Login trotz Deaktivierung geht nur beim "admin", bei einem selbst angelegten User greift die Sperre auch für SSH, zumindest bei mir.

Gruss

 

[Barungar]

Der "admin" ist und bleibt UID 0, also "root". In der Unix-Philosophie ist das der "Gott des Systems".
Ich frage mich, weil ich es auch noch NIE probiert habe, kann man den Root Account auf Linux/Shell-Ebene sperren?!
Ich denke nicht.

Man kann maximal im SSH-Dämonen ein "PermitRootLogin" auf no setzen. Das sperrt aber ja nicht den User, sondern weißt SSH an, keinen Login der UID 0 zuzulassen.

Klar gibt es noch dreckige Tricks, das man dem User in der passwd keine gültige Shell zuweist. Aber auch das ist "kein Sperren" des Users, sondern strenggenommen ein bewusstes "falsch konfigurieren" der Shell für diesen User.

 

[rednag]

Die Umsetzung einen alternativen Admins ist bei QNAP aber einfach nur grottig. Eben erst weder im anderen Forum gehabt. PMA funktioniert nicht mit einem anderen Admin. Dafür braucht man den Orginal. Und warum soll ich mir die Mühe machen durch Trial&Error rauszufinden was den Orginal braucht? Da arbeite iich doch gleich mit dem. Ganz große Klasse. Gut gemeint ist bei QNAP aber ungleich Gut gemacht.

 

[tiermutter]

Ich habe bis heute auch keinen Grund gesehen mich vom admin zu verabschieden... Im Gegenteil... Seit 5.0 Beta schimpfe ich ja schon darüber und dass es auch noch einen Unterschied des Verhaltens gibt, je nachdem ob man den 5er oder 4er Kernel hat...

 

[rednag]

dass es auch noch einen Unterschied des Verhaltens gibt, je nachdem ob man den 5er oder 4er Kernel hat...

Ach, hier gibts auch wieder Unterschiede?

 

[tiermutter]

Ja, aber ich weiß nicht ob das mittlerweile anders ist... Anfangs war es so, dass der Pseudo Admin eines Kernel mehr Rechte hatte als beim anderen Kernel.

... Was natürlich auch im Kernel selbst begründet sein könnte...

 

[rednag]

Die Kisten werden mehr und mehr zu einem BlackHole. Das Verhalten kennt man nicht, weiß es nicht und kann es nicht nachvollziehen.
Die Dinger werden vermutlich nur für die Mitarbeiter bei QNAP gebaut. Die Logik welche dahintersteckt blickt doch keiner. Der Vertrieb ist nur eine Randerscheinung des ganzen.