Es ist schon ein bisschen witzig
Meine Aussage, die Du dort zitierst, bezog sich ja eindeutig darauf, daß ich keine Alternative
zu dem bisher bereits von mir Bereitgestellten wüßte, die einigermaßen generisch wäre. Ich gehe natürlich (und in meinen Augen auch zurecht) davon aus, daß man - wenn man sich mit "modfs" befaßt - auch die bisher von mir dafür bereitgestellten Modifikationen und meine Erläuterungen dazu in seine Recherchen einbezieht.
-----------------------------------------------------------------------------------------------------------------
Mir wäre allerdings SSH lieber
Niemand sollte Dich davon abhalten können ... die Binaries für einen SSH-Server in der FRITZ!Box gibt es sogar wieder in "yf_bin" bereits "vorkompiliert" und wer kein Linux-System auf einem PC hat, kann seine FRITZ!Box als "first stage build host" benutzen und sich dort das passende SquashFS-Image zusammenpacken lassen.
Warum gibt es von mir kein "fertiges" SSH-Paket? Auch die Frage habe ich bereits mehrfach beantwortet. Da ich generell gegen die Verwendung von Kennwörtern beim SSH-Zugriff bin, sind die von mir bereitgestellten Binärdateien (konkret hier "dropbearmulti") so modifiziert, daß sie nur die schlüsselbasierte Authentifizierung zulassen:
https://github.com/PeterPawn/YourFreetz/commit/29d81c6c019550ef7c930891af1c538a8eac21cf - für den Host-Key wird dabei das ohnehin vorhandene FRITZ!Box-Zertifikat benutzt. Die öffentlichen Schlüssel, denen der Zugriff erlaubt sein soll, muß man aber noch irgendwie selbst auf die Box bringen - und das ist auch genau der Teil, der in einer generischen Lösung gar nicht funktionieren KANN, denn schließlich sollte jeder sein eigenes Schlüsselpaar haben.
Da es auch nicht ganz trivial ist und obendrein noch vom Modell der verwendeten FRITZ!Box abhängt, wo und wie man diese Schlüssel so speichert, daß sie (a) änderbar (sofern man das möchte) und (b) trotzdem vor unbefugtem (Schreib-)Zugriff sicher sind, gibt es dazu zwar auch "Empfehlungen" meinerseits, aber ebenfalls keine "allgemeingültige Lösung". Das fängt nämlich bereits damit an, daß man sich erst einmal überlegen muß, wo und wie man nun das Home-Verzeichnis (i.d.R. bei einer FRITZ!Box halt nur für den "root"-Benutzer, denn es macht nur wenig Sinn, auf die AVM-Benutzerverwaltung noch eine eigene aufzupropfen) anlegt und ob das dann eine persistente Speicherung von Dateien ermöglicht oder nur volatile Daten enthalten sein sollen. Man kann den eigenen öffentlichen Key ja auch einfach in eine "authorized_keys"-Datei in "/etc" packen und dann diese nur noch in das auserwählte Home-Verzeichnis kopieren (natürlich im Unterverzeichnis ".ssh", aber das sieht man ja auch in den Optionen, mit denen "dropbear" von mir erzeugt wurde).
Wenn man sich das "
rc.shellinaboxd" als Vorlage nimmt und darin beim Start des SSH-Servers einfach aus einem "inline"-File (aka "here document") eine "authorized_keys" an der richtigen Stelle erstellt, die den eigenen (öffentlichen) Key enthält, ist das auch nur
eine weitere, denkbare Lösung ... denn dann muß man wieder dafür sorgen, daß das eigene (Customizing.-)Image an einer Stelle liegt, wo definitiv niemand mit NAS-Zugriffen das gesamte Image austauschen kann.
Aber genau für solche Fälle gibt es ja wieder eine passende Option im "modfs" (die steht dann auf der Seite NACH dem von Dir inzwischen offenbar gelesenen Beitrag #644 - deshalb kann und will ich es auch niemandem ersparen, sich tatsächlich den Thread durchzulesen, auch wenn die Nummern - dank des Löschens einiger Beiträge durch ihre Autoren - nicht immer 100% stimmen) ... mit dieser kann man beim Installieren eines Systems im derzeit inaktiven Partitionset auch gleich noch weitere Dateien in die "wrapper"-Partition schreiben lassen und diese ist dann eben nicht ohne weiteres über NAS-Zugriffe zu erreichen und damit auch relativ sicher vor Manipulationen bzw. wer bis zu diesem Punkt käme, hätte auch noch andere Möglichkeiten.
Da sich "dropbear" auch nicht daran stört, wenn die "authorized_keys"-Datei über einen Symlink irgendwo anders hinzeigt, kann man den Inhalt der Datei auch wieder an vielen verschiedenen Orten speichern ... bis hin zum SquashFS-Image für das "rootfs", wo er dann - per Definition - unveränderlich wäre.
Die Vor- und Nachteile der jeweiligen Speicherung sollte ich bei "E99-custom" auch bereits erläutert haben - bei einer 7490 kann man z.B. auch einfach eine Datei unter "/var/flash" verwenden, denn auch die ist (a) nicht von außen zu lesen oder zu schreiben und (b) bei der 7490 sogar persistent - bei anderen VR9-Modellen aber nicht (das ist die "config"-Partition und deren Handling ist bei AVM einigermaßen undurchsichtig - aber nur, wenn man über unterschiedliche Modelle vergleicht, innerhalb eines Modells war das bisher ziemlich "stabil").
Es gibt nun mal an dieser Stelle so viele unterschiedliche Möglichkeiten (die alle ihre Berechtigung bzw. ihre Vor- und Nachteile haben), daß ich mich nicht für eine einzelne entscheiden WILL ... wer auf einer FRITZ!Box mit einer Shell umgehen möchte, der sollte m.E. auch in der Lage sein, diese - nun wirklich eher simplen - Shell-Befehle für den Start eines SSH-Daemons in ein passendes rc-Skript zu klöppeln - ansonsten sollte er besser auf den Shell-Zugang komplett verzichten.
Ich erwarte ja schon gar nicht mehr, daß die Leute sich die Binaries selbst erstellen (obwohl es Freetz eben schon seit Jahren gibt) ... mit meiner Bereitstellung aktueller Dateien inkl. passender "Unterschrift" wollte ich u.a. auch die älteren Quellen "austrocknen", bei denen es weder aktuelle Versionen noch irgendeine Form der Sicherung der Authentizität einer Datei gab - und das für Binaries, die die Leute am Ende auf ihren Systemen einfach starten (sollen).
Ich bin ja zur Unterstützung bis zu einem gewissen Punkt durchaus auch bereit - aber irgendwann muß der Motor nach dem Anschieben (ja, ich bin so alt, daß das zu meiner Zeit noch funktionierte bei PKWs) auch mal anspringen und von selbst weiterlaufen ... ich habe nicht die Absicht, bis zur nächsten Tankstelle zu schieben, weil jemand die entsprechende Anzeige nicht im Auge haben WILL oder sie einfach ignoriert.
Im Klartext ... ich habe nicht die Absicht, anderen alles bis ins Kleinste "vorzukauen", sondern ich erwarte einfach, daß man sich (bei Interesse) damit auch selbständig befaßt.
Bei mir gibt es z.B. folgende "Zusätze" bei jedem "modfs"-Lauf, die auch alle nur mit den Mitteln arbeiten, die ich im Rahmen von "modfs" auch allen anderen zur Verfügung stelle:
- ich tausche die BusyBox von AVM immer gegen meine eigene, statisch gelinkte aus (auch die steht in "yf_bin") - der zusätzliche Platzbedarf juckt mich dabei kein Stück, die Gewißheit, die notwendigen Applets dann über "busybox <cmd>" aufrufen zu können, ist mir das allemal wert
- ich füge weitere öffentliche Schlüssel hinzu, damit ich die installierte Firmware über weitere Images (analog zu DECT-Updates) erweitern kann, wenn das notwendig ist (damit kann ich solche Images halt selbst signieren)
Diese beiden Schritte sind ganz simpel zu erledigen, dazu braucht es lediglich in "files" eine Datei "binaries_<hwrevision>_<kernel_version>.tgz" mit dem folgenden Inhalt:
Code:
root@FB7490:/var/media/ftp/YourFritz/modfs $ tar -tvf files/binaries_113_3.10.107.tgz
drwxr-xr-x root/root 0 2019-06-27 11:44:50 bin/
-rwxr-xr-x 1000/1001 1237428 2019-06-27 11:45:14 bin/busybox
drwxr-xr-x root/root 0 2016-07-03 23:25:35 etc/
lrwxrwxrwx root/root 0 2017-04-22 11:20:57 etc/avm_firmware_public_key9 -> /wrapper/etc/firmware_signing_1.key
lrwxrwxrwx root/root 0 2017-04-22 11:20:56 etc/avm_firmware_public_key8 -> /wrapper/etc/firmware_signing_2.key
drwxr-xr-x root/root 0 2016-04-09 23:01:25 lib/
drwxrwx--- root/root 0 2016-06-04 06:16:16 usr/
drwxrwx--- root/root 0 2016-04-13 04:39:49 usr/bin/
root@FB7490:/var/media/ftp/YourFritz/modfs $
und die Anwendung von "copy_binaries" als "modscript" - alles kein Hexenwerk und anhand der Datumsangaben kann man auch sehen, daß sich darin praktisch nur die BusyBox an und an mal ändert ... der Rest ist "stabil".
- ich füge Symlinks für ein paar zusätzliche Start-Skripte in "/etc/init.d" ein, diese Symlinks verweisen auf Dateien in der YAFFS2-Partition des laufenden Systems
- es wird ein zusätzlicher "hook" für "onlinechanged" installiert
- in jedem Branding wird ein zusätzliches Verzeichnis "custom" im GUI-Baum installiert
Das alles macht ein einzelnes, zusätzliches "modscript", das ich unter "contrib/custom/modscripts/mod_custom" abgelegt habe (ich verwende das anstelle des "mitgelieferten" "mod_custom") und das - ohne den Kram drumherum - die folgenden Befehle als Quintessenz enthält:
Code:
ln -s /wrapper/etc/init.d/E99-custom $check_filename
ln -s /wrapper/etc/init.d/S02-config $rootdir/etc/init.d/S02-config
ln -s /wrapper/etc/init.d/S03-early-syslogd $rootdir/etc/init.d/S03-early-syslogd
ln -s /wrapper/etc/init.d/S03-path $rootdir/etc/init.d/S03-path
ln -s /wrapper/etc/init.d/S20-config $rootdir/etc/init.d/S20-config
ln -s /wrapper/etc/init.d/S50-rdate $rootdir/etc/init.d/S50-rdate
sed -e "s|^\(find /etc/onlinechanged/\.\) -\(type.*\)\$|\1 /var/custom/etc/onlinechanged/. -\2|" -i $rootdir/bin/onlinechanged
for TARGET_BRANDING in $TARGET_BRANDINGS; do
ln -s /var/custom/usr/www/custom $rootdir/usr/www/$TARGET_BRANDING/custom
done
ln -s /var/media/ftp $rootdir/nand
Da wird also fast alles erst einmal nach "/wrapper" (also in die YAFFS2-Partition des laufenden Systems) umgebogen ... wenn es irgendwo anders liegen soll, kann man das von dort ja weiterleiten. Wie man auch sehen kann, wird alles das, was nicht nach "/wrapper" geht, dann wieder unter "/var/custom" "verortet" und das ist nun mal genau der Pfad, mit dem fast alle von mir bereitgestellten Binaries kompiliert wurden - kann man alles im "YourFreetz"-Repo im "YourFritz"-Branch nachlesen.
Wie kommen nun die Dateien nach "/wrapper"? Ganz einfach ... denn dafür gibt es ja den Beitrag #661 und das dort beschriebene "ADD_TO_WRAPPER". In meinem "modfs"-Tree gibt es dafür dann das Verzeichnis "atw_3.10.107" mit folgendem Inhalt:
Code:
root@FB7490:/var/media/ftp/YourFritz/modfs $ find atw_3.10.107/
atw_3.10.107/
atw_3.10.107/etc
atw_3.10.107/etc/firmware_signing_1.key
atw_3.10.107/etc/custom_config.conf
atw_3.10.107/etc/init.d
atw_3.10.107/etc/init.d/S03-path
atw_3.10.107/etc/init.d/S20-config
atw_3.10.107/etc/init.d/E99-custom
atw_3.10.107/etc/init.d/S02-config
atw_3.10.107/etc/init.d/S03-early-syslogd
atw_3.10.107/etc/init.d/S50-rdate
atw_3.10.107/custom.custom
atw_3.10.107/config
atw_3.10.107/config/custom.tar.xz
atw_3.10.107/bin
atw_3.10.107/bin/custom_config
atw_3.10.107/bin/custom_config/link_to_export
atw_3.10.107/bin/custom_config/initialize
atw_3.10.107/bin/custom_config/shutdown
atw_3.10.107/bin/custom_config/writer
atw_3.10.107/bin/custom_config/yourfritz_helpers
atw_3.10.107/bin/custom_config/monitor
atw_3.10.107/bin/custom_config/lazy_countdown
root@FB7490:/var/media/ftp/YourFritz/modfs $
Da weden also in erster Linie die vorher verlinkten Start-Dateien übernommen (deren Inhalt ist erst mal egal), die Signatur-Keys kopiert und - das ist wieder wichtig - eine "custom.custom"-Datei (ein SquashFS-Image mit meinen "Standarderweiterungen" - bis hin zum "Midnight Commander") in das neu installierte System kopiert. Bis auf den "custom_config"-Teil (den ich zwar auch mal hier irgendwo veröffentlicht hatte, der ist aber nicht mehr aktuell, weil sich beim "notifyfs" etwas geändert hat) ist das alles bereits "öffentlich" und wer Interesse daran hat, kann es sich selbst so oder in jeder anderen, von ihm selbst gewünschten Form nachbauen.
Die wirklich wichtigen Sachen werden dann wieder aus dieser "custom.custom" heraus gestartet ... in erster Linie eben ein SSH-Server (meist tatsächlich "dropbear"), der sowohl den Shell-Zugang als auch - per SFTP - den Dateizugriff ermöglicht.
Das alles wurde von mir veröffentlicht und (mind. einmal) auch hier im IPPF jeweils beschrieben ... an dieser Stelle ist dann aber mit dem "Vorkauen" auch Schluß. Ich sehe noch ein, daß es ein paar "Grundbedürfnisse" bei der Modifikation einer Firmware geben könnte (der "gui_bootmanager" gehört meinetwegen dazu und ein paar Mods fürs AVM-GUI), aber ich erkenne nicht einmal den (permanenten) Bedarf nach einem Shell-Zugang ... selbst wenn man den für ein erneutes Update per "modfs" benötigt. Niemand wird schließlich daran gehindert, sich den genau zu dem Zeitpunkt, wo er benötigt wird, auch wieder per "implant_siab..." in die laufende Version einzubauen ... und die Unterschiede bzw. Probleme beim Umgang mit dem Browser, den Telnet-Client oder einem SSH-Client, sind mir am Ende ebenfalls egal. Wer der Ansicht ist, er braucht den Shell-Zugang (und sei es dreist, um "modfs" verwenden zu können), der muß auch mit solchen "Widrigkeiten" fertig werden - ansonsten sollte er (schlauerweise) selbst die Entscheidung zum Verzicht treffen.
Wer schlau ist, wartet nicht erst darauf, daß ihm jemand anderes "schlüsselfertige Lösungen" präsentiert ... wer sich nur ein wenig damit befaßt, sollte solche Vorhaben wie "Ich baue mir mit "modfs" einen SSH-Server in mein System ein." auch problemlos selbst auf die Reihe bringen - und er braucht dazu im Prinzip nichts weiter als seine FRITZ!Box und einen Editor. Schließlich ist genau deshalb das "modfs" von mir ja als "offenes Framework" konzipiert worden, damit da jeder seine eigenen Idee mit umsetzen kann. Ich hatte ja mal den Glauben, daß es tatsächlich "user contributed modifications" geben würde ... offenbar verwenden die meisten aber doch nur das, was ihnen bereits vom "modfs.tgz" mitgeliefert wird.
Letztlich wollte ich eigentlich nur die Einstiegshürde ggü. Freetz etwas senken ... das sollte (zumindest als "modfs") gar keine "Full-Service-Solution" werden (und ist es auch nicht). Das kann vielleicht mal für "YourFritz" etwas werden ... ist aber noch ein weiter Weg und die Mitstreiter (bei der Programmierung von irgendetwas) rennen einem auch nicht gerade die Bude ein. Daß ich mich dann eher selten dazu aufraffen kann, da weiter Hand anzulegen, ist hoffentlich auch nachvollziehbar ... mir persönlich reichen nämlich die Möglichkeiten der Automatisierung beim Modifizieren der Firmware, die inzwischen vorhanden sind, durchaus.
-----------------------------------------------------------------------------------------------------------------
tritt das Problem mit den gefärbten Codeblöcken auf, die sind nun im Code enthalten und müssen erst wieder entfernt werden.
Hier verstehe ich nicht so richtig, was Du
mir sagen willst ... ich hoffe halt immer noch, daß irgendwann mal wieder die Möglichkeit der farblichen (und typographischen) Hervorhebung in die CODE-Blöcke Einzug hält (bei vBulletin war sie ja vorhanden) und werde gewiß nicht hingehen und die BBCode-Tags entfernen. Abgesehen davon kann ich manche Beiträge gar nicht mehr editieren (habe ich ebenfalls mehrfach bereits betont/festgehalten), weil sie das nachträglich gesetzte Limit der Zeichenanzahl reißen und ich sie nach den simpelsten Änderungen nicht länger speichern kann. Wenn Dich das also stören sollte, mach' einfach bei der Administration entsprechenden "Krach".
