[Problem] Root-Login per Telnet oder Dropbear nach Freetz update auf Fritz!OS 7.25 nicht mehr möglich!?

[DHU]

Hallo Allerseits,

habe gerade mein Fritz!Box mit freetz-ng von 7.2x auf die 7.25 gebracht. Vorher kam ich per Telnet bzw. ssh login auf die Fritz!Box.
Aber momenan scheint es so, dass der root login garnicht funktioniert und einen anderen Benutzer habe ich nicht angelegt.
Passwot ändern via Rudi-Shell habe ich durchgeführt, aber hat auch keine Änderung herbeigeführt.
Mit folgenden Befehl habe ich das Passwort in /etc/shadow geändert, aber Login ist nicht möglich
(echo BlaBli; sleep 2; echo BlaBli) | passwd

/etc/paaswd ->
root:x:0:0:root:/mod/root:/bin/sh
/etc/shadow ->
root:1CMUEO6C0eB9M:18700:0:99999:7:::

Die Einträge /bin/sh und /mod/root habe ich auch schon auf Vorhandensein und Zugriffsrechte überprüft.
Nähere untersuchen fallen auch schwer, da die Rudi-Shell doch beschwerlich ist, gab es eine Änderung die ich nicht mitbekommen habe?

Danke, Dirk

 

[PeterPawn]

Schnittstellen für Entwickler | AVM Deutschland

Schnittstellendokumentation für Entwicklungen im FRITZ!Box-Umfeld

avm.de

 

[DHU]

O.K: Habe ich jetzt gelesen, den Neuen Benutzer fritzxxxx habe ich rausgefunden, wenn ich mich mit diesem Benutzer per Telnet oder SSH einlogge bekomme ich "Access denied".
Den Benutzer gibt es auch nicht in /etc/passwd oder /etc/shadow
Aber diese Änderung betrifft eher das Web-Interace. Die Anmeldung darüber klappt zum Glück mit dem alten Passwort!

 

[gismotro]

Bei mir nimmt er root weder bei telnet noch beim AVM-Ftp

 

[PeterPawn]

Daß es hier um die Linux-Accounts geht, war ja zu dem Zeitpunkt, wo ich #2 schrieb, noch nicht zu erkennen - da gab es den Teil mit der etc/passwd noch nicht. Und bei der Verwendung von ar7login sind dann auch weiterhin die AVM-Accounts diejenigen, gegen die man sich authentifizieren kann/muß - wenn man überhaupt einen SSH-Server mit Password-Authentifizierung gestartet/verwendet hat.

Ansonsten muß man aber weiterhin raten, was denn nun "SSH-Login" wohl heißen mag (es gibt ja Pakete für Dropbear UND für OpenSSH) und auch die Info, wie der Telnet-Daemon letztlich gestartet wird (denn da gibt man ja i.d.R. ein login-Programm an, was dann die Credentials abfragt und validiert), fehlt für ein gezielteres Raten. Denn beim Dropbear gäbe es dann z.B. ja auch noch die Option -w, die auch eine Anmeldung als root verhindert (afaik) und auch die Option -g sollte man dann ja eher nicht verwenden. Aber vielleicht ist es ja auch gar kein Dropbear, der hier Probleme macht ... nur woher soll man das wissen?

Wobei sicherlich auch ein Protokoll des Anmeldeversuchs nichts schaden würde - üblicherweise kann man sogar den meisten SSH-Clients noch den Auftrag geben, den Handshake mit dem Server ausführlicher zu protokollieren ... vielleicht ist am Ende gar nicht der zu verwendende Account, sondern der zu verwendende Crypto-Algorithmus schuld und die beiden (Client und Server) verstehen sich deshalb gar nicht erst, so daß es tatsächlich nie zum Validieren des Accounts kommt.

Auch da sind dann natürlich meistens die "echten" Fehlernachrichten "sprechender" ... das "access denied" aus #3 wäre ja (wenn man tatsächlich gegen die /etc/passwd bzw. /etc/shadow authentifizieren will) zu erwarten, denn AVM trägt in die /etc/passwd ja nicht die Benutzernamen aus dem GUI ein, sondern Benutzernamen nach dem Schema boxusrXX, wobei das XX für die Benutzernummer aus der ar7.cfg steht.

Ich würde nicht mal mehr darauf Wetten abschließen, daß die verwendete C-Library tatsächlich noch das alte (und längst vergessene, weil absolut unsichere) CRYPT-Verfahren für das Kennwort verwendet oder auch nur verstehen kann - auch in Freetz-NG wird ja ganz offensichtlich MD5 verwendet: https://github.com/Freetz-NG/freetz-ng/blob/7eaea5533207d3709c82c5bba2ce40fae6b7dd75/fwmod#L1107 und die von AVM in die /etc/passwd eingetragenen Konten verwenden sogar SHA-512 (Algo-ID 6). Was genau ist

/etc/shadow ->
root:1CMUEO6C0eB9M:18700:0:99999:7:::

das hier also?

Man könnte zwar anhand von #1 auch erraten, daß es sich um ein Update handelt(e) und die Freetz-Settings noch die von der 07.2x sind - aber so richtig klar und deutlich, steht das da auch nicht.

Was würde Dich eigentlich davon abhalten, da einfach wieder auf die vorhergehende Version zu wechseln und bei der dann einfach auf den ganzen Kennwort-Quatsch zu verzichten und stattdessen eine (ordentliche) Authentifizierung über ein Schlüsselpaar zu konfigurieren? Die sollte dann auch nach dem Wechsel auf die 07.25 funktionieren - wobei immer noch nicht so ganz klar ist, warum es hier (abseits der Änderungen durch AVM, die ja von Dir als "hier nicht zutreffend" aussortiert wurden) überhaupt einen Unterschied zwischen 07.21/07.22 und 07.25 (in diesem Punkt) geben sollte.

 

[DHU]

Es betrifft telnet und dropbear und es schein es hat nichts mit der Authentification zu tun,
sondern das ein automtisches exit oder soetwas passiert und zwar bei root oder einen anderen user:
Welcome at fritz.box

_____ _ _ _ ____
| ___| __ ___ ___| |_ ____ | \ | |/ ___|
| |_ | '__/ _ \/ _ \ __|_ /____| \| | | _
| _|| | | __/ __/ |_ / /_____| |\ | |_| |
|_| |_| \___|\___|\__/___| |_| \_|\____|

Und das ist die letzte Ausgabe und dann bin ich wider draußen!
Wie kann ich den die Authentification von telnet umstellen,von passwd auf ar7?

 

[PeterPawn]

Wenn Du den Telnet-Daemon über den telefon-Daemon von AVM starten läßt (auch in Freetz-NG gibt es passende Patches und soweit ich weiß, hat @cuma das auch für die 07.25 schon auf CONFIG_BUILDTYPE umgestellt), benutzt der automatisch die AVM-Accounts - wenn es der über Freetz gestartete ist, gab's da (aus der Erinnerung, ich will gerade nicht nach der Stelle suchen) auch die Option, den über den AVM-Weg zu starten. Wenn das nicht der Fall sein sollte oder nicht funktioniert, bräuchte es die Option -l /sbin/ar7login als Zusatz für den Telnet-Start - ich weiß aber auch gerade nicht (mehr) sicher, ob man dem Daemon bei Freetz noch weitere Optionen mit auf den Weg geben kann/konnte.

Ich habe aber mittlerweile auch eine Diskussion im Repo von Freetz-NG gesehen, wo es anderen wohl ebenso ergeht - da hat zumindest jemand mal versucht, ein Image mit dem Telnet-Start über die AVM-Telefoncodes zu bauen und ist erst dann gescheitert, als er bei diesem Daemon weiterhin root als Benutzernamen verwenden wollte: https://github.com/Freetz-NG/freetz-ng/discussions/224

Man muß sich also an das Problem herantasten ... ich würde Dir aber raten, Dich dann auch eher an den GitHub-Thread zu hängen (Account hast Du ja ohnehin), damit man das nicht an zwei Stellen fortsetzen muß.

 

[DHU]

Mit einem 7.21 image klappt das login auch nicht, d.h. es hat sich in den letzten 4 Monaten etwas an Freetz verändert, was das Problem hervorruft.

 

[B612]

Hast du auch deine Konfig von der 7.21 wieder eingespielt? Oder Werksreset gemacht? Durch deinen Ausflug in die 7.25 wurde da einiges verändert.

 

[DHU]

Ja die 7.21 Konfig habe ich auch wieder zurückgespielt, aber keine Änderung.

Klappt den bei anderen der Telnet Zugang bzw. Dropbear Zugang zur Freetz!Box mit dem 7.25 Freetz und von wann war das letzte Update?

 

[FischersFreetz]

Das beantwortet zwar nicht deine letzte Frage, aber vielleicht helften dir auch folgende Informationen etwas:

Mit einem 7.21 image klappt das login auch nicht,...

Ich kann mich unter Freetz-NG mit FW 7.21 via Dropbear auf der Box anmelden (telnet habe ich nicht ausgewählt).

... d.h. es hat sich in den letzten 4 Monaten etwas an Freetz verändert, was das Problem hervorruft.

Es hat sich sicherlich etwas an Freetz-NG in dieser Zeit verändert. Aber deine Schlussfolgerung finde ich nicht zwingend. Ich habe mein Image vor ca. 2 Tagen gebaut (Freetz-Version: freetz-ng-18140M-7eaea5533) und damit klappt es ja via Dropbear.

 

[PeterPawn]

Wie bereits im GitHub-Repo geschrieben, hat sich die Implementierung von crypt() in der 1.0.37 der uClibc-ng geändert. Da wohl nur die Authentifizierungen betroffen sind, die diese Funktion zum (erneuten) Hashen des zu prüfenden Kennworts nutzen (und hier offenbar auch nicht bei allen Freetz-Benutzern), lohnt sich da zumindest mal ein Blick.

Wer tatsächlich aktuell von diesem Problem reproduzierbar betroffen ist (einige haben in ihrem Bestreben, für sich selbst einen Workaround zu finden, dann die Daten ja auch gleich wieder mit neuen überschrieben), der kann ja mal die Zeile: https://elixir.bootlin.com/uclibc-ng/latest/source/libcrypt/crypt.c#L30 auskommentieren und dann ein neues Image bauen lassen - allerdings inkl. Neubau der C-Library, was (neben dem gcc) so ziemlich der umfassendste Build ist, den man ausführen kann und vielleicht sollte man dafür sogar die Download-Toolchains deaktivieren, weil ich nicht sicher bin, was @cuma da noch geändert hat. Das ist also nur etwas für "Hardcore-Benutzer", die gleichzeitig zur Fehlersuche beitragen wollen.

 

[DHU]

Crypt.cL30 war kein Problem, aber seit neuer Zeit wird in der Busybox
FREETZ_BUSYBOX_FEATURE_NOLOGIN=y
FREETZ_BUSYBOX___V132_FEATURE_NOLOGIN=y
FREETZ_BUSYBOX_FEATURE_SECURETTY=y
FREETZ_BUSYBOX___V132_FEATURE_SECURETTY=y
gesetzt, woher diese Abhängigkeit kommt, habe ich noch nicht herausgefunden.

 

[PeterPawn]

Hatten wir ja dann alles im GitHub-Repo von Freetz-NG weiter diskutiert ... und da dann auch eine/ein paar Lösungen gefunden: https://github.com/Freetz-NG/freetz-ng/discussions/224

 

[zwierbel]

Habe da ein kleines Problem mit einem 7.50er freetz image und der telnet Authentificatation. Kann mich mit telnet nicht anmelden obwohl das Passwort zu 100% richtig ist. vsftp root login klappt ohne Probleme. Habe das root Passwort entfernt, jetzt klappt der root Zugriff auch über telnet. Danach ein neues Passwort mit "passwd" gesetzt und wieder das gleiche Problem. Vsftp akzeptiert das neue Passwort, telnet tut es nicht.

Irgend jemand eine Idee woran das liegen könnte?

 

[WileC]

Hallo, ich habe das selbe Problem bei meiner 7590ax:

mit FritzOS 7.31 rev94867 und freetz-ng-21376-37014746d komme ich wie immer mit "root" und meinem Passwort per telnet auf meine Box. Mit einem Labor FritzOS 7.39 rev103864 und freetz-ng-21376-37014746d funktioniert der root-login nicht mehr.

im "menuconfig" habe ich natürlich "replace ar7-login" aktiviert.

 

[PeterAu]

Habe das gleiche Problem wie kriegt man das wieder zum laufen?