Nach Aktualisierung kein Freetz Session-Login mehr möglich #224

Bodenseematze · 2021-03-11T13:41:24Z

Bodenseematze
Mar 11, 2021

Hallo zusammen,

ich habe heute auf meine 7590 zweimal einen aktuell gebauten Stand (freetz-ng-18134M-1c6cf3e2a) mit Fw 7.25 gespielt (über Freetz Firmware-Update).
Das erste Mal hat es problemlos funktioniert, sowohl AVM-WebIf als auch Freetz-WebIF als auch meine ssh-Verbindungen über einen eigenen Port.
Dann habe ich den gleichen Stand nochmal mit zusätzliche GnuTLS-Library übersetzt und diese nochmal draufgespielt.

Danach kam zuerst beim Aufruf des Freetz-WebIf plötzlich kein Session-Login mehr (das ich schon seit einiger Zeit eingestellt hatte) sondern die alte Variante - und zwar mit Standard-Passwort und nicht dem von mir gesetzen.
Da habe ich dann gleich wieder mein ursprüngliches Passwort gesetzt.

Dann ist mir aufgefallen, dass der crond nicht mehr läuft und auch nicht mehr auf "automatisch" steht - also auch das wieder eingeschaltet und weiter geschaut - hosts sind noch da, dnsmasq läuft und hat seine Einstellungen - sieht sonst alles normal aus.
Dann habe ich wieder das Session-Login eingeschaltet und nach einem Refresh der Seite kommt das Login auch - allerdings kann ich mich nicht mehr einloggen - weder mit Standardpasswort noch mit dem von mir gesetzten...
Also denke ich: kein Problem, dann logge ich mich eben per ssh ein - aber der scheint auch nicht mehr zu laufen - weder auf dem Standard-Port noch auf dem von mir normalerweise verwendeten Port.

Jetzt zwei Fragen:
1.) wie kann ich das Freetz-Verfahren wieder auf Standard zurücksetzen oder das Passwort auf Standard, ohne den Rest "kaputt" zu machen?
2.) was ist da überhaupt passiert? Sehr seltsam das ganze...

Achja, der AVM-Teil funktioniert ganz normal und hat auch ganz normal seine Einstellungen...

fda77 · 2021-03-11T14:23:32Z

fda77
Mar 11, 2021
Collaborator

Es gab vor kurzem schonmal sowas komisches mit dem Session-Login: https://github.com/Freetz-NG/freetz-ng/issues/153 & f2f5e84
Dass cron sich selbst (de)aktiviert kenne ich nur wenn man das DEBen-Addon installiert ist (bzw war!). Punk 2 auf https://freetz-ng.github.io/freetz-ng/ADDONS.html

2 replies

Bodenseematze Mar 12, 2021
Author

Es scheint so, dass bei mir irgendwie eine Teil der gespeicherten Einstellungen wieder auf Standardeinstellungen zurück gesetzt wurden - es ist war ja nicht nur der cron betroffen, der ssh-Daemon läuft ja auch nicht mehr (ob er seinen Port behalten hat, weiß ich nicht).
Was mir noch aufgefallen ist: auch die Breite der Weboberfläche war zurück gesetzt.

Warum ich dann nach Neusetzen des Passworts und Umstellen auf Session-Login überhaupt nicht mehr rein komme, ist da dann wohl ein Folgeproblem (von dem ich übrigens noch nicht weiß, wie ich das wieder löse - ohne ssh-Zugang; wie mache ich das am einfachsten?)

Übrigens habe ich mit DEBen überhaupt nichts am Hut!
Wie gesagt - ich hatte nochmal ein komplett neues Image gebaut - an der Config habe ich zwei Dinge geändert: ich habe von Expert auf APTGuru gewechselt und dann die Verwendung der fertig gebauten Toolchain eingeschaltet und ich habe die GNUTLS-Library hinzugefügt.
Dann habe ich allerdings komplett neu gebaut (d.h. make clean vorangestellt) - ich wollte mal sehen, ob es viel schneller abläuft, mit vorgebauter Toolchain...

Gismotro Mar 14, 2021

Also auf meiner 7520 läuft die aktuelle FW der 7530 (7.25) ohne DEB-Addon. Nur WoL und Samba ausgewählt.

aktuelle Probleme:

keinen Zugriff per telnet (root)
kein Zugriff per AVM-FTP (user:Pw aus AVM-WebIF)

Liegt es ggf. an den Änderungen von AVM ? siehe hierzu die AVM-Info :
Ab FRITZ!OS 7.25 kommt es bei der Anmeldung mit dem FRITZ!Box-Kennwort zu einer Änderung, die von Entwicklern für FRITZ!Box berücksichtigt werden muss. Die Änderung ist außerdem Bestandteil der Laborversion FRITZ!OS 7.24.

Quelle: https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/Empfehlungen%20zur%20Benutzerfu%CC%88hrung%20bei%20der%20Anmeldung%20an%20einer%20FRITZ%21Box_v1.1.pdf

Edit: Ich teste das mal mit der 7.24(Labor) auf meiner 7490 gegen.
aktiv dort nur telnet und VSFTPD

fda77 · 2021-03-12T12:55:40Z

fda77
Mar 12, 2021
Collaborator

Dl-Tools+Toolchains sind es bestmmt nicht, die nutze ich nur noch, da damit ein Minimalimage in 3 Minuten fertig ist.
Vom Addon ist halt bekannt dass es dort diese Probleme gab und noch immer alte Images damit im Umlauf sind.
Wenn es bei dir aber so auftritt, kann es noch so ein Problem wie in f2f5e84 sein, also dass Busybox irgend einen Befehl jetzt anderes interpretier. Das kann von der Busyboxversion abhängen und von den installierten Packages. Da aber mehrere (alle?) Packages betroffen sind müsste es aber ein Problem am "mod" sein, also beim (globalen) Speichern oder Laden. Das müssten dann aber mehr Leute haben.
Oder du könntest ein Alien haben das das TFFS nicht richtig ansprichst...

20 replies

fda77 Mar 15, 2021
Collaborator

Telnet-Login funktioniert bei mir mit 7.24+ auch nicht mehr. Weder mit root noch mit den von AVM angelegten boxusr11 und boxusr11int . Falls es niemand braucht würde ich vorschlagen die Option nur bis 7.20 auswählbar zu machen :)

fda77 Mar 15, 2021
Collaborator

Um den Start eines daemons zu erzwingen hätte es gereicht $DROPBEAR_ENABLED durch einen Wert zu ersetzen. Ich glaube möglich ist darin yes, no und evtl inetd
https://github.com/Freetz-NG/freetz-ng/blob/master/make/dropbear/files/root/etc/init.d/rc.dropbear#L60

Bodenseematze Mar 16, 2021
Author

Telnet-Login funktioniert bei mir mit 7.24+ auch nicht mehr. Weder mit root noch mit den von AVM angelegten boxusr11 und boxusr11int . Falls es niemand braucht würde ich vorschlagen die Option nur bis 7.20 auswählbar zu machen :)

Wenn's nicht mehr funktioniert, kann man es auch nicht mehr brauchen ;-)
Also entweder herausfinden, warum es nicht mehr funktioniert oder die Option entfernen...

Könnte man stattdessen nicht den dropbear (oder einen beliebigen anderen Daemon) als Dienst an den Telefon-Code hängen?
Also diesen per Telefon ein-/ausschaltbar machen?

Oder sonst eine Möglichkeit finden, einen wichtigen Daemon starten zu können ohne auf die Freetz-Weboberfläche zu müssen?
Vielleicht auch über einen definierten Tastendruck an der Box?

fda77 Mar 16, 2021
Collaborator

Könnte man bestimmt, falls jemnd weiss/herausfindet was bei der Tastenkombination genau geschieht. Ich für meine Bastelbox aber gar kein Telefon ...
Das ganze basiert halt darauf wie AVM es früher offiziell in der Firmware hatte.
Falls es von AVM so eine "interne" Firmware mit Telnet gibt, könnte man schauen wie das dort mit dem Login gelöst ist

PeterPawn Mar 16, 2021

Das mit dem "funktioniert nicht mehr" hinsichtlich der Telefon-Codes sind ja auch nur Sch***haus-Parolen - es funktioniert schon noch, nur wird eben jetzt eine andere Firmware-Variable ausgewertet für die Entscheidung, ob der telefon-Daemon nun im private mode arbeiten soll oder nicht. Dabei würde dann sowohl die Verarbeitung der calllog-Datei wieder freigeschaltet, als auch die Telefon-Codes zum Starten des Telnet-Daemons (Stoppen geht m.E. immer).

Und wieso sollte es irgendein "Geheimnis" sein, wie dieser telnetd bei AVM gestartet wird? Das habe ich doch oben in dem Hexdump schon gezeigt, wie das aussieht - wer stattdessen also lieber dropbear starten möchte (ungeachtet der bekannten Probleme, daß man den Start nur einmal pro Neustart (des telefon-Daemons) erfolgreich ausführen kann), der muß nur ein Shell-Skript als /usr/sbin/telnetd hinterlegen und darin dann diesen dropbear starten - fertig ist die Laube.

Und dafür (um das zu implementieren und zu testen) braucht man nicht einmal ein Telefon, weil das mit der "Wählhilfe" bei AVM genauso funktioniert - vorausgesetzt, der telefon-Daemon läuft im - bereits erwähnten - private mode.

Und daß dann bei diesem Telnet-Daemon auch nicht root oder irgendein anderer Eintrag aus /etc/passwd für die Anmeldung verwendet werden kann, versteht sich nun mal von selbst ... da wird IMMER(!) das /sbin/ar7login als Login-Programm eingebunden und das kennt nun mal nur die Accounts aus der ar7.cfg.

Das Witzige ist nur, daß das alles lange bekannt ist und im IPPF schon zig-mal ventiliert wurde - auch wenn das mit den "Discussions" hier neu sein mag, muß man ja nun nicht zwangsläufig auch die ganzen alten Lagerfeuer-Geschichten hier erneut erzählen und alles noch einmal aufdröseln.

Wenn das Login auch bei Verwendung von /bin/login nicht funktionieren will (üblicherweise hat root gar kein Kennwort, wenn es nicht durch Freetz(-NG) gesetzt wird - mithin wird auch kein Login für root möglich sein, solange das nicht richtig(!) gesetzt wurde), dann muß man sich eben mal das weiter unten schon erwähnte crypt() genauer ansehen - zumindest wäre es eine "erste Spur". Denn so ein __set_errno kann auch noch viel später und an anderen Stellen zum Problem werden, weil die C-Library das selbst nicht löschen würde und somit ist der Aufrufer dafür zuständig, daß alte Fehlerbedingungen irgendwann mal als "behandelt" angesehen werden. Wenn das aber bisher funktionierte, gab es bisher auch keinen Grund, die Variable vor weiteren Aufrufen auf NO_ERROR zu setzen - das kann also auch noch irgendeine nachfolgende Funktion sein, die da gegen den Baum fährt, weil sie den (alten) gesetzten Fehlercode irrtümlich für den eigenen hält.

Ihr solltet Euch vielleicht mal mehr mit der "Ursachenforschung" für das/ein Problem befassen, als mit der Suche nach "Workarounds" - zumindest dann, wenn man dabei auch systematisch alle noch vorhandenen "Spuren" dadurch beseitigt, daß man da einfach neue Kennwörter drüber bügelt. Das hilft zwar dem Einzelnen im Moment auch ... aber für das tatsächliche Erkennen, wo das Problem liegt und wie es dazu kommt, bringt das genau gar nichts.

Bodenseematze · 2021-03-15T14:46:48Z

Bodenseematze
Mar 15, 2021
Author

So, ich bin jetzt ein Schritt weiter - ich habe ein Image gebaut, in dem es eine S20-dropbear im /etc/init.d-Verzeichnis gibt (habe einen Symlink auf rc.dropbear im Paket-Verzeichnis unterhalb von make angelegt) - damit startet mein dropbear-sshd wieder automatisch.
Ich kann mich jetzt auch wieder per ssh einloggen --> d.h. das "normale" root-Passwort ist immer noch da, oder?

Nur die freetz-Weboberfläche ist immer noch auf Session-Login gestellt und lässt mich noch nicht wieder rein...
...jetzt muss ich also noch herausfinden, wo deren Passwort gespeichert ist und wie ich das entsprechend ändern kann

4 replies

PeterPawn Mar 15, 2021

Mal abgesehen vom Erfolgserlebnis ... kannst Du das:

in dem es eine S20-dropbear im /etc/init.d-Verzeichnis gibt (habe einen Symlink auf rc.dropbear im Paket-Verzeichnis unterhalb von make angelegt)

noch etwas genauer erklären? Es erscheint zumindest komisch, wenn in einem FRITZ!OS, was über supervisor gestartet wird (und hier war/ist ja hoffentlich/vermutlich immer noch von einer FRITZ!OS-Version jenseits der 07.2x die Rede), ein zusätzlicher Link in /etc/init.d/... einen Start eines Daemons bewirkt - und "unterhalb von make" liegen schon einige Paket-Verzeichnisse (u.a. das für den Dropbear und auch das für mod, was ja der eigentliche Freetz-Mod wäre) und damit versteht man (konkreter: ich) nicht so richtig, wo da genau ein Symlink angelegt wurde und wohin der zeigt - zumindest war das ja vermutlich eine Aktion auf dem Build-Host.

Bodenseematze Mar 15, 2021
Author

Ich habe auf meinen Build-Host in meinem Freetz-NG Arbeitsverzeichnis im Unterverzeichnis make/dropbear/files/root/etc/init.d einen symbolischen Link S20-dropbear auf rc.dropbear angelegt.
Außerdem habe ich (sicherheitshalber; ich weiß nicht, ob das einen Effekt hatte) in der Datei make/dropbear/files/root/etc/default.dropbear export DROPBEAR_ENABLED='yes' sowie meinen Port bei DROPBEAR_PORT eingefügt.

Beim Bau des Image wurde dabei unter build/modified/filesystem/etc/init.d dieser Link dann ebenfalls angelegt und damit landet er auch auf der Box unter /etc/init.d.
Ob jetzt der Link oder die neu gesetzten Defaults die Ursache dafür waren, dass der dropbear-Daemon wieder gestartet wird, weiß ich nicht.

Inzwischen habe ich mit echo -n "freetz" | md5sum | sed 's/[ ]*-.*//' > /tmp/flash/mod/webmd5 auch das freetz Web-Interface-Passwort wieder zurückgesetzt - damit wurde ich beim Login wieder nach einem neuen Passwort gefragt und dieses gesetzt.
Ich habe in dem Zug dann gleich (ohne mich nochmals auszuloggen) die Weboberfläche wieder von Session-Login auf "Standard" zurückgestellt.

Beim dropbear steht in der Weboberfläche (immer noch?) "automatisch" drin...

Achja, und bei den "AVM-Diensten/Einstellungen" steht beim telnetd "manuell" und "byphone"...

Gismotro Mar 15, 2021

Also mein Dropbear (ssh-Zugriff) läuft weiterhin auch ohne das ich was am Dropbear ändern mußte.

PeterPawn Mar 15, 2021

So ein Sch*** - ich hatte gerade einen längeren Text geschrieben und der hat sich jetzt - dank eines "unvorsichtigen", aber unbeabsichtigten Klicks auf einen dort eingefügten Link - wieder in Luft aufgelöst, weil das Zeug hier kein "autosave" hat und nicht mal der Wechsel auf "Preview" zu einem Roundtrip führt, der dann wieder in irgendeiner Browser-History landen könnte. Das ist noch ein deutliches Manko der GitHub-Diskussionen im Vergleich zu "herkömmlichen" Bulletin-Boards - die haben üblicherweise so eine regelmäßige Sicherung.

Ich habe jedenfalls keinen Bock mehr, das alles noch einmal zu schreiben ... deshalb nur ganz kurz:

In uClibc-ng hat sich das crypt() in der 1.0.37 dahingehend geändert, daß da jetzt nicht nur NULL im Fehlerfall zurückgegeben wird (wenn salt falsch formatiert ist), sondern noch ein Fehler EINVAL gesetzt wird, was bis zur 1.0.36 auskommentiert war: https://elixir.bootlin.com/uclibc-ng/v1.0.37/source/libcrypt/crypt.c

Da KÖNNTE(!) sich also ein Blick lohnen, ob die Eingabewerte für crypt() (in den jeweiligen Programmen, die da ein Kennwort hashen (aka "verschlüsseln") lassen wollen, um es mit einem gespeicherten Wert zu vergleichen) tatsächlich stimmen oder ob nicht dieser zusätzliche Fehlercode am Ende dazu führt, daß da irgendwelche falschen Wege in den Server-Programmen eingeschlagen werden. Denn üblicherweise kommt dieser salt ja aus den gespeicherten Daten eines Kennworts - nur auf diesem Weg ist es (bei Verwendung von Crypto-Hashes) auch möglich, dieselben "Ausgabedaten" für einen Algorithmus zu erzeugen, so daß ein Vergleich überhaupt lohnt.

Wobei man auch sagen muß, daß sich hier dropbear z.B. vorbildlich verhält bei so einem Vergleich zwischen gespeichertem und neu erzeugtem Hash: https://github.com/mkj/dropbear/blob/9262ffe8617bd8d631edf30772650ff4d5d156c6/svr-authpasswd.c#L108 - anstatt da anhand der Geschwindigkeit des "Abbruchs" beim Vergleichen dem Aufrufer Hinweise darauf zu geben, an welcher Stelle der Vergleich scheiterte, wird sichergestellt, daß positive und negative Vergleiche genauso lange brauchen und sich daher keine Rückschlüsse aus der Dauer dieser Operation ziehen lassen - man somit das Kennwort auch nicht über einen Seitenkanal-Angriff über das Timing "erraten" kann.

Ich würde jedenfalls vermuten(!), daß sich irgendwo in diesem geänderten Verhalten dann auch der Grund findet, warum die (bzw. "manche") Programme, die auf die Kennwörter in der /etc/passwd bzw. in der /etc/shadow zurückgreifen wollen, nicht (mehr) richtig funktionieren (zumindest in einigen Fällen, denn das kann ja problemlos auch davon abhängig sein, wie die Betroffenen bisher ihre Kennwörter gehasht und dann gespeichert haben) - es sei denn, das war in den vorherigen Installationen bei den Betroffenen auch schon immer die 1.0.37-Version der uClibc-ng, die da als C-Library zum Einsatz kam (bei AVM ist es entweder musl (bei den GRX-Modellen) oder eine ältere Version der uClibc-ng).

fda77 · 2021-03-16T17:34:52Z

fda77
Mar 16, 2021
Collaborator

@PeterPawn ich schreib mal hier weiter, da mich dieses "aufklappen" nervt.
Wie gesagt, über den Telefoncode kann ich mangels Telefon nichts sagen!
Ich hab telnet einfach so auf der Console gestartet: "telnetd -F -l /sbin/ar7login" (und strace -fffffff davor)
Im Telnet wird nach dem Benutzernamen "root" sofort ohne Passwortabfrage "Loin incorrect" angezeigt
Bei jedem anderen Benutzernamen (ob diesen gibt oder nicht) wird danach noch ein Passwort abgefragt

Es wird aber auf jeden Fall die /etc/passwd gelesen!!

Und scheinbar eine /etc/securetty
7490:

tts/0
tts/1
tty
console
tty1
tty2

Strace ab "enter" nach "root" Benutzername


) = 1 (in [4])
[pid  6115] read(4, "\r\n", 2024)       = 2
[pid  6115] _newselect(6, [3 4 5], [5], NULL, NULL) = 1 (out [5])
[pid  6115] write(5, "\r", 1)           = 1
[pid  6141] <... read resumed>"root\n", 4096) = 5
[pid  6115] _newselect(6, [3 4 5], [], NULL, NULL <unfinished ...>
[pid  6141] open("/etc/passwd", O_RDONLY|O_LARGEFILE <unfinished ...>
[pid  6115] <... _newselect resumed>)   = 1 (in [5])
[pid  6141] <... open resumed>)         = 3
[pid  6115] read(5,  <unfinished ...>
[pid  6141] ioctl(3, TCGETS <unfinished ...>
[pid  6115] <... read resumed>"\r\n", 2024) = 2
[pid  6141] <... ioctl resumed>, 0x7fd1d164) = -1 ENOTTY (Inappropriate ioctl for device)
[pid  6115] _newselect(6, [3 4 5], [4], NULL, NULL <unfinished ...>
[pid  6141] read(3,  <unfinished ...>
[pid  6115] <... _newselect resumed>)   = 1 (out [4])
[pid  6141] <... read resumed>"eigeneruser:x:777:0:eigenegruppe:/:/bin/false\na"..., 4096) = 1103
[pid  6115] write(4, "\r\n", 2 <unfinished ...>
[pid  6141] close(3 <unfinished ...>
[pid  6115] <... write resumed>)        = 2
[pid  6141] <... close resumed>)        = 0
[pid  6115] _newselect(6, [3 4 5], [], NULL, NULL <unfinished ...>
[pid  6141] open("/etc/securetty", O_RDONLY|O_LARGEFILE) = 3
[pid  6141] ioctl(3, TCGETS, 0x7fd1d16c) = -1 ENOTTY (Inappropriate ioctl for device)
[pid  6141] read(3, "tts/0\ntts/1\ntty\nconsole\ntty1\ntty"..., 4096) = 34
[pid  6141] read(3, "", 4096)           = 0
[pid  6141] close(3)                    = 0
[pid  6141] rt_sigaction(SIGCHLD, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 16) = 0
[pid  6141] nanosleep({tv_sec=3, tv_nsec=0},

0x7fd1d24c) = 0
[pid  6141] write(1, "Login incorrect\n", 16) = 16

EDIT: Nach löschen der securetty kommt nach Eingabe von root als Benutzernamen nicht mehr sofort eine Fehlermeldung

0 replies

fda77 · 2021-03-16T17:41:43Z

fda77
Mar 16, 2021
Collaborator

Einloggen mit den Daten vom AVM-Webif, ab "Enter" nach dem Passwort

) = 1 (in [4])
[pid  6246] read(4, "\r\n", 2024)       = 2
[pid  6246] _newselect(6, [3 4 5], [5], NULL, NULL) = 1 (out [5])
[pid  6246] write(5, "\r", 1)           = 1
[pid  6247] <... read resumed>"n", 1)   = 1
[pid  6246] _newselect(6, [3 4 5], [], NULL, NULL <unfinished ...>
[pid  6247] read(0, "p", 1)             = 1
..
[pid  6247] read(0, "w", 1)             = 1
[pid  6247] read(0, "\n", 1)            = 1
[pid  6247] rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, NULL, 16) = 0
[pid  6247] ioctl(0, TCSETS, {B38400 opost isig icanon echo ...}) = 0
[pid  6247] ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
[pid  6247] write(1, "\n", 1)           = 1
[pid  6246] <... _newselect resumed>)   = 1 (in [5])
[pid  6247] brk(0x4d1000 <unfinished ...>
[pid  6246] read(5,  <unfinished ...>
[pid  6247] <... brk resumed>)          = 0x4d1000
[pid  6246] <... read resumed>"\r\n", 2024) = 2
[pid  6246] _newselect(6, [3 4 5], [4], NULL, NULL <unfinished ...>
[pid  6247] mmap(NULL, 40960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0 <unfinished ...>
[pid  6246] <... _newselect resumed>)   = 1 (out [4])
[pid  6247] <... mmap resumed>)         = 0x77a07000
[pid  6246] write(4, "\r\n", 2)         = 2
[pid  6246] _newselect(6, [3 4 5], [], NULL, NULL <unfinished ...>
[pid  6247] munmap(0x77a07000, 40960)   = 0
[pid  6247] rt_sigaction(SIGCHLD, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 16) = 0
[pid  6247] nanosleep({tv_sec=3, tv_nsec=0}, 0x7f9271cc) = 0
[pid  6247] write(1, "Login incorrect\n", 16) = 16

0 replies

fda77 · 2021-03-16T17:46:42Z

fda77
Mar 16, 2021
Collaborator

@PeterPawn: DL-tools+toolchains werden nur genutzt wenn man die user-competence "APTgutu" verwendet. Viele hatten massive Probleme mit apt Pakete nachzuinstallieren https://freetz-ng.github.io/freetz-ng/NEWS.html#2021-03-02

0 replies

PeterPawn · 2021-03-16T18:44:10Z

PeterPawn
Mar 16, 2021

Du testest ja gar nicht wirklich das Login mit AVM-Accounts, denn das wird bei Freetz-NG ja hiermit: https://github.com/Freetz-NG/freetz-ng/blob/master/make/mod/files/root/sbin/ar7login umgebogen - Du müßtest also entweder -l /sbin/ar7login.bin verwenden oder die root-Zeile in der /etc/shadow (das ist der Symlink auf /tmp/shadow) wieder auf ein Kennwort * ändern.

EDIT: Damit hat @Bodenseematze dann - unter einem Freetz[-NG]-Image - auch recht gehabt - da wird dann zwar weiterhin das ar7login vom telefon verwendet bei Aufruf, aber das biegt Freetz dann (ziemlich fies) einfach um - und mit den AVM-Accounts kann man nur noch arbeiten, wenn man ein echo "root:*:12332:0:99999:7:::" >/tmp/shadow macht oder auch sed nimmt, falls da tatsächlich noch mehrere Accounts enthalten sind. Die dann aber auch alle von Freetz stammen würden, weil AVM direkt die /etc/passwd ändert - das mit der shadow ist unter dem Sicherheitskonzept von FRITZ!OS ohnehin nur Augenwischerei. Das mit diesem "Wrapper-Skript" ist mir aber auch erst wieder eingefallen (so "da war doch mal was"-mäßig), als ich die Zugriffe auf /etc/passwd gesehen habe, die beim "richtigen" ar7login gar nicht auftreten dürften.

Dieses Fehlen eines "autosave" für die Beiträge hier, geht mir sowas von auf die Eier ... ich tappe immer wieder in diese Falle, wenn ich nach irgendwelchen Links suche, die ich in dem geschriebenen Text unterbringen will - eben schon wieder. Mancher mag das sogar gut finden, weil ich dann vor lauter Wut auch nur noch Telegrammstil schreibe - oder auch gleich komplett verzichte. Es nervt einfach nur ... das kann ja nicht sooo schlimm sein, den eingegebenen Text regelmäßig in eine lokale Sicherung zu schreiben (window.localStorage oder sogar window.sessionStorage, weil niemand so blöd ist, den Tab auch noch zu schließen).
Da ja hier dann am Ende login verwendet wird, sollte man erst mal klären, wo das wirklich herkommt (es ist vermutlich das aus der BusyBox) und wie das genau übersetzt wurde bzw. ob sich da Optionen für die BusyBox (insb. bei CONFIG_USE_BB_CRYPT*) verändert haben, weil in Abhängigkeit von diesen Optionen auch die BusyBox am Ende das crypt() aus der C-Library verwenden würde: https://elixir.bootlin.com/busybox/1.33.0/source/libbb/pw_encrypt.c#L150
Dein Test war ja dann der "Beweis", daß irgendetwas mit dem Login über /etc/passwd bzw. /etc/shadow tatsächlich faul ist - allerdings verwendet der dropbear das login nicht für die Kennwort-Authentifizierung, sondern macht die selbst (siehe Link zu common_sess.c oder so ähnlich, falls der das gestrige Desaster überlebt haben sollte und irgendwo in dem von mir Geschriebenen auftaucht) und verwendet dazu dann eben auch das crypt() ... da liefen dann die Fäden erst wieder zusammen, wenn das tatsächlich sowohl mit dropbear als auch mit telnetd zu reproduzierbaren Ergebnissen führt(e).

0 replies

fda77 · 2021-03-16T18:49:30Z

fda77
Mar 16, 2021
Collaborator

doch:

auf der Console gestartet: "telnetd -F -l /sbin/ar7login" (und strace -fffffff davor)

einfach öfter zwischen-posten ;-)

Mit diesem Patch ist mit meinem avm-webif-benutzer nach wie vor kein Login möglich

cat toolchain/make/target/uclibc/1.0.37/000-crypt_c--revert-set_errno.patch
--- uClibc-ng-1.0.37/libcrypt/crypt.c   2020-12-26 19:04:49.000000000 +0100
+++ uClibc-ng-1.0.36/libcrypt/crypt.c   2020-10-02 19:29:10.000000000 +0200
@@ -6,7 +6,6 @@

 #include <unistd.h>
 #include <crypt.h>
-#include <errno.h>
 #include "libcrypt.h"

 char *crypt(const char *key, const char *salt)
@@ -27,7 +26,7 @@
                                return __sha512_crypt(ukey, usalt);
 #endif
                }
-               __set_errno(EINVAL);
+               /* __set_errno(EINVAL);*/ /* ENOSYS might be misleading */
                return NULL;
        }
        return __des_crypt(ukey, usalt);

Vielleicht liegts daran:

$ passwd root
passwd: no record of root in /etc/shadow, using /etc/passwd: Numerical result out of range
Changing password for root
New password: a
Bad password: too weak
Retype password: a
passwd: password for root changed by root

8 replies

fda77 Mar 16, 2021
Collaborator

Eihentlich könnte man diese 2 löschen:
https://github.com/Freetz-NG/freetz-ng/blob/master/make/mod/files/root/sbin/ar7login
https://github.com/Freetz-NG/freetz-ng/blob/master/patches/scripts/107-wrapper_ar7login.sh
Dann wäre das Verhalten wie bei avm - halt ohne .profile. Wer Telnet nutzt braucht das aber auch nicht ^^
sieh auch https://github.com/Freetz-NG/freetz-ng/tree/master/patches/scripts#undisableable-patches

Wofür wird ar7login denn noch so genutzt?

PeterPawn Mar 16, 2021

Ich hab aber noch den uclib-crypt.c-revert patch aktiv

Ob der überhaupt Sinn macht (auch wenn es der kleinste gemeinsame Nenner von telnetd und dropbear wäre), ist doch eigentlich auch noch ziemlich unklar ... ich werde jedenfalls aus den verschiedenen Beobachtungen - jeweils noch vor und nach irgendwelchen neu gesetzten Kennwörtern - beim SSH-Server nicht so richtig schlau. Erst wenn das auch nicht funktioniert (bei Kennwort-Authentifizierung, weil es natürlich bei PubKey auch wieder kein Schwein interessiert), dann würde ich auf das crypt() schauen - vorher müßte man ja erst noch klären, ob das BusyBox-Applet login tatsächlich auch die crypt()-Funktion aus der C-Library benutzt. Ist das nicht der Fall, interessiert diese Funktion ja auch beim login-Applet niemanden.

fda77 Mar 16, 2021
Collaborator

Ich vermute dass

passwd: no record of root in /etc/shadow, using /etc/passwd: Numerical result out of range

ist der Auslöser der ursprünglichen Problems. Dass da root drin ist sieht man ja oben am grep!

PeterPawn Mar 16, 2021

Eihentlich könnte man diese 2 löschen:

Konzentriere Dich doch jetzt erst einmal auf das Wesentliche ... und das wäre ja wohl die Fehlersuche. Wenn man danach dann in Ruhe noch einmal überlegt und zur Entscheidung kommt, daß dieser ar7login-Wrapper gar nicht gebraucht wird, ist das wieder etwas anderes.

Denn dieser Wrapper sorgt ja auch noch dafür, daß komplett andere Login-Namen verwendet werden - der stammt aber auch noch aus einer Zeit, wo es bei AVM noch gar keine getrennten Benutzerkonten gab und die Entscheidung zwischen ar7login und login nur die war, ob jetzt das AVM-(Box-)Kennwort benötigt wurde oder das von Freetz für root (und dann das mit der .profile).

Also immer schön der Reihe nach ... der Wrapper mag zwar (im Moment) etwas hinderlich sein bei der Suche, aber solange nicht sicher ist, daß der auch für den Aufruf eines falschen login verantwortlich ist (weil der ja keine absoluten Pfade enthält für diese Aufrufe), änderst Du mit dessen Entfernen bloß noch zusätzlich das "Gesamtsystem", was dann den Überblick nur noch erschwert, wenn es zwei weitere Faktoren bei den Permutationen (mit bzw. ohne diesen Wrapper) einführt.

Denn mit dem Problem beim dropbear (falls sich das auch bestätigt) kann der Wrapper ja auch nichts zu tun haben ... das ist also eine andere Baustelle.

PeterPawn Mar 16, 2021

Sorry, das wird mir wieder zu "stückig". Wir schreiben wieder parallel, jeder kennt nur den vorletzten Beitrag des anderen und so reden wir wieder munter aneinander vorbei.

Ich weiß nicht, wie valide der Test mit passwd am Ende wirklich ist ... aber wenn Du damit glücklich wirst und damit auch den Fehler findest - wer wollte Dich davon abhalten?

fda77 · 2021-03-16T19:25:45Z

fda77
Mar 16, 2021
Collaborator

Ich kann 100x "passwd root" ausführen und ein PW setzen, die Meldung kommt aber jedes mal!
Es wird auch offensichtlich shadow dadurch verändert. Aber der hash des neuen Passwortes ist kürzer als die bereits vorhandenen

Hashlänge heute mit passwd angelegt: 14 Zeichen
Bereits vorhanden Benutzer: 50 Zeichen - ausserdem beginnen diese alle mit '$1$'

crypt(3)

          ID  | Method
          ─────────────────────────────────────────────────────────
 **       1   | MD5
          2a  | Blowfish (not in mainline glibc; added in some
              | Linux distributions)
          5   | SHA-256 (since glibc 2.7)
          6   | SHA-512 (since glibc 2.7)

Die boxuser haben "$6$"

1 reply

PeterPawn Mar 16, 2021

Alles Hash-Werte, die nicht mit $x$ beginnen, verwenden einen alten Algorithmus (DES), den eigentlich auch niemand mehr benutzen sollte (https://elixir.bootlin.com/uclibc-ng/latest/source/libcrypt/crypt.c#L33) und im __des_crypt der BusyBox ist sogar nur das ganz alte Format (das mit den max. 8 Zeichen Kennwort) unterstützt, wenn man in die aktuellen Quellen schaut: https://elixir.bootlin.com/uclibc-ng/latest/source/libcrypt/des.c#L645

Ich weiß auch nicht, wie das vorher war und ob sich da etwas geändert hat und wenn ja, was genau ... aber daß ein passwd seinerseits keine DES-Hashes mehr erzeugen SOLLTE, das weiß ich ziemlich genau. Und genau dafür gibt es da auch den Parameter -a und mit dem sollten dann auch Deine Kennwort-Felder wieder mit $x$ beginnen und wenn Du MD5 nimmst, sogar wieder mit $1$ .

Nur klärt das ja auch noch nicht wirklich, was der C-Library (oder eben doch erst der BusyBox, denn das passwd gehört eben zu der und da müßte man auch erst mal nachsehen, ob das nicht doch wieder eine eigene Implementierung nutzt und gar nicht die aus der C-Library) hier am Format der /etc/passwd nicht gefällt und warum die überhaupt dorthin "umschaltet", wenn doch in der /etc/shadow auch schon ein gültiger Eintrag für root stehen sollte.

Ich glaube kaum, daß man das nur durch "weiteres Probieren" so weit eingrenzen kann, daß man auch die wirkliche Ursache findet - zumindest nicht in akzeptablen Zeiträumen. Wenn Du also unbedingt passwd zur "Diagnose" verwenden willst, dann schau Dir einfach mal die Abläufe in diesem BusyBox-Applet an - erst wenn Du die verstehst, wirst Du ja auch dahinter kommen, was letztlich der Auslöser für die Fehlermeldungen ist.

fda77 · 2021-03-16T19:55:36Z

fda77
Mar 16, 2021
Collaborator

Was besseres als md5 (1) bekomm ich nicht hin. Die Busybox kann das wohl nicht

$ passwd --help

Usage: passwd [-a ALG] [-dlu] [USER]

Change USER's password (default: current user)

    -a ALG      des,md5 (default des)
    -d  Set password to ''
    -l  Lock (disable) account
    -u  Unlock (enable) account

Ohne den Benutzer in shadow aber mit Passwort in der passed ist ein Login per Telnet möglich

8 replies

fda77 Mar 16, 2021
Collaborator

Probiers aus.. Ich müsste dazu die Busybox neu bauen :)
Leg dir am besten einen neuen Benutzer an

Ich würde die BusyBox auch mit den SHA-Hashes bauen

Ich hatte die irgendwann bei mir drin (sieht man anhand der alten Passwörter). Weiss nur nicht weshalb nicht mehr. Änderungen an meiner .config sehe ich mir immer sehr genau an, die liegen auch in einem svn

PeterPawn Mar 16, 2021

sieht man anhand der alten Passwörter

In derselben "Gegend" der BusyBox-Konfiguration liegt (iirc) auch eine Option, mit der man die Standard-Methode für den Hash ändern kann - bereits beim Build.

Bodenseematze Mar 16, 2021
Author

Leg dir am besten einen neuen Benutzer an

root@Fritz7590:~# adduser -h /mod/root -S -u 1 -s /bin/bash root2 -G root -g root2
addgroup: can't find root in /etc/../var/tmp/gshadow
Was ist das denn für eine komische Fehlermeldung? Der Benutzer wird aber angelegt - was bedeutet eigentlich das -S?
(hatte es davor noch mit adduser -h /mod/root -S -u 1 -s /bin/bash -g root2 root2 root versucht, da kommt dann aber eine Fehlermeldung adduser: unknown group nogroup und der Benutzer wird nicht angelegt)

root@Fritz7590:~# cat /etc/passwd | grep root2
root2:x:1:0:root2:/mod/root:/bin/bash
root@Fritz7590:~# cat /etc/shadow | grep root2
root2:!:18702:0:99999:7:::

root@Fritz7590:~# passwd -a sha512 root2 << EOF
> freetz
> freetz
> EOF
passwd: no record of root2 in /etc/shadow, using /etc/passwd: Numerical result out of range
Changing password for root2
New password:
Bad password: too weak
Retype password:
passwd: password for root2 changed by root
root@Fritz7590:~# cat /etc/shadow | grep root2
root2:$6$qJfyqTEGPUBlNQ9A$Ba5Q8RmYDohRKlDbnO/m46vYYxdTSfN1WuEiJhx7a2PiDsIwKFl0UD1mgWbxV6wNKmATj0JG2TtAqkcXsDFK01:18702:0:99999:7:::

Einlog-Versuche mit telnetd - kein Login möglich.
Mit dropbear funktioniert's - mit Fehlermeldungen wg. der Id 1, die auf das Verzeichnis des User 0 zugreift...
(wobei mit einige Meldungen komisch vorkommen....)

-bash: /var/env: Permission denied
rm: can't remove '/var/htmltext.db': Permission denied
ln: /var/htmltext.db: File exists
rm: can't remove '/var/TZ': Permission denied
ln: /var/TZ: File exists
rm: can't remove '/var/Country_iso': Permission denied
ln: /var/Country_iso: File exists
root2@Fritz7590:~$

Bodenseematze Mar 16, 2021
Author

In dem Zusammenhang - macht es denn Sinn / ist es vielleicht sogar besser, wenn ich jetzt von Hand mein root-Passwort auf sha512 umstelle? (also mit passwd -a sha512)
Das scheint bei mir zumindest noch des zu sein...
Oder handle ich mir damit (neue) Probleme ein?

Ich glaube, ich lege mir mal einen neuen root2-Benutzer an, bei dem ich die UID von Hand nachträglich auf 0 ändere - dann kann ich den zusätzlich zum "normalen" root-Benutzer verwenden ;-)

fda77 Mar 16, 2021
Collaborator

Ich benutze zum einloggen normal nur Keyfiles

Bodenseematze · 2021-03-16T20:10:13Z

Bodenseematze
Mar 16, 2021
Author

Zumindest bei mir ist es so, dass der telnetd nur ein Notnagel ist - d.h. wie im Ausgangspunkt der Diskussion - wenn aus irgendwelchen Gründen andere Möglichkeiten, auf die Box zu kommen, nicht mehr funktioniert - wenn es da also stattdessen einen alternativen Weg gäbe, einen sichereren Einlog-Daemon (ich nenne das jetzt mal so) starten zu können, könnte ich sicher auf den telnetd verzichten...

0 replies

PeterPawn · 2021-03-16T22:39:30Z

PeterPawn
Mar 16, 2021

Ich weiß zwar nicht genau, wie das hier jetzt weitergehen soll, aber der nächste Build sollte dann die Symbole CONFIG_FEATURE_SHADOWPASSWDS und CONFIG_USE_BB_CRYPT_SHA gesetzt haben ... denn die Fehlernachricht, die das passwd da ausspuckt, kommt von hier: https://elixir.bootlin.com/busybox/latest/source/loginutils/passwd.c#L163 und da kommt man nur vorbei, wenn das beim Build auch mit den Stellen, die nur bedingt übersetzt werden, alles genauso eingebunden wurde.

Warum dann die sechs in Zahlen zu konvertierenden Felder der /etc/shadow an irgendeiner Stelle zu diesem "out of range"-Problem führen (hier sind die Definitionen der Datentypen für den Parser: https://elixir.bootlin.com/busybox/latest/source/libpwdgrp/pwd_grp.c#L62 - die dürfen also auch leer sein), ist zwar damit auch noch nicht geklärt, aber man weiß dann zumindest mal wieder definitiv, wie die BusyBox nun eigentlich erzeugt wurde.

Denn außer dem Screenshot aus menuconfig habe ich hier noch keine einzige .config im Thread gesehen - und hier wäre ausnahmsweise tatsächlich mal die gesamte Datei und nicht nur die komprimierte Version gefragt, weil die interessanten Symbole u.U. schon "Standard" sind und dann in der komprimierten nicht auftauchen.

Fakt ist jedenfalls, daß das no record of root in /etc/shadow, using /etc/passwd: Numerical result out of range (also die gesamte Zeile) aus dem oben schon verlinkten Aufruf von getspnam_r() stammt (bzw. wg. dessen Ergebnis ausgegeben wird) und der landet dann auf verschlungenen Wegen irgendwann mal bei dem convert_to_struct() in der pwd_grp.c, wo dann die Konvertierung in eine Zahl versucht wird ... und die geht offenbar schief, wie der Text Numerical result out of range (also ERANGE - oder errno=34) anzeigt.

Auf den ersten Blick sieht jetzt aber keiner der Werte so aus, daß man das erwarten würde - also muß man sich ggf. auch noch die Konvertierungen in der C-Library ansehen, denn da verwendet auch die BusyBox dann wieder diese C-Library: https://elixir.bootlin.com/busybox/latest/source/libbb/bb_strtonum.c#L120 (https://linux.die.net/man/3/strtol) und wenn da ebenfalls neue Fehlercodes eingepflegt wurden, wie im crypt(), dann kann es doch wieder da zu finden sein.

Spannend ist es auch noch, daß die libpwdgrp/pwd_grp.c der BusyBox sich seit 2017 nicht mehr geändert hat - das würde ja auch wieder in die Richtung der C-Library weisen ... aber jetzt sollte man erst mal mit einem neuen Image (bei dem man dann auch genau weiß, wie BusyBox und C-Library konfiguriert sind) noch einmal systematisch "nachtesten", wie sich das wirklich verhält. Maximal könnte man noch einen (unabhängigen) Test machen, bei dem in der /etc/shadow auch das siebte und achte Feld (inact und expire) mal mit numerischen Werten belegt werden - bei inact kann's ruhig auch eine 0 sein, bei expire würde ich irgendetwa zwischen 18702 (heute) und 20000 (in 1298 Tagen) nehmen.

Wenn alle Stränge reißen, muß man eben die pwd_grp.c mal so anpassen, daß die im convert_to_struct() gesprächiger wird (außer man kann sie direkt debuggen - was passiert eigentlich mit so einer BusyBox und passwd auf einen "normalen System"?) und auch die Info preisgibt, welches Feld da nun genau nicht konvertiert werden kann.

Eine /etc/shadow gibt es jedenfalls auch bei AVM in der Firmware, die kann man also nicht einfach streichen - zumindest muß man sich das gut überlegen und auch erst mal prüfen, welche Auswirkungen das auf andere Komponenten hat. Und solange die existiert, werden Kennwörter von den entsprechenden (Linux-)Programmen auch in dieser Datei geändert/gespeichert - daher ist das also auch nichts, was man einfach durch "Ausweichen" auf die /etc/passwd dauerhaft(!) aus der Welt schaffen kann. Daß AVM da die eigenen Konten direkt in die /etc/passwd einträgt und sich auch auf das "Fallback" auf diese Datei verläßt, wenn ein Benutzer keinen Eintrag in der /etc/shadow hat, steht auf einem ganz anderen Blatt.

0 replies

fda77 · 2021-03-16T23:32:45Z

fda77
Mar 16, 2021
Collaborator

Ich deute!!! die Fehlermeldung so dass die 5 und 6 des Verschlüsselungsalgos im Passwort nicht im Range der unterstützten ("1" und davor) war

Bei mir funktioniert nun der Login mit Benutzer aus passwd+shadow

F7490 login: xxx
Password: xxx

BusyBox v1.33.0 (2021-03-17 00:06:45 CET) built-in shell (ash)

-sh: /etc/init.d/rc.conf: line 4: can't create /var/env: Permission denied
rm: can't remove '/var/htmltext.db': Permission denied
ln: /var/htmltext.db: File exists
rm: can't remove '/var/TZ': Permission denied
ln: /var/TZ: File exists
rm: can't remove '/var/Country_iso': Permission denied
ln: /var/Country_iso: File exists
xxx@F7490:/var/mod/root#

Ob das so sein soll dass diese Dinge ausgeführt werden weiss ich nicht, auch nicht ob das schon immer so war!

Login mit avm-webif-pw+user geht auch

Fritz!Box user: xxx
password: xxx

BusyBox v1.33.0 (2021-03-17 00:06:45 CET) built-in shell (ash)

sh: root: unknown operand
root@F7490:/var/mod/root# id
uid=0(root) gid=0(root)

Da wird auch irgend was ausgeführt beim Login

Was ich aber gar nicht verstehe, aus dem ar7login-wrapper:

		If wrapper was started by telnetd AND root password
		is defined, proceed with regular user/password login.

Man muss also ein root-passwort haben. ABER man kann sich auf keinen Fall mit root einloggen - wegen der securetty. Diese gibt es schon sehr, sehr lang, zb
14569e2689d96190744b17ce1805e726 ./FRITZ.Box_2170.51.04.57/etc/securetty
14569e2689d96190744b17ce1805e726 ./fritz.box_fon_wlan_7050.14.04.33/etc/securetty
14569e2689d96190744b17ce1805e726 ./FRITZ.Box_Fon_WLAN_7113.60.04.68/etc/securetty
14569e2689d96190744b17ce1805e726 ./FRITZ.Box_Fon_WLAN_7140.AnnexA.39.04.77/etc/securetty
14569e2689d96190744b17ce1805e726 ./fritz.box_fon_wlan_7140.annexb.30.04.33/etc/securetty
14569e2689d96190744b17ce1805e726 ./FRITZ.Box_Fon_WLAN_7141.40.04.77/etc/securetty
14569e2689d96190744b17ce1805e726 ./FRITZ.Box_Fon_WLAN_7170.29.04.88/etc/securetty
14569e2689d96190744b17ce1805e726 ./fw_Speedport_W501V_v_28.04.38/etc/securetty

Kann also eigentlich "noch nie" funktioniert haben

Es wird wohl die /etc/init.d/rc.conf nach dem einloggen automatisch ausgeführt. Ich hab keine Ahnung weshalb und ob das Sinn macht. Stört aber bis auf die unschönen Meldungen scheinbar nicht

4 replies

Bodenseematze Mar 18, 2021
Author

Bei mir funktioniert nun der Login mit Benutzer aus passwd+shadow

Ich habe nochmal ein neues Image gebaut (mit aktuellen Quellen und leicht angepasster Busybox-Konfiguration) - bei mir funktioniert das mit telnetd ebenfalls.
Auch diese komischen Meldungen beim Einloggen kommen in ähnlicher Form wie bei Dir...

Ausserdem kann ich mich noch mit einem boxusr-Account per telnetd einloggen.

Und als Passwortverschlüsselung funktioniert sowohl das alte "des" als auch "sha512" (was bei mit jetzt als Default eingestellt ist) - habe eine root-Benutzer, bei dem das Passwort in /etc/shadow noch per des gesetzt ist und einen root2-Benutzer (ebenfalls mit uid/gid 0), bei dem das Passwort per sha512 gesetzt wurde - mit beiden funktioniert der Login (per dropbear - beim telnetd funktionieren beide nicht, da scheinen nur Benutzer zu gehen, die ihr Password in der /etc/passwd stehen haben).

Login mit avm-webif-pw+user geht auch

Wie initiierst Du den?

Die Warnmeldung beim passwd-Aufruf ist übrigens weg - das funktioniert jetzt einwandfrei...

Meine Version ist aktuell Freetz: ng-18145M-af663c90c (Firmware: 154.07.25 rev86535) - config und config.compressed habe ich angehängt...
config_7590_7.25_2021-03-16.txt
config.compressed_7590_7.25_2021-03-16.txt

PeterPawn Mar 18, 2021

Kann also eigentlich "noch nie" funktioniert haben

Das Berücksichtigen der /etc/securetty kann per BusyBox-Parameter beim Build ein- und ausgeschaltet werden: https://git.busybox.net/busybox/tree/loginutils/login.c?h=1_24_stable#n82 und zwar schon mind. seit 1.24.x - das braucht bloß bisher deaktiviert gewesen zu sein und es hat dann doch funktioniert.

Bestimmt kannst Du Dich noch daran erinnern, daß in Freetz erst mal alle BusyBox-Settings auf not set gestellt wurden - vollkommen ohne Rücksicht darauf, ob das eine Einstellung war, die zusätzliche Applets einbinden sollte oder doch nur ein "Standardwert" der BusyBox, die ja nun auch nicht vollkommen absurde "Vorgaben" macht(e).

Bodenseematze Mar 18, 2021
Author

Zumindest bei mir ist die Berücksichtigung der /etc/securetty (FREETZ_BUSYBOX___V132_FEATURE_SECURETTY) mit x vorausgewählt und lässt sich nicht abschalten
Selected by [y]:
- FREETZ_BUSYBOX_FEATURE_SECURETTY [=y] && FREETZ_REPLACE_BUSYBOX [=y] && FREETZ_BUSYBOX__VERSION_V132 [=y]
und FREETZ_BUSYBOX___V132_LOGIN ist ebenfalls mit x vorausgewählt und kann nicht abgeschaltet werden:
Selected by [y]:
- FREETZ_BUSYBOX_LOGIN [=y] && FREETZ_REPLACE_BUSYBOX [=y] && FREETZ_BUSYBOX__VERSION_V132 [=y]

PeterPawn Mar 18, 2021

Das war hier nicht gemeint ... wenn Du es genau(er) wissen willst (ich schrieb ja oben, was da zuvor geschah), dann mußt Du Dir halt die Commit-Historie dazu ansehen.

Es mag sein, daß das seit diesen Änderungen wieder seitens Freetz-NG als Voreinstellung fest gesetzt wird, aber das bedeutet noch nicht, daß es schon immer so war.

Die einfachste Möglichkeit, den "Wahrheitsgehalt" meiner Worte zu prüfen, wäre der Blick in das originale Freetz-Projekt und da sieht das immer noch so aus:

Es ist also nicht nur möglich, sondern sogar wahrscheinlich, daß das schon einmal funktioniert hat - und nur das war es, was ich @fda77 mit meinem Beitrag nahebringen wollte.

fda77 · 2021-03-18T19:44:26Z

fda77
Mar 18, 2021
Collaborator

Wieder eine Busybox Option.. Ich hab vor ein paar Monaten, evtl 1 Jahr alle BB Optionen so gesetzt wie AVM sie nutzt. Man könnte diese Option nur als default=y setzte, damit man sie deaktivieren kann. Aber will man telnet als root nutzen??? In der Hilfe hab ich das ja schon dazugeschrieben (Diskussionen können nicht in commit-comments referenziert werden).
Da es bislang niemandem auffiel nutzen wohl nicht mehr so viele telnet.
Als "Notnagel" finde ich die AVM-Auth eh besser. Da ist es egal was mit passwd ist. Das kann man ja mit deaktiviertem replace-ar7login ermöglichen.
Ich bin der Meinujng man könnte es so lassen wie es ist

5 replies

Bodenseematze Mar 19, 2021
Author

Ich stimme Dir zu (solange der Default auf deaktiviertem "replace-ar7login" steht ;-)

Wobei ich mich da jetzt allerdings frage, ob es überhaupt eine sinnvolle Verwendung für den busybox-telnetd (d.h. mit deaktiviertem ar2-login) gibt...

EDIT: und der Default für FREETZ_BUSYBOX___V132_FEATURE_DEFAULT_PASSWD_ALGO sollte m.E. heutzutage auch auf etwas anderes als des gestellt werden - für mich wäre das sinnvollerweise sha512; ich kann allerdings nicht beurteilen ob es auf allen Boxen sinnvoll ist oder vielleicht doch nur sha256...

fda77 Mar 19, 2021
Collaborator

Ich hab doch schon auf sha512 als default umgestellt!
Wie gesagt, ich seh für telnet gar keine Verwendung. Wenn man sichergehen will dass man sich mit kaputter passwd einloggen kann, muss man halt Keyfiles hinterlegen. Das mach ich eh schon lang weil ich zu faul bin das Passwort immer einzugeben...
UPDATE: Login sollte jetzt auch mit root möglich sein

Bodenseematze Mar 25, 2021
Author

Ich hab doch schon auf sha512 als default umgestellt!

@fda77: ja, Du hast recht - habe ich inwischen auch gesehen ;-)

Wie gesagt, ich seh für telnet gar keine Verwendung. Wenn man sichergehen will dass man sich mit kaputter passwd einloggen kann, muss man halt Keyfiles hinterlegen. Das mach ich eh schon lang weil ich zu faul bin das Passwort immer einzugeben...

Solange der Daemon gestartet wird - problematisch wird es ja nur dann, wenn der ssh-Daemon kein Autostart drin hat; den telnetd kann man über Telefon einschalten...
(den dropbear/ssh ggf. auch - ich habe es jetzt zumindest als script für dtrace (also per Telefon #97*3* aufrufbar) hinterlegt - allerdings noch nicht getestet:

#!/bin/sh
RC_DAEMON=/mod/etc/init.d/rc.dropbear
if [ "$(${RC_DAEMON} status)" != "running" ]; then
  "${RC_DAEMON}" start
else
  "${RC_DAEMON}" restart
fi

fda77 Mar 26, 2021
Collaborator

Das ursprünglich Problem war ja auch dass man sich am Webif nicht mehr anmelden konnte. Damit hätte man das Script auch nicht mehr anlegen können

Bodenseematze Mar 27, 2021
Author

Ja schon, ich sehe das jetzt eher als "Prävention" für die Zukunft - falls so ein Problem nochmals auftritt hoffe ich, dass ich dann gewappnet bin, den dropbear per Telefon starten zu können... ;-)

Nach Aktualisierung kein Freetz Session-Login mehr möglich #224

Replies: 14 comments · 52 replies

fda77 Mar 11, 2021 Collaborator

Bodenseematze Mar 12, 2021 Author

fda77 Mar 12, 2021 Collaborator

fda77 Mar 15, 2021 Collaborator

fda77 Mar 15, 2021 Collaborator

Bodenseematze Mar 16, 2021 Author

fda77 Mar 16, 2021 Collaborator

Bodenseematze Mar 15, 2021 Author

Bodenseematze Mar 15, 2021 Author

fda77 Mar 16, 2021 Collaborator

fda77 Mar 16, 2021 Collaborator

fda77 Mar 16, 2021 Collaborator

fda77 Mar 16, 2021 Collaborator

fda77 Mar 16, 2021 Collaborator

fda77 Mar 16, 2021 Collaborator

fda77 Mar 16, 2021 Collaborator

fda77 Mar 16, 2021 Collaborator

fda77 Mar 16, 2021 Collaborator

Bodenseematze Mar 16, 2021 Author

Bodenseematze Mar 16, 2021 Author

fda77 Mar 16, 2021 Collaborator

Bodenseematze Mar 16, 2021 Author

fda77 Mar 16, 2021 Collaborator

Bodenseematze Mar 18, 2021 Author

Bodenseematze Mar 18, 2021 Author

fda77 Mar 18, 2021 Collaborator

Bodenseematze Mar 19, 2021 Author

fda77 Mar 19, 2021 Collaborator

Bodenseematze Mar 25, 2021 Author

fda77 Mar 26, 2021 Collaborator

Bodenseematze Mar 27, 2021 Author

Replies: 14 comments 52 replies

fda77
Mar 11, 2021
Collaborator

Bodenseematze Mar 12, 2021
Author

fda77
Mar 12, 2021
Collaborator

fda77 Mar 15, 2021
Collaborator

fda77 Mar 15, 2021
Collaborator

Bodenseematze Mar 16, 2021
Author

fda77 Mar 16, 2021
Collaborator

Bodenseematze
Mar 15, 2021
Author

Bodenseematze Mar 15, 2021
Author

fda77
Mar 16, 2021
Collaborator

fda77
Mar 16, 2021
Collaborator

fda77
Mar 16, 2021
Collaborator

fda77
Mar 16, 2021
Collaborator

fda77 Mar 16, 2021
Collaborator

fda77 Mar 16, 2021
Collaborator

fda77
Mar 16, 2021
Collaborator

fda77
Mar 16, 2021
Collaborator

fda77 Mar 16, 2021
Collaborator

Bodenseematze Mar 16, 2021
Author

Bodenseematze Mar 16, 2021
Author

fda77 Mar 16, 2021
Collaborator

Bodenseematze
Mar 16, 2021
Author

fda77
Mar 16, 2021
Collaborator

Bodenseematze Mar 18, 2021
Author

Bodenseematze Mar 18, 2021
Author

fda77
Mar 18, 2021
Collaborator

Bodenseematze Mar 19, 2021
Author

fda77 Mar 19, 2021
Collaborator

Bodenseematze Mar 25, 2021
Author

fda77 Mar 26, 2021
Collaborator

Bodenseematze Mar 27, 2021
Author