TRACE (4891) 8.418995: enter checkpubkey
TRACE (4891) 8.419108: enter checkpubkeyperms
TRACE (4891) 8.419219: enter checkfileperm(/var/home)
TRACE (4891) 8.419381: leave checkfileperm: success
TRACE (4891) 8.419497: enter checkfileperm(/var/home/.ssh)
TRACE (4891) 8.419672: leave checkfileperm: stat() != 0
TRACE (4891) 8.419801: leave checkpubkeyperms
TRACE (4891) 8.419909: bad authorized_keys permissions, or file doesn't exist
TRACE (4891) 8.420021: leave checkpubkey: ret=-1
dropbear gar nicht anders (will ich aber nicht beschwören) - die Suche nach authorized_keys in ~/.ssh ist ja "normal".
root, iirc) so setzen, daß darunter ein Verzeichnis .ssh existiert, in das man dann eine authorized_keys legen kann.authorized_keys) kann/sollte man dann aus einer signierten Datei wiederherstellen lassen - die kann man bei der Installation oder bei Änderungen einfach mit dem Box-Key selbst signieren (dazu kann man sign_image (https://github.com/PeterPawn/YourFritz/blob/main/signimage/sign_image) mit SIGN_ON_BOX=1 aufrufen - braucht eigentlich nur ein OpenSSL und getprivatekeypassword zusätzlich) und VOR dem Entpacken (im Rahmen des Start-Skripts für dropbear, wo man auch das Home-Verzeichnis von root einfach auf /var setzen kann, was dann /var/.ssh als Verzeichnis für die Datei ergibt) aus dem NAS-Flash oder von einem USB-Volume dann diese Signatur wieder prüfen lassen (check_signed_image (https://github.com/PeterPawn/YourFritz/blob/main/signimage/check_signed_image) mit Option -s), damit einem da niemand einen falschen/nicht autorisierten Key unterjubeln kann.authorized_keys ganz simpel im YAFFS2-Teil unter /wrapper ablegen und dann lediglich von /var/.ssh/authorized_keys dorthin verlinken - um beim verwendeten Home-Verzeichnis zu bleiben. Eine andere Option (immer noch bei VR9) ist es natürlich auch, das Home-Verzeichnis einfach auf /wrapper zu setzen ... das ist üblicherweise ein read-only-Mount, läßt sich aber mit einem kühnen mount -o remount,rw /wrapper auch wieder beschreibbar mounten und dann kann man dort wieder ändern und sich dort ein Verzeichnis .ssh anlegen.dropbear ist jedenfalls absichtlich so stark eingeschränkt ... nur root kann sich anmelden und auch das nur mit Key und auch nur mit RSA-Keys als Server-Identity, WEIL ich ja den Key der Box (den sie sich entweder selbst generiert oder den der Benutzer hochladen kann über das AVM-GUI) verwenden will und keinen anderen.authorized_keys gleich mit ins Image zu packen (kann man auch machen, ist aber dann schon SEHR unflexibel), sondern diese an einer beschreibbaren Stelle im Rahmen des Startprozesses für den dropbear-Server dynamisch zu erzeugen ... aber eben mit etwas Absicherung, damit da kein Angreifer einfach eigene Keys hinzufügen kann. Ob man das dann wirklich als authorized_keys-Datei schon so abgespeichert hat und es nur noch kopiert oder ob man sich die gesamte Datei dynamisch aus einzelnen "pubkey"-Dateien zusammenbastelt, ist wieder Geschmackssache ... wobei der dropbear es auch beherrscht, für einen Key ein vordefiniertes Kommando zu hinterlegen - man kann dann also mit dem passenden privaten Schlüssel auch noch keine "komplette Session" starten, sondern "nur" das verknüpfte Kommando ausführen. Das spricht in meinen Augen für die erste Variante, weil die dynamische Erzeugung des Inhalts komplexer wird, wenn da gleichzeitig noch diese Optionen genutzt werden sollen..ssh oder auch erst der authorized_keys betrifft. Man kann also selbst mit einem Home-Verzeichnis /var für root (die AVM-Vorgaben / ist da ohnehin Gülle, weil das per Definition dann ein "nur lesbares" Home-Verzeichnis ergibt) noch per Symlink entscheiden, wo letztlich die Liste der zulässigen öffentlichen Schlüssel für SSH-Zugriffe gesucht wird.
# wget -q https://raw.githubusercontent.com/PeterPawn/YourFritz/main/signimage/sign_image
# wget -q https://raw.githubusercontent.com/PeterPawn/YourFritz/main/signimage/image_signing_files.inc
# wget -q https://raw.githubusercontent.com/PeterPawn/privatekeypassword/master/shell/privatekeypassword.sh
# chmod u+x sign_image privatekeypassword.sh
# mkdir -p var/home/.ssh
# echo "ssh-rsa AAAAblabla" >var/home/.ssh/authorized_keys
# tar cf authorized_keys.tar ./var/
# SIGN_ON_BOX=1 YF_SIGNIMAGE_OPENSSL=/var/media/ftp/openssl ./sign_image authorized_keys.tar $(./privatekeypassword.sh) >sign
Found OpenSSL 1.0.2n 7 Dec 2017
Check dgst command ... OK
Check rsa command ... OK
Verify hash algorithm md5 is supported ... OK
Checking input file format ... ./sign_image: line 285: mktemp: not found
OK
./sign_image: line 335: which: not found
Error determining the password for the FRITZ!OS RSA key.cp -r /.ssh /var/home; dropbear für den Service-Start begnügen.
authorized_keys in dem Node liegt oder ob da ein Skript steht (ob rc.user oder debug.cfg ist halt "nur ein Name") und das dann die Datei dynamisch erzeugt, ist wieder Geschmackssache.command- oder environment-Parameter in der authorized_keys habe ich ja nicht nur zufällig gewählt - nicht jeder will "nur" eine Shell-Session per SSH haben) wieder ein neues Image backen muß und das daher schon als "allgemeines Herangehen" eher nicht taugt in meinen Augen.decrypt_nvram(). Und das, obwohl auch dieser Storage "von außen" gar nicht ohne weiteres zu erreichen ist - ähnlich wie das YAFFS2 unter /wrapper bei VR9-Boxen.mktemp-Applet enthält:~ # /var/custom/bin/busybox mktemp --help
BusyBox v1.27.2 multi-call binary.
Usage: mktemp [-dt] [-p DIR] [TEMPLATE]
Create a temporary file with name based on TEMPLATE and print its name.
TEMPLATE must end with XXXXXX (e.g. [/dir/]nameXXXXXX).
Without TEMPLATE, -t tmp.XXXXXX is assumed.
-d Make directory, not file
-q Fail silently on errors
-t Prepend base directory name to TEMPLATE
-p DIR Use DIR as a base directory (implies -t)
-u Do not create anything; print a name
Base directory is: -p DIR, else $TMPDIR, else /tmp
~ #mktemp emulieren (in irgendeinen Shell-Skript im Repo gibt es das garantiert auch schon, weil es auch nicht das erste Mal wäre, daß etwas mit der AVM-BusyBox "gängig" gemacht werden muß und die kennt das Applet eben nicht) - ich hoffe einfach mal, daß das "Verständnis" des Prinzips DARAN jetzt nicht wirklich scheitert.privatekeypassword nehmen ... aber solange die auch funktioniert, ist das ebenfalls wieder "Geschmackssache". Aber die ist nun mal nur zum Zeigen des Prinzips und wenn die irgendwo jetzt nicht funktionieren sollte, ist mir das prinzipiell (sic! - auch wenn's ein anderes Prinzip ist) egal. Alternativ gibt es noch das zugehörige C-Programm bzw. die Library (das C-Programm ist praktisch nur ein einziger Aufruf einer Library-Funktion) oder auch dieselbe Funktion noch einmal im decoder-Programm.read-only-Key leben kannst (der ist ja schon mal prinzipbedingt "sicher", wenn ihn niemand austauschen kann), ist das ja schön für Dich - andere hätten es vermutlich gerne etwas flexibler und dann muß/sollte zwar auch das Skript dafür ins Image (außer man macht es eben doch wieder mit "Erweiterungen" als Image, wie früher in E99-custom), aber dafür muß man sich eben auch schon vorher entscheiden, WIE man es letztlich angehen will - denn das muß dann ja in dieses Skript Einzug halten.
Das hatte ich bei der 6490 gemacht eben weil hier der store (/var/media/ftp) potentiell von aussen erreichbar ist. Bei der 6591 liegt das ganze unverschlüsselt in /nvram (weil das da gross genug und auf emmc statt spi flash liegt).
bb0 bis bb9 (https://github.com/PeterPawn/YourFr...3e08df58ffc79c3094/tffs/data/nametable_@L#L10) in der Name-Table? Die kommen sich zumindest nicht mit anderen Nutzungsformen ins Gehege.
in /etc/passwd (symlink zu /var/tmp/passwd) steht bei mir jedenfalls
root:x:0:0:root:/:/bin/shecho $HOME nur / aus und sucht somit je nach passwd an unterschiedlichen Stellen nach den authorized_keys.
Das dürfte auch die Variante sein, die aus der
/var.tar im Image entpackt wird - da bietet sich (beim Erstellen des neuen Images) eine weitere Option, WIE man die passwd schon von Beginn an nach eigenen Vorstellungen erzeugen kann. Meine Ansätze (beim Implantieren von SIAB) gehen aber von einem unmodifizierten Image aus und da muß man nun mal die passwd dann erst im Nachhinein anpassen, weil man die /var.tar eben NICHT ändern kann.Weil das Image auch nur ein "Angebot" ist ... die Verzeichnisse, die Dir da komisch vorkommen, sind sogar im Skript konfigurierbar (oder können noch beim Aufruf (des Generator-Skripts) als Parameter angegeben werden auf der Kommandozeile), wenn man lieber etwas anderes möchte: https://github.com/PeterPawn/YourFr.../toolbox/build_shellinabox_implant_image#L268
/var liegen muß) und (b) nicht schon allen möglichen Müll des FRITZ!OS enthält, wenn ich mich einlogge (was /var selbst schon mal ausschließt). Und das home als Bestandteil des Namens ... nun, das erschien mir hier irgendwie naheliegend. Und es hat auch Gründe, warum das Home-Verzeichnis bei mir eben gerade NICHT auf einem USB-Volume liegt (wobei das auch unterhalb von /var wäre 
).unshare enthält) auch einfach eine eigene passwd-Datei für den SSH-Server setzen, in der kann dann das Home-Verzeichnis für den root-Benutzer hinzeigen, wo man will und die anderen Daemons werden davon nicht beeinflußt. Das gilt auch für die Varianten, wo man den SSH-Server in ein chroot-Jail packen möchte ... da hat der dann auch seine eigene Kopie dieser Datei.[Service]
ExecStart=/etc/init.d/S85-apps
After=net.service
WantedBy=multi-user.target
