[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

[PeterPawn]

Das kann dann jeder selbst umsetzen ... ich habe mir das mit dem "Sicherheitsproblem" noch einmal durch den Kopf gehen lassen und bin (für mich) zu dem Schluß gekommen, daß es nicht hilfreich ist, eine reine Information, daß man nicht die sichersten Einstellungen, die von der Firmware angeboten werden, verwendet, einfach "zu unterdrücken". Wer die 2FA generell abschaltet (was bei Fernwartung mehr oder weniger verständlich ist), der sollte wenigstens ständig daran erinnert werden.

Zumal ein "unter anderem" ja auch aussagen würde, daß es noch andere "sicherheitsrelevante Einstellungen" gibt, die diese Meldung verursachen könn(t)en - ich habe mir das immer noch nicht (im Rahmen von "modfs") genau angesehen, weil es immer noch keine Release-Version für die 7490 (und andere VR9-Boxen, auf die "modfs" ja in erster Linie zielt) gibt. Aber ich rate mal, daß (hoffentlich) auch die Verwendung von "Kennwortlose Anmeldung" diese Message triggert und vielleicht auch noch ein paar weitere Bedingungen ... die jetzt mit einem Patch alle auf einen Schlag "totzulegen" (wenn meine Annahme stimmen sollte, daß AVM da nicht nur die eine Bedingung berücksichtigt), wäre in meinen Augen wieder wenig hilfreich.

Zumal es auch kein Problem ist, mit einer VPN-Verbindung und einer Shell auf der Box (alles Dinge, die man sowohl mit "modfs" als auch mit Freetz[-NG] realisieren kann) die 2FA nur dann zu deaktivieren, wenn das tatsächlich für irgendwelche Wartungsarbeiten erforderlich ist. Aktiviert man die hinterher auch wieder, verschwindet die Fehlermeldung ebenso.

Daher wird's von mir so einen Patch doch nicht geben (entgegen der früheren Aussage in dem oben verlinkten Beitrag) - wo man das ändern könnte, kann man sich im Freetz-NG-Patch ja ansehen und dann eben selbst umsetzen. Da das Abschalten der 2FA letztlich die Sicherheit des gesamten FRITZ!OS - unnötigerweise - verringert, möchte ich niemanden dabei unterstützen (deshalb würde ich auch kein entsprechendes "modscript" von dritter Seite in "contrib" aufnehmen) - wer das tatsächlich für notwendig hält (und AVM läßt es ja auch zu, weil es sicherlich in Sonderfällen auch gute Gründe geben mag), der sollte auch mit der entsprechenden Warnung im GUI leben können, denn die tut ja niemandem wirklich weh, sondern weist nur darauf hin, daß da etwas faul sein könnte.

Das ist - für mich - auch der Unterschied zu der "Vom Hersteller ..."-Meldung - die ist "reine Schikane", weil sie eben keine sicherheitsrelevanten Probleme signalisiert und auch nicht ohne weiteres wieder "gelöscht" werden kann (wobei das "clear_id 87" nach der Verwendung von "ar7login" - und nur dann ist das noch relevant, weil die anderen Bedingungen (u.a. die Installation unsignierter Firmware) von AVM mittlerweile ohnehin gesperrt sind - ohnehin zum "Standard-Repertoire" gehören sollte bzw. man das auch nur dann aufrufen kann, wenn das "tainted"-Flag im TFFS-Node 87 gesetzt ist), was das Ausblenden im GUI wieder legitim erscheinen läßt für meine Begriffe.

Wenn aber Erweiterungen/Änderungen den Betrieb einer FRITZ!Box (dauerhaft) unsicherer machen, sollte man als Besitzer die Notwendigkeit dieser Änderungen ständig neu hinterfragen. Es gibt ja auch gute Gründe, warum ich zwar gegen die (permanente) Verwendung des "telnetd" argumentiere und gleichzeitig dessen Aktivierung ermögliche - aber eben nicht als permanent gestarteten Dienst, der vom Besitzer dann gar nicht mehr zu stoppen/abzuschalten ist, sondern als "on demand"-Dienst, den man per Telefon starten kann und den man danach dann auch wieder stoppen sollte. Wer permanenten Shell-Zugang will/braucht, sollte sich eher auf einen SSH-Server auf der Box verlegen - ein aktueller "dropbear" mit ED25519-Auth ist beim Login ab VR9 nur noch unmerklich langsamer, als ein Telnet-Zugang und bietet mit einem SFTP-Server auch gleich noch einen zuverlässig geschützten, externen Zugriff auf das Dateisystem.

 

[eisbaerin]

Wer die 2FA generell abschaltet, der sollte wenigstens ständig daran erinnert werden.

Da stehe ich voll hinter dir.

Aber ich rate mal, daß (hoffentlich) auch die Verwendung von "Kennwortlose Anmeldung" diese Message triggert

IMO nicht, denn die Bedingung für die Anzeige lautet:

if (data.fritzos.twofactor_disabled || data.fritzos.ipphone_from_outside) {

die 2FA nur dann zu deaktivieren, wenn das tatsächlich für irgendwelche Wartungsarbeiten erforderlich ist

Hättest du dafür bitte auch gleich noch den richtigen Befehl.

 

[PeterPawn]

Hättest du dafür bitte auch gleich noch den richtigen Befehl.

https://www.ip-phone-forum.de/threa...-confirmation-of-settings.297158/post-2246969 - das sollte nach meiner Info immer noch funktionieren (ich brauche es halt auch nicht ständig und mit einer 07.19/07.20 habe ich es nicht getestet).

Die Herausforderung (ohne passende Werkzeuge, wie z.B. "tvi" (https://github.com/PeterPawn/YourFritz/blob/master/tffs/fritzos_scripts/tvi), was auch den Neustart des "ctlmgr" noch ausführen würde, wenn man das möchte) ist das korrekte Editieren der "ar7.cfg" - was dabei zu beachten ist, damit das wirklich zuverlässig klappt, habe ich mehrfach beschrieben.

Ob anderslautende Erfahrungsberichte jetzt zuverlässig reproduzierbare Ergebnisse liefern oder nicht, möge jeder selbst testen und dann entscheiden. Ich empfehle an dieser Stelle immer das Löschen des Inhalts der "ar7.cfg" und das nachfolgende Stoppen des "ctlmgr" nach irgendeiner zusätzlichen Änderung von Einstellungen (damit der "ctlmgr" beim Beenden einen Grund hat, die intern gespeicherten Einstellungen neu zu schreiben) - in meinen Augen ist der dann (üblicherweise) eintretende Erfolg, daß die "ar7.cfg" wieder in alter Schönheit erstrahlt, der beste Beleg dafür, daß der "ctlmgr" diese Einstellungen intern zwischenspeichert und man deshalb die passende Reihenfolge bei Änderungen an der "ar7.cfg" einhalten sollte.

IMO nicht, denn die Bedingung für die Anzeige lautet:

OK, dann ist das derzeit offenbar nicht so. Aber das ändert meine grundsätzliche Einstellung an diesem Punkt auch nicht ... denn wenn sich AVM zur Ausweitung der getesteten Bedingungen entschließen sollte, ist ein Patch (etwas abhängig davon, wie man den umsetzt) häufig immer noch aktiv und wirksam und blendet dann auch diese zusätzlichen Bedingungen (im schlechtesten Fall) sauber aus.

 

[eisbaerin]

das sollte nach meiner Info immer noch funktionieren

Bestimmt.
Ich dachte du hättest einen einzigen Befehl, der gleich mit "ctlmgr w" beginnt und das ändert.

 

[PeterPawn]

der gleich mit "ctlmgr w" beginnt und das ändert.

Auch den gibt's: ctlmgr_ctl w boxusers settings/twofactor_auth_enabled {0|1} - wie weit das funktioniert, kann ich im Moment nicht testen. Aufgrund von geänderten Einstellungen (bei mir ist in "ptest" etwas gesetzt (und ja, natürlich absichtlich), was da normalerweise nicht steht) arbeitet der "ctlmgr" bei mir etwas anders:

Sep  1 12:53:12 ctlmgr[2463]: ar7.cfg wird nicht gespeichert, da PTEST_SERVER aktiv ist

und ich kann nicht sicher sagen, wie das aussieht, wenn die Änderungen an der "ar7.cfg" tatsächlich gespeichert werden.

Wenn ich mich richtig erinnere, mußte früher zumindest die Session in der FRITZ!Box neu gestartet werden oder sogar der "ctlmgr", damit die Änderung wirksam wurde - denn letztlich macht das GUI ja auch nichts anderes, als diese Einstellung zu setzen und ein Umgehen war (zumindest wieder früher, als die 2FA aufkam, was so bei 06.8x gewesen sein müßte) beim Abschalten der 2FA nicht machbar.

EDIT: Es sieht fast so aus, als ließe sich die Einstellung per CLI tatsächlich auch ohne weitere Kopfstände setzen (113.07.19-irgendwas jenseits der 80000) ... wobei man auch mal festhalten sollte, daß das Abschalten der 2FA - zumindest für Besitzer eines Android-Smartphones, auf dem sich die Google-Authenticator-App installieren läßt - gar nicht mehr erforderlich ist, selbst wenn man niemanden vor Ort mit dem Wählen einer Ziffernfolge oder dem Drücken eines Buttons beauftragen kann. Auch das hat AVM ja mittlerweile nachgerüstet ... ich weiß nicht mal genau, seit welcher Version oder ob das erst mit dem nächsten Release (bzw. der aktuellen Labor-Version) funktioniert.

 

[eisbaerin]

ctlmgr_ctl w boxusers settings/twofactor_auth_enabled {0|1}

Danke, das probiere ich mal und berichte.

EDIT:
Geht super mit 7580_07.19-80459 BETA!
Mit dem Befehl ändern, danach unbedingt in der GUI ausloggen und wieder einloggen.

 

[PeterPawn]

Ich habe das gerade mal mit dem Google Authenticator gecheckt - erstens gibt's den natürlich auch für iOS oder Windows und zweitens klappt damit das Authentifizieren einwandfrei - auch wenn's hinter dem Link versteckt ist in der "Abfrage" ... das könnte man bei AVM sicherlich auch noch besser machen, wenn es sich um ein Konto mit aktiviertem GA handelt.

Es gibt also (fast) keinen Grund mehr, die 2FA abzuschalten. Zwar setzt der GA eine funktionierende Internetverbindung voraus (zumindest müßte er das nach meinem Kenntnisstand), aber die sollte bei einem Versuch der "Fernwartung" ja ohnehin vorhanden sein bei der zu bedienenden FRITZ!Box - ansonsten klemmt's schon deutlich vor der 2FA.

 

[eisbaerin]

Ich habe meinen letzten Beitrag noch ergänzt.

Es gibt also (fast) keinen Grund mehr, die 2FA abzuschalten.

Bei der 7272, 7390 und 7412 muß man es aber noch machen.

Aber jetzt habe ich eine Möglichkeit es schnell mal auszuschalten und kann es somit nach Jahren überhaupt erst mal wieder einschalten.
Danke!

 

[koyaanisqatsi]

Moinsen


Es ist ja auch so, dass nach einmaliger "Bestätigung" andere "bestätigungsabhängige" Aktionen ohne nochmalige "Bestätigung" möglich sind.
...solange sich die SID nicht ändert, für eine gewisse Zeit, die ich aber nicht kenne.

Aber eine einfache ( von Extern ) Möglichkeit der temporären Deaktivierung begrüße ich durchaus, da sie ja ebenso einfach wieder aktiv geschaltet werden kann und soll(te).

 

[fda89]

Wenn man die Abfrage remote einfach deaktivieren kann, kann das durch eine Sicherheislücke jeder

 

[PeterPawn]

Um so wichtiger vielleicht, daß das dann nicht einfach verschwiegen wird?

Ich war/bin auch etwas erstaunt, daß eine Deaktivierung der 2FA so ohne weiteres mit einer einzelnen Einstellung machbar ist - das war (iirc) früher anders (vielleicht sogar besser), das hatte ich jedenfalls damals gleich getestet, als die 2FA in der Firmware auftauchte.

Zwar ging es mit der Änderung der "ar7.cfg" und dem Restart des "ctlmgr" dann doch (wie ich es im weiter vorne verlinkten Beitrag beschrieben hatte), aber da war dann die Shell schon die eigentliche Hürde und wer einen "echten" Shell-Zugang erhalten kann, dem stehen ohnehin noch weitere Möglichkeiten offen.

Die Frage wäre also, wie groß eine "command injection"-Lücke sein müßte, damit man am Ende ein "ctlmgr_ctl" aufrufen kann - ggf. auch erst über eine nachgeladene Shell-Datei. Solange die nicht existiert, betrachte ich die Reduktion der "Abschaltung" auf eine einzelne Einstellung als "läßliche Sünde", auch wenn es natürlich nicht wirklich schön und sicher ist. Zumindest bei der Änderung über "ctlmgr_ctl" (oder auch über das Lua-Interface des "ctlmgr") sollte man sicherlich prüfen, ob die aktuelle Session über die 2FA autorisiert wurde.

Wenn dabei dann der Weg der "händischen Änderung" an der "ar7.cfg" - also am "ctlmgr" vorbei - weiterhin gangbar bleibt, ist das m.E. zu vernachlässigen, da die Komplexität der notwendigen Aktionen und ihre Reihenfolge eine deutlich höhere Hürde bilden, als die einfache Ausführung eines "ctlmgr_ctl" (oder die Benutzung des Lua-Interfaces).

 

[tacitus-nrw]

Geht der Telnet mit FritzOS 7.21 auf der 7490 nicht mehr? ModFS hat zumidest keine Fehler geliefert, und das Aktivieren des Startens habe ich hinzu gefügt.

Habe mod_telnet_enable aus dem Ordner inactive in den modscripts Ordner verschoben und die Rechte mit chmod 754 mod_telnet_start korrekt gesetzt.

Dann das modscript aufgerufen, und es werden deim Einbauen und aktivieren von Telnet auch KEINE Fehler gemeldet.


Ausgabe

root@Fritzbox7490:/var/media/ftp/SanDisk-Ultra-11# ./modfs update FRITZ.Box_7490-07.21.image
respawn script with custom BusyBox shell, SHLVL=2
/var/media/ftp/SanDisk-Ultra-11/bin/185/busybox sh ./modfs update FRITZ.Box_7490-07.21.image
Using debug mode with a 64 KB buffer (new format)


Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK
Überprüfen des verfügbaren Swap-Space ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.


.....
.....

Die Modifikation 'remove affected swap space before stopping USB devices' wurde angewendet, Fehlercode = 0.

Die Modifikation 'enable telnet daemon' wird verarbeitet ...
Überprüfen der Voraussetzungen für die Modifikation ... OK
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'enable telnet daemon' mit folgender Beschreibung
Busybox-Symlink für den Telnet-Daemon erstellen
angewendet werden? (j/N) j
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'enable telnet daemon' wurde angewendet, Fehlercode = 0.

Die Modifikation 'always start telnet daemon' wird verarbeitet ...
Überprüfen der Voraussetzungen für die Modifikation ... OK
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'always start telnet daemon' mit folgender Beschreibung
Telnet-Daemon automatisch beim Systemstart aktivieren, egal was an anderen Stellen eingestellt wurde
angewendet werden? (j/N) j
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK
Die Modifikation 'always start telnet daemon' wurde angewendet, Fehlercode = 0.

Die Modifikation 'volatile storage on NAS' wird verarbeitet ...


Überprüfen der Voraussetzungen für die Modifikation ... OK
Überprüfen der unterstützten Sprachen ... OK
......


Die Modifikation 'add YourFritz key' wurde angewendet, Fehlercode = 0.

Das ist die letzte Chance zum manuellen Modifizieren des Dateisystems in folgendem Verzeichnis: /var/media/ftp/SanDisk-Ultra-11/2837/squashfs-root
Die Eingabetaste drücken, um mit dem Packen des neuen root-Dateisystems zu beginnen
oder 'q' eingeben, um die letzte Möglichkeit zum Abbruch zu nutzen :
Packen des neuen root-Dateisystems ... OK
Erstellen eines neuen 'äußeren Dateisystems' ... OK
Kopieren des neuen root-Dateisystems in die inaktive Dateisystem-Partition ... OK
Kopieren des neuen Kernel-Images in die Zielpartition ... OK
Festlegen des alternativen Systems als aktives System beim nächsten Start der Box ... OK
Das neue root-Dateisystem wurde erfolgreich in die inaktive Partition kopiert.


Beim nächsten Start der Box wird das System in den alternativen Partitionen benutzt.

Sollte beim Start ein Problem auftreten, kann man leicht wieder über den Bootloader auf das hier verwendete System umschalten.

Eine kurze Anleitung, wie das in einer FTP-Sitzung zum Bootloader funktioniert, ist in der Datei BOOTSELECTION.ger enthalten.

[Edit Novize: Log in Code-Tags gepackt]


Ende
Alles ohne Fehler, auch sind die anderen Modifikationen gemacht, aber Telnet läuft nicht.

Gruß
Friedhelm

 

[eisbaerin]

Geht der Telnet mit FritzOS 7.21 auf der 7490 nicht mehr?

Bei mir geht es.

 

[PeterPawn]

Ich habe bisher nur überprüft, daß die BusyBox weiterhin das "telnetd"-Applet enthält und den Test auf die Existenz des Symlinks "/usr/sbin/telnetd" und daß der "telefon"-Daemon weiterhin die Zeichenketten zum Start des Telnet-Daemons enthält. Alles andere (bis hin zu "CONFIG_RELEASE=0" für den "Inhouse-Modus" des "telefon"-Daemons) habe ich mit der Release-Version noch nicht geprüft - es würde mich aber auch sehr wundern, wenn AVM hier von den letzten Labor-Zuckungen zum Release noch einmal etwas über den Haufen geworfen hätte - zumindest wäre das untypisch und das Applet inkl. Link-Prüfung schleppt man ja nun auch schon seit der 6320/6360 und der "Abschaffung" allgemein in der 06.2x mit sich herum.

Was natürlich nicht länger funktionieren KANN, ist die Verwendung von "mod_telnet_start" ... immerhin erstellt das nur eine Datei unter "/etc/init.d/S85-apps" (bzw. eine zusätzliche Zeile darin) und da das gesamte Startsystem ja auf "supervisor" umgestellt wurde (steht alles weiter vorne - auch in diesem Thread), wird die naturgemäß ignoriert.

Wer den Service "für ständig" starten will und auf das Telefon dabei verzichten möchte, der muß sich halt ein passendes Service-File erstellen (unter "/lib/systemd/system/...") und den Telnet-Daemon von dort aus starten. Die "mod_rc_tail.sh" enthält ein Beispiel, wie so etwas aussehen könnte - dort wird dann die "rc.user" über ein solches "service"-File zur Ausführung gebracht.

Da ich die "mod_telnet_start" (nicht zu verwechseln mit der "mod_telnet_enable") ohnehin nur als (altes) Beispiel drin gelassen habe, habe ich auch nicht die Absicht, diese "allgemein" zu ändern - ein ständig laufender Telnet-Server ist ein Security-Albtraum und das muß man ja nicht forcieren (bzw. das will ich persönlich nicht unterstützen) - zumal eben die Vorgehensweise, wenn man das - allen Warnungen zum Trotz - unbedingt so haben will, auch hier mehrfach beschrieben wurde.

 

[bmaehr]

Auf einer 7490 läuft es auch ohne USB-Speicher

Das ist anscheinend nicht mehr korrekt.

Mit einem eingesteckten USB-Stick und den Befehlen

dd if=/dev/zero of=/var/media/ftp/ESD_USB/swapfile bs=1M count=600
chmod 600 /var/media/ftp/ESD_USB/swapfile
mkswap /var/media/ftp/ESD_USB/swapfile
swapon /var/media/ftp/ESD_USB/swapfile

hat aber die Installation von 7.21 auf der 7490 einwandfrei geklappt.
Telnet geht.

 

[PeterPawn]

Das ist anscheinend nicht mehr korrekt.

Das ist wahr ... und ich habe #1 auch tatsächlich nicht aktualisiert, wenn das dort immer noch so steht (vermutlich irgendwo weiter hinten im Text von #1?).

Aber ausführlich beschrieben und begründet (für manchen Geschmack sogar wieder zu ausführlich) habe ich das trotzdem: https://www.ip-phone-forum.de/threa...nand-basierte-fritz-boxen.273304/post-2299406 und irgendwo findet sich garantiert auch meine Erklärung/mein Vorschlag, wie man am besten mit dem nunmehr notwendigen Swap-Space umgeht (vermutlich hilft "swapon" oder "fdisk" bei der Suche - in diesem Thread und in Kombination mit mir als "Von:").

Denn ich empfehle ja eher die Verwendung einer Swap-Partition, weil die vom FRITZ!OS beim Start automatisch gemountet wird - auch wenn das Dismount (bzw. das "swapoff") beim Auswerfen mit AVM-Firmware nicht implementiert ist (ob sich das geändert hat mit der 07.21, muß ich erst mal schauen - bei der Labor-Reihe war es noch "wie früher") ... aber dafür gibt es ja ein passendes "modscript".

Beschrieben ist das - unter anderem - auch noch einmal hier: https://www.ip-phone-forum.de/threa...nand-basierte-fritz-boxen.273304/post-2295063 ... und guck mal, wer da den nächsten Beitrag verfaßt hat.

BTW ... (ich habe es auch erst jetzt mitbekommen, aber) @eisbaerin hat in diesem Thread: https://www.ip-phone-forum.de/threads/how-to-modfs-die-gebrauchsanleitung.284778 in diesem Jahr noch Änderungen/Ergänzungen vorgenommen (ich habe noch nicht alles gelesen), die auch einige der von mir vorgenommenen Änderungen am "modfs" abdecken, deren "Einführung" hier im Thread etwas "versteckt" sein mag, wenn man ihn nicht regelmäßig verfolgt hat.

 

[Micha0815]

Das ist anscheinend nicht mehr korrekt.

Korrekt , es wurde allerdings ausführlich erläutert.

Nachtrag: War ich wohl zu langsam

Wegen der gestiegenen Größe der Firmware-Images seit 07.19, habe ich auch die Speicherplatzangaben in "modfs" deutlich nach oben korrigiert ... eine Ausführung mit "reinem NAS-Flash" wird damit eher nicht mehr funktionieren (nur die Puma-Geräte hätten bisher genug NAS-Speicher, um das darin abzuwickeln). Auch wenn man die Möglichkeit mit dem "ext3"-Image über das Loop-Device eigentlich nicht mehr nutzen sollte (damit kann ja auf einem Dateisystem, was keine Linux-Flags versteht, auch entpackt und neu gepackt werden), habe ich das mal auf ein 256 MB-Image erweitert.

Mit einem passenden USB-Stick (inkl. Swap-Partition und ext2/ext3/ext4 für die Daten - etwas anderes kennt dann das FRITZ!OS nicht unbedingt) sollte das jedenfalls auch weiterhin für 07.19 funktionieren ... eine Unterscheidung zwischen 07.19 und älteren Versionen hinsichtlich der Anforderungen an den bereitzustellenden Speicherplatz wollte ich jetzt nicht noch treffen, daher "leiden" eben die älteren Versionen und Boxen jetzt einfach mit.

LG
-Ein Teil abgetrennt und verschoben-

 

[tacitus-nrw]

Habe den Telnet bei der 7.21 nicht hinbekommen, obwohl das ModFS Script alles als ok meldete, auch die Telnet Anteile, alles andere ging aber. Bin nun aber auf Freetz NG umgestiegen, weil der IP sec im Fritz OS 7.21 noch langsamer geworden ist, und mit 2,5 Mbit Durchsatz unbrauchbar ist. Mit Freetz NG kann man Wireguard einbauen, und man kommt auf 20 Mbit Durchsatz im VPN. Außerdem ist der ssh Daemon schon drin, den habe ich sonst nach ModFS ja noch einbauen müssen, damit Ssh und scp geht und Telnet ausgeschaltet werden kann. Anmerkung: Der Telnet war beim ModFS Ausführen auf dem laufenden Image deaktiviert gewesen, war ja mit ssh drauf. Kann das die Ursache sein, dass der Telnet nach dem Update partout nicht startete?

 

[PeterPawn]

Kann das die Ursache sein, dass der Telnet nach dem Update partout nicht startete?

Was natürlich nicht länger funktionieren KANN, ist die Verwendung von "mod_telnet_start"

Ich dachte, ich habe das oben schon aufgezeigt, wo das Problem hier wohl liegt.

Denn anders als in #1792 beschrieben, steht "mod_telnet_enable" (https://github.com/PeterPawn/modfs/blob/master/modscripts/mod_telnet_enable) ja gar nicht in "inactive" - da steht nur "mod_telnet_start" (https://github.com/PeterPawn/modfs/blob/master/modscripts/inactive/mod_telnet_start), was auch mit der Anzeige für dieses "modscript" im Protokoll in #1792 korrespondiert (https://github.com/PeterPawn/modfs/blob/master/modscripts/inactive/mod_telnet_start#L4). Und warum das ab 07.19 nicht länger funktioniert, habe ich in #1794 erklärt.

Ein SSH wird wohl demnächst doch noch von mir angeboten (nachdem Dropbear jetzt ED25519 beherrscht, macht das auch Sinn, weil es performant sein kann) - allerdings will ich den Dropbear (in der "YourFritz"-Version) erst noch so patchen, daß der (a) die Benutzerverwaltung des FRITZ!OS für das Login benutzen kann, denn es macht ja keinen Sinn, da zwei verschiedene Implementierungen parallel zu verwenden und so kann man wenigstens das Henne-Ei-Problem bei der Verwendung von "pubkey-auth" entschärfen, wenn sich Admin-Konten erst einmal per Benutzername/Kennwort einloggen können und das eben gerade kein "Standardkonto" mit einem vordefinierten Kennwort ist.

Und (b) soll der SFTP-Server (auch wenn der aus dem OpenSSH-Paket stammt) die Berechtigungen für Benutzer, die keine Administratoren sind, anhand der "libavmacl2.so" überprüfen und die dann auch auf alles unterhalb von "/var/media/ftp" beschränken, damit auch da keine zweite Verwaltung von Berechtigungen benötigt wird und man das dann anstelle von FTP und Samba (was ich ab 07.19 ohnehin nicht mehr verwenden würde) einsetzen kann.

 

[tacitus-nrw]

Cool. . Dann wäre mit Modfs alles auf Anhieb drin, was man braucht.