Anleitung: SSH (Dropbear) und Etherwake auf der FRITZ!Box

@jojo-schmitz

Gebe ich /var/tmp/start_pc1 ein, bekomme ich die Fehlermeldung "file not found", bei var/tmp/startpc funktioniert es, aber ich muß doch irgendwie unterscheiden, welcher PC gestartet werden soll.

Habe natürlich in der debug.cfg aus "startpc" auch "start_pc1" gemacht.

Ich dachte ich hätte aber auch irgendwo gelesen eth 0=Lan1 und eth 1=Lan 2

VG

Kiwi
 
Wenn die debug.cfg verändert wurde, muss die Box neu gebootet werden, damit die Änderungen auch in Effekt kommen. Diese wird ja beim boot ausgefüht und erzeigt dann Deine start_pc1 (allerdings ist nach einem reboot wohl auch die startpc weg).

Ich benutze folgendes:
Code:
# WOL-Scripte für alle DHCP LAN Clients erzeugen (WLAN macht wohl keinen Sinn)
grep '^lease' /var/flash/multid.leases | while read typ mac ip time name mac2
do
	# " los werden und Rest in lowercase konvertieren
	name=$(echo $name | tr -d '"' | tr '[A-Z]' '[a-z]')
	cat > /var/tmp/start_${name:=noname} <<-EOF
#!/bin/sh
ping -c 1 $ip >/dev/null 2>&1
if [ \$? = 0 ]
then
	echo "$name ($ip) läuft schon"
else
	echo "Sende WOL an $name ($mac) ..."
	# -i eth0 ist Default und hier das Richtige
	ether-wake $mac
	echo "Warte ob/bis $name ($ip) startet"
fi
EOF
	chmod +x /var/tmp/start_$name
done
 
wieder mal Access denied

Es tut mir leid, dass ich dieses Thema schon wieder anschneiden muss, aber leider hat die Suche lediglich ergeben, dass sich die Leute irgendwie vertippt haben oder etwas anderes falsch gemacht hatten, was ich alles schon kontrolliert habe.
Ich habe das Problem, dass ich mein dropbear-Passwort nicht so in der /var/tmp/shadow ablegen kann, dass die Anmeldung mit diesem Passwort klappt.

Meine debug.cfg ist relativ klein, daher hier mal die komplette Auflistung:

sleep 20
# download von dropbear
cd /var
/usr/bin/wget http://www.spblinux.de/fbox.new/cfg_dropbear
sleep 5
#dropbear installieren
chmod 755 /var/cfg_dropbear
/var/cfg_dropbear install
#rsa-key generieren
/var/dropbear/bin/dropbearkey -t rsa -f /var/tmp/dropbear_rsa_hostkey -s 1024
#SSH user/password festlegen
cp /var/tmp/shadow /var/tmp/shadow_save
sed -e "/root:/s#^root:[^:]*:#root:Ft3602tAHmOTg:#" /var/tmp/shadow_save > /var/tmp/shadow
#dropbear starten
/var/cfg_dropbear start
#Startskripte für alle angeschlossenen PCs erstellen
echo "/usr/bin/ether-wake -i eth0 00:XX:XX:XX:XX:XX" > /var/tmp/start_pc1
echo "/usr/bin/ether-wake -i eth0 00:XX:XX:XX:XX:XX" > /var/tmp/start_pc2
chmod 755 /var/tmp/start_pc1
chmod 755 /var/tmp/start_pc2
#Fritz! Box selbst in resolv.conf eintragen, damit sie die IP aufloesen kann
echo "nameserver 192.168.178.1" >> /var/tmp/resolv.conf
#interne IP-Adresse fuer den SSH-Server definieren
#-> danach Port 22 auf 192.168.178.254:22 umleiten!
ifconfig lan:1 192.168.178.254 netmask 255.255.255.0


Es funktioniert alles außer der Passwort-Vergabe, auch der Zugriff von außen - allerdings nur, wenn ich das Passwort über den dropbear Passwortänderungs-Mechanismus festlege. Dies funktioniert dann natürlich nur bis zum nächsten Neustart.
Daher will ich eigentlich den "normalen" weg über Eintragung in /var/tmp/shadow gehen, wie in jeder Anleitung beschrieben.
Dafür zuständig ist ja eigentlich die obige sed-Zeile, die hier "root:*:" in der shadow durch "root:Ft3602tAHmOTg:" ersetzt - was wiederum das Ergebnis einer Hash-Berechnung von der Seite http://home.flash.net/cgi-bin/pw.pl für den Klartext "ipforum" darstellt.
Nun gibt es zwei Fragen:
1.)Wieso erzeugt diese Seite bei jedem Versuch ein anderes Ergebnis für den gleichen Klartext (zig mal gefragt, nie befriedigend beantwortet)? Es darf ja doch wohl nur eins geben - oder wie soll sonst der Abgleich des eingegebenen Passworts mit dem in der shadow hinterlegten funktionieren?!
2.)Wieso komme ich mit user root / passwort ipforum nicht per SSH auf die Box? (liegt meines Erachtens an Punkt 1)

Übrigens, wenn ich den Passwort-Hash für "ipforum" mit dem Tool "htmanager" generiere, kommt immer das gleiche Ergebnis heraus, und zwar root:RxEbKBrqqGnjs. Funktioniert aber trotzdem nicht.

Ich hab eine 7170, die neueste Firmware geflasht (29.04.49) und benutze dementsprechend das neue dropbear-Kompilat (siehe wget-link oben). Meine Vermutung ist, dass die ganze Methode mit dieser Version von dropbear einfach nicht mehr funktioniert...?

Bin echt mit meinem Latein am Ende...
 
Meine debug.cfg ist relativ klein, daher hier mal die komplette Auflistung:
...
Lasse Dir von The Constuct ein Pseudo Imagge erstellen
Dafür zuständig ist ja eigentlich die obige sed-Zeile, die hier "root:*:" in der shadow durch "root:Ft3602tAHmOTg:" ersetzt - was wiederum das Ergebnis einer Hash-Berechnung von der Seite http://home.flash.net/cgi-bin/pw.pl für den Klartext "ipforum" darstellt.
Nun gibt es zwei Fragen:
1.)Wieso erzeugt diese Seite bei jedem Versuch ein anderes Ergebnis für den gleichen Klartext (zig mal gefragt, nie befriedigend beantwortet)? Es darf ja doch wohl nur eins geben - oder wie soll sonst der Abgleich des eingegebenen Passworts mit dem in der shadow hinterlegten funktionieren?!
Weil der crypt() nunmal so funktioniert und jede Sekunde (!) einen anderen Wert erzeugt. Diese Sekunden stellen den 'salt' oder 'seed' dar und sind Bestandteil des verschlüsselten Passwortes, so dass ein gegebenes Password it diesem seed verschlüsselt dieselbe Verschlüsselung ergibt und damit dann auch Gleichtheit geprüft werden kann. Das Password kann nämlich nicht entschlüsselt werden.

Tschö, Jojo
 
Hi Jojo, danke für die schnelle Antwort erst Mal.
Weil der crypt() nunmal so funktioniert und jede Sekunde (!) einen anderen Wert erzeugt. Diese Sekunden stellen den 'salt' oder 'seed' dar und sind Bestandteil des verschlüsselten Passwortes, so dass ein gegebenes Password it diesem seed verschlüsselt dieselbe Verschlüsselung ergibt und damit dann auch Gleichtheit geprüft werden kann. Das Password kann nämlich nicht entschlüsselt werden.
Was ich schon wusste war, dass es sich um eine Einweg-Verschlüsselung handelt. Was ich nicht wusste war, dass diese Einweg-Verschlüsselung jede Sekunde ein anderes Ergebnis liefert.
D.h. also, in dem Moment wo ich ein Passwort eingebe, wird es mit dem in dieser Sekunde aktuellen seed im Client encrypted, übertragen und auf dem Server ebenfalls (mit dem gleichen seed) encrypted. Anschließend werden die beiden Ergebnisse verglichen, richtig?
Jetzt geht es noch um das "gegebene" Passwort: Damit der Mechanismus funktionieren kann, muss das eigentliche Passwort (hier z.B. "ipforum") doch in irgendeiner Form auf der Box abgelegt werden.
Es macht ja keinen Sinn, ein encryptetes Passwort (das eh nur 1 Sekunde gültig ist) auf der Box abzulegen... muss ich also stattdessen das Passwort im Klartext in die shadow schreiben (damit auf dieser Basis in Verbindung mit dem aktuellen seed die Vergleichs-Encryption laufen kann?)

Gruß
 
Nein, in die shadow gehört das verschlüsselte Password. Da dieses wie gesagt den Salt mit beinhaltet, kann der Passwortcheck Algorithmus das gegebene Klartext Paswort mit dess Hilfe verschlüsseln und die Ergebnisse vergleichen, etwa so:
Code:
pwd = getpwnam(desired_name)
...
if ( strcmp(pwd->pw_passwd, crypt(cleartext, pwd->pw_passwd) == 0)
...
D.h. das verschlüsselte Passwort (bzw. die ersten beiden Zeichen davon) werden als salt verwendet, das Klartect password damit verschlüsselt und mit dem verschlüsselten (aus /etc/passwd bzw. /etc/shadow) verglichen.
Beim Erzeugen des Passwortes dagegen wird eben mit einem mehr oder minder zufälligen Salt verschlüsselt, der üblicherweise sekündlich wechselt.
 
OK, das macht Sinn. Nur nochmal zur Sicherheit:
1.) Das Passwort wird initial mit crypt() verschlüsselt und in der shadow abgelegt.
2.) Beim login wird der salt des auf dem Server liegenden Schlüssels verwendet, um das im Client eingegebene Passwort zu verschlüsseln
3.) Das Ergebnis wird mit dem verschlüsselten Passwort auf dem Server verglichen.

Richtig so?

Daher also kann das Passwort beim Generieren jedes mal anders sein - der Salt-Anteil ist nach der Generierung enthalten und damit "fix". Er wird von da an bei jedem Login benutzt, um das Passwort zu verschlüsseln und dann den String zu vergleichen.

Nun bin ich zwar ein ganzes Stück schlauer, aber der Lösung meines Problems bin ich leider immer noch nicht näher gekommen.

Du scheinst ja ein echter Profi zu sein, kannst Du evtl. in meiner debug.cfg einen Fehler finden? Ich habe immer noch den Verdacht, mein dropbear kehrt sich einen Sch... was in der shadow steht, Grund der Annahme:
Wenn ich per dropbear ein passwort festlege (was dann ja auch bis zum nächsten Neustart funktioniert), verändert sich die /var/tmp/passwd, aber nicht die shadow. Da kann ich auch heinzbecker eingeben, das hat null Einfluss auf das Verhalten.
Du sprichst von /etc/passwd bzw. /etc/shadow... muss ich den ganzen Kram in diese shadow statt in die in /var/tmp schreiben oder wie (bin gerade leider nicht auf der fritzbox-shell)?
 
Genau so!

/etc/passwd vs. /etc/shadow (bzw. in der Box symbolische links nach /var/tmp, wo dann die 'echten' Dateien liegen):
Früher befand sich das verschlüsselte Password in der für jeden lesbaren /etc/passwd (im 2. Feld) und man konnte es daher kopieren und per 'brute force' knacken. Daher liegt es jetzt in /etc/shadow, welche nur der Super User lesen kann (und einige Tools die SUID sind)
Ich weiss nicht, wie man mit dropbear das Passwort ändert, aber wenn dieses die /var/tmp/passwd verändert statt der /var/etc/shadow, dann geht da was schief, denn beim Verifizieren eines Users vergleicht dropbear mit dem Passwort aus der shadow.

Generiere also dein Password besser mit http://home.flash.net/cgi-bin/pw.pl und trage das dan in /var/tmp/shadow ein. Da mit das dann aich nach einem Restart noch tut, zusätzlich in /var/flash/debug.cfg, eben in diesem sed Kommando.

Oder lasse Dir einfach (und wie schon vorher erwähnt) ein Pseudo Image von The Construct erstellen.

Tschö, Jojo
 
OK, sieht so aus als hätte meine debug.cfg keinen erkennbaren Fehler, es geht halt einfach nicht. Das Eintragen eines auf http://home.flash.net/cgi-bin/pw.pl erzeugten Passwortes in das sed-Kommando hat ja wie gesagt leider nicht getan...
Werde mir so ein Pseudo Image erstellen und das aufspielen und dann mal gespannt schauen, was das so alles in die debug.cfg schreibt...
Hätte es halt gern auf manuellem Wege hinbekommen, weil ich gern genau wissen will wie etwas funktioniert.
 
Der Fehler könnte schon im cfg_dropbear liegen.

Und: in das sed Kommand eintragen und Neustart der Box, oder (ggf zusätzlich zum sed) in /var/tmp/shadow eintragen
 
Stimmt... das cfg_dropbear selbst könnte einen Fehler haben.
Hab das Passwort in die sed-Zeile eingetragen und selbige anschließend direkt ausgeführt um die Wirkung zu kontrollieren. Daran kanns also auch nicht liegen.

Wie gesagt, werde heut Abend mal zu "The Construct" gehen. Werde wieder berichten.
 
So, habe es jetzt hinbekommen. Habe mir bei The Construct ein image erstellen lassen und mir angesehen, was da generiert wurde (hab die .image - Datei einfach mal auf Verdacht in .zip umbenannt und violá). Auffällig ist, dass das Skript eine neue Version der busybox nachlädt, was meine vorherige Version nicht getan hat. Außerdem wird ein fester RSA-Schlüssel erzeugt und nicht bei jedem Neustart ein neuer (was meines Erachtens ja auch Sinn macht).
Zu guter Letzt ist das Passwort viel länger als bei den bisherigen Beispielen, die ich z.B. bei wehavemorefun oder tecchannel gesehen habe. Kann es sein, dass hier ein anderes Generierungsverfahren benutzt wird?

Wie auch immer - hab mir dann eine Mischung aus dem Pseudo-image und meiner alten Version gebaut und das ist das Ergebnis:

Code:
#!/bin/sh
sleep 40
PASSWD='XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/'
#SW nachinstallieren
wget -qO /var/tmp/dropbear [url]http://ftp.the-construct.com/files/linux26/dropbear[/url]
wget -qO /var/tmp/busybox [url]http://ftp.the-construct.com/files/linux26/busybox[/url]
chmod 755 /var/tmp/busybox
chmod 755 /var/tmp/dropbear
#root-Passwort festlegen
sed -e "s#^root:[^:]*:#root:${PASSWD}:#" -i /var/tmp/shadow
#RSA host key erzeugen
/var/tmp/busybox uudecode -o /var/tmp/dropbear_rsa_host_key << 'RSA'
begin 600 /var/tmp/dropbear_rsa_host_key
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXX RSA-KEY halt XXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end
RSA
#dropbear starten
sleep 50
/var/tmp/dropbear -p 22 -r /var/tmp/dropbear_rsa_host_key
#Startskripte für alle angeschlossenen PCs erstellen
echo "/usr/bin/ether-wake -i eth0 00:XX:XX:XX:XX:XX" > /var/tmp/start_pc1
echo "/usr/bin/ether-wake -i eth0 00:XX:XX:XX:XX:XX" > /var/tmp/start_pc2
chmod 755 /var/tmp/start_pc1
chmod 755 /var/tmp/start_pc2
#Fritz! Box selbst in resolv.conf eintragen, damit sie die IP aufloesen kann
echo "nameserver 192.168.178.1" >> /var/tmp/resolv.conf
#interne IP-Adresse fuer den SSH-Server definieren, die dann uebers Portforwarding 
#angesprochen werden kann->danach Port 22 auf 192.168.178.254:22 umleiten!
ifconfig lan:1 192.168.178.254 netmask 255.255.255.0

Funktioniert alles einwandfrei, inkl. SSH-Zugriff von außen über die DynDNS-Adresse.

Vielen Dank an jojo-schmitz für die Hilfe! :p
 
Zuletzt bearbeitet:
Stimmt, statt crypt() wird vermutlich bigcrypt() verwendet, daher die längeren Passwor Hashes.
 
Hallo,

Ich versuche gerade dropbear auf meine FB Fon 7170 zu bekommen...

Hab die neuste Firmware drauf und benutze den Dropbear von The-Construct für den 2.6er Kernel.

An der Stelle im install Script, wo er die RSA-Keys generieren soll bekomm ich folgende Ausgabe:

Erstelle neuen RSA Hostkey ...
Bus error

Ich habe schon mehrere Foren durchsucht aber keine Lösungen für diesen Fehler gefunden....

Weiß jmd woran das Liegen kann?

greez Goshe

@edit: Image von The-Construct hat geholfen ;-)
 
hi all,
ich habe änliches problem.
wie schon oben beschriben, bekomme ich beim erstellen des keys folgende meldung:
can't resolve symbol '__uClibc_start_main'
wie ich es verstanden habe, ist der dropbare bei mir für kernel 2.4, habe aber 2.6.
ich möchte auf keinem fall die pseudoimage erstellen - ich lade die teile vom usb-stick und möchte meine debug.cfg selbst bearbeiten. außerdem haben bei mir schon mehrere images micht funktioniert.

hat jemand villeicht eine lösung?
 
Pseudoimage erstellen, reingucken und feststellen, welche Dateien dort geladen würden, diese selbst laden und auf den Stick packen, eigene debug.cfg passend beabeiten.


Gruß,
Wichard
 
vielen dank, dein tipp hat geholfen. allerdings ist fernzugriff per ssh nicht möglich. dafür muss ich doch portfreigabe des 22.-port auf die adresse der fritzbox einrichten oder?
 
hallo,
ich möchte in meine debug.cfg ein paar zeilen reinschreiben, um login versuche mit ssh über dropbear von außen zu Protokollieren.
Hier im Forum hab ich dazu noch nichts gefunden, und das was ich alles gefunden habe, ist aus 2005, glaube zu alt.
Hat jemand ne Idee, wie das zu machen ist ?
In Dropbear hab ich dazu keine Option gefunden.
schön wärs wenn das log in /var/log abgelegt würde
es soll mit der Labor-Version 29.04.97-10173 funktionieren


hallo radislav,
wie editiert man die Benutzeroberfläche, kann man das irgendwo nachlesen?
MfG thiesy
 
@thiesy
hi, das ist ein interesanntes thema - ich bin selber drauf gekommen, wie es geht, natürlich mit hilfe von google/internet. editieren ist es nicht ganz.... aber ich denke, dass dieses hier nun überhaupt nicht reinpasst. interessiert aber vermutlich mehrere user. deswegen werde ich gleich ein neues thread öffnen mit einer kleinen beschreibung, wie ichs gemacht habe, die wir dann hoffentlich auch vervolständigen werden.

zur deiner eigentlichen frage kann ich leider nichts sagen - da müssen andere ran!

p.s. nachdem ich neues thread öffne, bearbeite ich diesen eintrag und poste den link zum thread.

[edit]
so, hier der verspochene link
@thiesy: ich erwarte natürlich deine teilnahme ;)
[/edit]

gruß
 
Zuletzt bearbeitet:
Also wenn du loggen willst machst statt:
/var/tmp/dropbear -p 22 -r /var/tmp/dropbear_rsa_hostkey

einfach ein
/var/tmp/dropbear -p 22 -E -r /var/tmp/dropbear_rsa_hostkey 2>/var/log/dropbear_log.txt

-E fordert dropbear auf in stderr zu loggen statt in syslog.

Gruß
Thorsten
 
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.