FB 6591 verschiedenes

[koyaanisqatsi]

Moinsen


Die Tilde ( ~ ) ist in Linuxartigen OS immer das HOME Verzeichnis des USERs der gerade versucht sich anzumelden.
Wer ist denn das bei dir? Der Superkuhkräftige User root?

 

[Botschafter]

Danke für den Hinweis. Das war mir unbekannt.
Ich habe den Login mit Telnet bisher immer mit meinem Benutzernamen versucht.
Auch als root gelingt der Login mit dem Standart Passwort allerdings nicht.
Aber über die Atom Console müsste ich die Datei dann ja vom NAS Laufwerksordner in den Hauptordner kopieren können.
Danke. Damit kann ich erst mal weiter arbeiten . Wirklich klasse wie schnell und hilfreich hier geantwortet wird. Danke!

 

[jha4711]

Verstehe. Aber wo muss ich Sie ablegen? In der Firmware vor dem Flashen oder auf der Box per FTP oder NAS?
Einfach im Hauptordner?

Probier doch mal folgenden Weg:
lass Dir "irgendwie" abhängig von Deinem Betriebsystem den public key anzeigen. Typischerweise ist das die Datei in dem Verzeichnis ~/.ssh/id_rsa.pub ...
Auf Linux / Mac also mit einem einfachen

cat ~/.ssh/id_rsa.pub

Diesen Output kopierst Du in die Zwischenablage (meistens CTRL-C/CMD-C ...)
Dann nach dem Reboot der FritzBox ein telnet dorthin.
Nach dem Login (siehe P.S. weiter unten) einfach ein

echo "<DEIN Public Key z.B. via Paste wie CTRL-V oder CMD-V>" >> ~/.ssh/authorized_keys

Daraufhin müsste ein ssh von Deinem PC/Mac/Linux auf die Box klappen.

Ich empfehle nochmals eine Grundlegende Recherche zum Thema "ssh public key authentication"

P.S.: Bei mir ist das mit dem telnet Zugang zum einmaligen Übertragen des PubKeys jetzt schon wieder so lange her, dass ich gar nicht mehr weiss welchen Benutzer und welches Passwort man dafür angeben muss. Ich glaube es ist "root" und das Passwort, dass Du im Webinterface der FritzBox auch verwendest, wenn Du Dich über http://fritz.box anmeldest. Aber da bin ich nicht sicher und ggf. kann das hier noch jemand mit absoluter Sicherheit ergänzen - sorry ;-)

 

[koyaanisqatsi]

Aus der Erinnerung...

Der telnetd bekommt normalerweise noch als Loginprogramm ar7login als Parameter mitgegeben.
( Siehe, nach Login: ps )
...damit FRITZ!Box Benutzer, oder FRITZ!Box Passwort als Login akzeptiert wird.
Und die haben meines Wissens kein HOME-Verzeichnis.

Für ein Login über SSH muss aber der Benutzer root scharfgeschaltet werden.
Also: Über den telnetd mit "passwd -a md5 root" ein Passwort vergeben und in /etc/passwd das HOME-Verzeichnis in den schreibbaren Bereich ab /var/tmp/hier/irgendwo eintragen.

 

[jha4711]

Für ein Login über SSH muss aber der Benutzer root scharfgeschaltet werden.

Ebenso aus meiner Erinnerung: Das musste ich nach Anwendung des Patch von @fesc glaube ich nicht machen, da der Root dort schon aktiviert war. Aber Password und/oder authorized_keys haben in meinem Fall gefehlt.

 

[koyaanisqatsi]

Jut, aber wo hat dein root das HOME-Verzeichnis?
Kannst ja mal in der /etc/passwd oder das Ziel des Softlinks /var/tmp/passwd nachgucken.
Außerdem sollte es im Environment stehen, Kommando: env
( Wird aus /etc/passwd ausgelesen und automatisch gesetzt )
Normalerweise ( Linux ) gelangst dahin nach dem Soloauftritt von: cd
...oder: cd ~
Oder dem "Mini IF THEN": cd && pwd
( IF cd THEN pwd )

 

[jha4711]

Jut, aber wo hat dein root das HOME-Verzeichnis?

Konkret auf meiner gepatchten Box ist das HOME-Verzeichnis von root das "echte" Root-Verzeichnis "/".
Für die Befehle ist das ja "egal", weil die Box dieses HOME-Verzeichnis ja bei Verwendung der Tilde (~) auflöst.

Dort im Root-Verzeichnis "/" gibt es einen symbolischen Link von /.ssh auf /var/tmp/root-ssh

/.ssh -> /var/tmp/root-ssh

Das wiederum ist ein symbolischer Link

/var/tmp/root-ssh -> /var/tmp/ffnvram/root-ssh

Und wie gesagt, ich müsste mich stark täuschen, wenn ich da nach Einspielen der gepatchten Firmware irgend etwas noch manuell angelegt hätte, "ausser" den ~/.ssh/authorized_key" (also tatsächlich die Datei /var/tmp/ffnvram/root-ssh/authorized_keys) mit meinem Public Key.

Aber leider lassen mich meine grauen Zellen da manchmal im Stich ;-)

Nachtrag: Diese Symbolischen Links werden durch spezielle Scripte in /etc/init.d einer gepatchten Box erzeugt.

 

[koyaanisqatsi]

Im / ( Rootverzeichnis ) was nicht bedeutet das es das HOME-Verzeichnis von root sein muss, kann nicht geschrieben werden.
Bitte schau mal in /etc/passwd mit "more /etc/passwd" nach, ob es das auch wirklich ist.
Wenn ja, dann hat der Patch und freetz das beim bauen ( build, cross-compilen ) gemacht und kann nicht mal so eben nachträglich in einer Konsolesession geändert werden, b.z.w. ist, wenn temporär "übermountet"*, nach einem Neustart/Reboot wieder weg.
Aber wenn /.ssh erst gar nicht vorhanden, kann es auch nicht "übermountet" werden.

* mount mit der Option remount bind kann existierende schreibgeschützte Dateien/Ordner auf ein anderes Ziel zeigen lassen

 

[jha4711]

Bitte schau mal in /etc/passwd mit "more /etc/passwd" nach, ob es das auch wirklich ist.

Ja - es ist definitiv "/"
Aber wahrscheinlich haben sich unsere Posts überschnitten, da es wie gesagt in /etc/init.d bei einer gepatchten Box Scripte gibt, die das /.ssh dann via SymLinks anlegen bzw. mounten. Wie gesagt, diesbezüglich muss man dann eigentlich nichts mehr tun ausser die "persönliche" authorized_keys im dann beschreibbaren Verzeichnis anlegen bzw. pflegen.

 

[koyaanisqatsi]

Für mich schon klar.
Früher ( freetz auf 7113 und 7360 SL ) hab ich das aber ohne Patch hingekriegt, indem ich das HOME-Verzeichnis von root in den schreibbaren Bereich /var/tmp verlegt habe.
Denn es gibt auch noch andere wichtige persönliche "Voreinstellungen" die ich in ~/.profile eingepflegt habe und deswegen auch beschreibbar sein musste.
Hast du eine ~/.profile?
...die aus /var/flash/debug.cfg heraus erzeugt wurde, als das noch so funktionierte.

 

[jha4711]

Hast du eine ~/.profile?
...die aus /var/flash/debug.cfg heraus erzeugt wurde, als das noch so funktionierte.

Weder noch! Also auf meiner Box gibt es weder eine ~/.profile noch ein /var/flash/debug.cfg
Oder hast Du ( @koyaanisqatsi ) jemand anderen angesprochen als mich ;-) , denn ich weiß jetzt ehrlich gesagt nicht mehr, um was es Dir da geht? Ich hatte doch nur versucht zu erklären, was @Botschafter tun müsste um per ssh auf eine gepatchte Box zuzugreifen.
Hilf mir mal auf die Sprünge, was ich jetzt noch beitragen kann und wofür, damit ich den Faden wieder finde.

 

[koyaanisqatsi]

Ja du hast Recht, bin historisch abgeglitten und das stiftet Verwirrung.

Das mit der /var/flash/debug.cfg ist schon lange Geschichte, wenn dieser Mechanismus nicht wieder aktiviert wird.

Ihr solltet euch aber schon an @fesc seine Anleitung halten.
Und in dieser steht, dass die Keys mit dropbearkey erstellt werden.
Das ist ein simpler Softlink auf dropbear.
Dieser Schritt kann also auch auf der Box erfolgen.
Die Binary erkennt wie sie aufgerufen wurde, anhand des Aufrufnamens, genau wie die Applets der busybox.

Make a symlink pointing at this binary with one of the following names:
'dropbear' - the Dropbear server
'dbclient' or 'ssh' - the Dropbear client
'dropbearkey' - the key generator
'scp' - secure copy

...wobei scp die zusätzliche Binary sftp-server voraussetzt.

Ich werde mich jetzt hier aber besser raushalten.
...denn ich hab nicht den Eindruck, dass ich verstanden werde.

 

[fesc]

Der telnetd bekommt normalerweise noch als Loginprogramm ar7login als Parameter mitgegeben.

Richtig, so ist das auch hier. D.h. es gibt keinen login "user", man gibt nur das passwort der web GUI an

Dort im Root-Verzeichnis "/" gibt es einen symbolischen Link von /.ssh auf /var/tmp/root-ssh

Richtig, das wird beim patchen des root filesystems angelegt. Beim booten wiederum wird das ein link nach

# readlink -f .ssh/
/nvram/ffnvram/rootfs-overlay/root/.ssh

d.h. die daten werden persistent in der nvram partition im eMMC gespeichert:

Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p13           6.7M    891.0K      5.3M  14% /nvram

Das gleiche gilt fuer /etc/shadow:

# readlink -f /etc/shadow
/nvram/ffnvram/shadow

d.h. vergebene passwoerter (fuer ssh) sind persistent.

Edit: Benoetigt man einen ssh private key fuer root, so muss der nach ~/.ssh/id_dropbear:

# 
dropbearkey  -t rsa -f ~/.ssh/id_dropbear

bzw. public key mit

dropbearkey  -y -f ~/.ssh/id_dropbear

 

[koyaanisqatsi]

Hallo @fesc
In der Anleitung hab ich gelesen, dass das setzen des Passwortes für root mit "passwd" ohne zusätzlichen Parameter "-a md5" erfolgen soll.
Aus meiner Erinnerung wird so nur ein 8 stelliges Passwort erzeugt.
Aber, das Tükische daran ist, dass der User das nicht mitkriegt,
wenn er trotzdem ein Passwort zum Einloggen nutzt welches mehr als acht Stellen hat.
Es wird nur bis zur achten Stelle geprüft und der Rest ignoriert.

 

[fesc]

In der Anleitung hab ich gelesen, dass das setzen des Passwortes für root mit "passwd" ohne zusätzlichen Parameter "-a md5" erfolgen soll.

Da hast du recht, war mir so gar nicht bewusst, werde ich aendern. Generell verwende ich persoenlich nur public key authentication.

 

[Flole]

Ob MD5 nun unbedingt besser ist sei mal dahingestellt. Sofern verfügbar sollte man immer SHA mit einem Salt verwenden, dann ist man sowohl gegen Rainbow Tables als auch gegen Bruteforce übers Netzwerk (was aber selbst bei 8 Zeichen schon ewig dauern dürfte) geschützt.

Wenn AVM da nicht was entfernt hat sollte das auch auf einer Fritzbox funktionieren.

 

[PeterPawn]

Wenn man schon mal dabei ist, kann man auch gleich noch die verwendete BusyBox "tunen" ... denn die Verwendung von "DES crypt" (obendrein noch im "old style") ist da immer noch der "Standardwert" und wenn man die BusyBox ohnehin ersetzen sollte (was man wg. vieler fehlender Applets bei der AVM-Version ohnehin früher oder später in Erwägung zieht), kann man mittels "FEATURE_DEFAULT_PASSWD_ALGO" auch den Standardwert gleich ändern.

Wer Freetz verwendet (wo die BusyBox-Konfiguration dynamisch zusammengestellt wird), kann das auch in der Freetz-Konfiguration erledigen ... einfach mal nach "ALGO" suchen im "mconf" (das ist das Programm hinter dem "make menuconfig") und schon findet man die richtige Stelle im (verzweigten) Menü - so eine Suche beginnt man einfach durch die Eingabe eines Schrägstrichs.

Wobei für die Verwendung von SHA dann auch die Option "USE_BB_CRYPT_SHA" aktiviert sein muß (https://git.busybox.net/busybox/tree/libbb/pw_encrypt.c#n97) ... was bei der BusyBox von AVM auch nicht der Fall ist. Insofern muß man sich (wenn man die AVM-BusyBox benutzt) tatsächlich auf DES oder MD5 beschränken - auch die Überprüfung eines (schon gespeicherten) Kennworts unter Verwendung von SHA funktioniert dann m.W. nicht, falls jemand das "login"-Applet der BusyBox nutzen wollte (https://git.busybox.net/busybox/tree/libbb/correct_password.c#n82).

 

[koyaanisqatsi]

(was aber selbst bei 8 Zeichen schon ewig dauern dürfte)

OK, und wenn du es weisst kannste auch nach den 8. Zeichen reinhauen was du willst.
...ist bestimmt: Impressiv

 

[jha4711]

Hier noch eine Info wie man den kompletten Datenbestand vorab sichert:

Hallo - ich hätte mal eine ggf. blöde Frage zu Deinem äußerst hilfreichen Hinweis mit der Sicherung über dd.

Vorab: Mir ist auch klar, dass ich einen Backup, den ich mit "dd if=<quelle> of=<sicherung>" angelegt habe, später "prinzipiell" auch über "dd if=<sicherung> of="<ziel>" wieder zurückspielen kann.

Ich habe das z.B. auf meiner 6591 auch schon benutzt, um auf einem von Bootbank 0 (linux_fs_start=0) gestartetem System (also mit "aktiven" Partitions /dev/mmcblk0p2, ...0p3, ...0p4 und ...0p5) eine ältere Sicherung auf die dann "deaktiven" Partitions /dev/mmcblk0p8, ...0p9, ...0p10 und ...0p11) zurückzuspielen. Soweit - so gut.

ABER: Wenn man tatsächlich den gesamten "Original" Datenbestand (also auch die anderen Zehn /dev/mmcblk0pXYZ, wobei XYZ =1,6,7,12-18) wieder herstellen will, kann man ja nicht auf eine aktuell aktive Partition schreiben. Man würde sich ja den Boden unter den eigenen Füssen weg ziehen.

Nun zu meiner konkreten Frage:
Wie würdest Du also mit einer existierenden Sicherung des "kompletten Datenbestandes" (z.B. auf USB-Stick) dann auch ein "komplettes Wiederherstellen" - also 1:1 auf den Zustand zum Zeitpunkt der ursprünglichen Sicherung machen? Auf einem anderen (Linux) System würde man z.B. von einer Live-CD booten und dann das Restore auf die Originalpartitions durchführen.
Aber geht das mit "dd" dann überhaupt auch auf so einer FRITZ!Box? Wenn ja, wie könnte man das (vorzugsweise über ssh) anstellen?

Und zur Klarstellung: Ich spreche von einer 6591 mit altem BIOS, welches über den Bootloader (EVA / adam2) KEIN Schreiben zulässt. Wo man also zum Patchen anscheinend auch den physikalischen Anschluss der intern verbaute ATOM-Konsole braucht.

Bin gespannt ;-)

 

[Flole]

Also eine Möglichkeit wäre den eMMC auszulöten, zu verändern (Backup zurückspielen), reballen und wieder drauf damit. Ist jetzt auch die einzige die mir einfällt wenn man nicht gerade ein Intel NDA und deren Tools hat.