[Frage] Telnet auf der Fritzbox mit OS 07.12

Was es mit diesem Hinweis [...] aufsich hat, kann ich nicht beurteilen (da nicht zuhause und zum ersten Mal davon lese).

Das bedeutet u.a., der FBEditor ist bis jetzt nicht mit den von FRITZ!OS 07.19 erstellten Export-Dateien kompatibel (bzw. kann dafür nicht die korrekte Checksumme berechnen).
 
  • Like
Reaktionen: Micha0815
...
Code:
cd ~/YourFritz
mkdir var/tmp/squashfs-root/.ssh/
chmod 700 var/tmp/squashfs-root/.ssh/
echo 'ssh-rsa AAA...public_root_sshKey...Ix rootAccess' >>var/tmp/squashfs-root/.ssh/authorized_keys
chmod 600 var/tmp/squashfs-root/.ssh/authorized_keys
cp bin/target/mips/3.10.107/dropbearmulti var/tmp/squashfs-root/usr/sbin/
ln -s dropbearmulti var/tmp/squashfs-root/usr/sbin/dropbear
cp bin/target/mips/3.10.107/sftp-server var/tmp/squashfs-root/usr/bin/
echo "/usr/sbin/dropbear -j -k -S /usr/bin/sftp-server" >>var/tmp/squashfs-root/etc/init.d/S85-apps
...

@PeterPawn: Hast du dropbearmulti für die 7490 so verändert, dass sie nur in /var/home/.ssh/ und somit nicht in /.ssh/ nach authorized_keys sucht? Genau so verhält sie sich bei mir jedenfalls:
Code:
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

Zum Zeitpunkt, wo systemd dropbear startet, zeigt ~ jedenfalls auf /var/home. Wie kann ich deine Version in /.ssh/ suchen lassen?
 
Zuletzt bearbeitet:
Dann frage ich mich, ob @hsz die Keys tatsächlich in der root eingebunden hat.

Was schlägst du vor, wie man die authorizzed_keys ins Image einbindet, so dass dein Binary sie findet?
 
Einfach das Home-Verzeichnis des verwendeten Users (das wäre in jedem Falle root, iirc) so setzen, daß darunter ein Verzeichnis .ssh existiert, in das man dann eine authorized_keys legen kann.

Die tatsächlich zu verwendenden Keys (also die 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.

Dann kann man diese Datei auch guten Gewissens auf unsicheren Volumes herumliegen lassen (die Public-Keys im Inhalt sind ohnehin "öffentlich") und wer sich den privaten Key seiner Box herauszieht (oder sogar Key und Zertifikat mit eigenen Dateien ersetzt - das geht ja über's GUI ganz einfach), der kann notfalls auch "extern" dieses Archiv signieren und dann erst auf die Box bringen (um mal dem "Henne<->Ei"-Problem bei der ersten Verwendung die Spitze abzuschlagen).

Wer will, kann aber auch (bei VR9-Modellen zumindest) diese 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.

Meine "Spezialversion" von 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.

Die Idee dabei ist es aber eben nicht, eine 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.

Jedenfalls gibt es m.W. keine Limitierungen (mal von den Zugriffsrechten abgesehen), was das Verlinken (per Symlink, weil es per Hardlink ja innerhalb eines Filesystems sein müßte) von .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.
 
Ich finde nicht, dass sich der ganze Aufwand lohnt ggü. einem read only Schlüssel in der Box. Man könnte ihn doch z.B. einfach in TFFS-Node 98 speichern. Dann wäre er so sicher wie bei fescs Methode in der 6591 (dort in /nvram/ffnvram speichern). Das dürfte den meisten (auch mir) sicher reichen.

Zum Spaß habe mal auf der Box probiert:
Code:
# 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.

Ich glaube, ich werde mich dann doch mit einem cp -r /.ssh /var/home; dropbear für den Service-Start begnügen.
 
Logischerweise geht das auch, den in TFFS-Node 98 abzulegen ... ob man das dann so macht, daß da tatsächlich nur eine 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.

Aber auch dann steht der Public-Key (oder auch mehrere) eben nicht direkt im Image ... ich sage ja nur, daß das dann sehr unflexibel ist und man spätestens beim Wechsel des Keys oder bei Bedarf für einen weiteren (das Beispiel mit dem 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.

Und ich weiß ja nicht, wie genau Du Dir das bei @fesc angesehen hast ... aber auch da wird eben (wenn ich's richtig in Erinnerung habe - EDIT: bzw. richtig lese: https://bitbucket.org/fesc2000/ffritz/src/6591/puma6/atom/mod/etc/init.d/S91-ffinit) der Key-Store nicht unverschlüsselt gespeichert, sondern noch einmal mit dem Box-Key verschlüsselt - siehe 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.

Und WIE genau man letztlich die Integrität der Daten sichert, ist am Ende dann tatsächlich egal ... irgendwo gibt es IMMER auch eine Schwachstelle, wenn man einen Key so speichern MUSS, daß er bei automatischen Starts auch ohne Benutzereingriff (z.B. irgendeine Kennwort-Eingabe) genutzt werden kann. Die Frage ist nur, wie "vordergründig" solch eine "Schwachstelle" dann sein sollte.

Und wenn Du das oben Getestete vielleicht auch noch mit einer BusyBox machst, die das mktemp-Applet enthält:
Rich (BBCode):
~ # /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
~ #
, dann sollte das auch wie beschrieben funktionieren. Ansonsten muß man eben wieder das 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.

Außerdem würde ich nicht unbedingt die Shell-Version von 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.

Aber noch mal ... wenn Du mit einem 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.
 
obwohl auch dieser Storage "von außen" gar nicht ohne weiteres zu erreichen ist
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).
Was ich mir ueberlegt habe ist einen authorized key in einer environment variable abzulegen die man per eva setzen kann, z.b. das (unbenutzte) kernel_args1 (weiss nicht ob das auch auf anderen boxen geht). Natürlich wieder mit dem box key verschlüsselt.
Alles unter der Prämisse dass die Box als kompromittiert zu betrachten ist sobald es jemand geschafft hat sich einzuloggen (und privatekey/passwort kennt). Bin mir da aber noch unsicher.
 
die man per eva setzen kann

Gibt's nicht auch bei der 6591 die Variablen 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.

Ich benutze diese Variablen zum Setzen eigener Public-Keys für das Verifizieren der Signatur von Images: https://github.com/PeterPawn/YourFr...58ffc79c3094/framework/implant_public_key#L87 - in meinem Falle (256 Byte Value-Size) hat das sogar noch den Vorteil, daß man da tatsächlich nur von EVA aus etwas eintragen kann und beim Zugriff auf EVA ist die Box per Definition schon kompromittiert.
 
Zuletzt bearbeitet:
Dann frage ich mich, ob @hsz die Keys tatsächlich in der root eingebunden hat.

Was schlägst du vor, wie man die authorizzed_keys ins Image einbindet, so dass dein Binary sie findet?
in /etc/passwd (symlink zu /var/tmp/passwd) steht bei mir jedenfalls
Code:
root:x:0:0:root:/:/bin/sh
Ich bin mir nicht sicher woher / als home für root gekommen ist, aber deshalb liegt .ssh wo es im script angegeben ist
 
@hsz: Danke für den Hinweis.

@PeterPawn: Ohne SIAB-Wrapper sieht die passwd wie von hsz beschrieben aus. Mit SIAB-Wrapper steht dort /var/home. Hier steht, dass es so ist. Aber warum machst du das?
Und da holt sich dropbear vermutlich auch den Pfad her. Denn ebenfalls mit SIAB-Wrapper gibt echo $HOME nur / aus und sucht somit je nach passwd an unterschiedlichen Stellen nach den authorized_keys.
 
Zuletzt bearbeitet:
wie von hsz beschrieben aus
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.

Aber warum machst du das?
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

Wer da also gerne andere Werte hätte, muß sich nur (mit passenden Parametern) ein eigenes Images für SIAB erzeugen. Und ICH hätte da nun mal gerne ein Home-Verzeichnis, was (a) beschreibbar ist (womit es irgendwo unter /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 :cool:).

Um auch das nicht unerwähnt zu lassen ... wer will, kann bei passendem Kernel (einem, der Namespaces unterstützt) und passender BusyBox (eine, die 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.
 
Update: da seit einiger Zeit (ich denke seit Version 07.19) systemd für den Bootprozess genutzt wird, startet das script in /etc/init.d/S85-apps aus #32 nicht mehr. Das kann mittels eines neuen Service in /lib/systemd/system/apps.service gefixt werden

Code:
[Service]
ExecStart=/etc/init.d/S85-apps
After=net.service
WantedBy=multi-user.target
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.