dropbear SSH-Problem bei Anmeldung des root Users

jori.gel

Neuer User
Mitglied seit
1 Feb 2008
Beiträge
9
Punkte für Reaktionen
0
Punkte
0
Hallo liebe Forumbetreiber,

zunächst mal herzlichen Dank für die Mühe, die Ihr Euch zur Lösung der Besucherprobleme macht. Ich betreibe selbst ein wiki und weiß, wovon ich rede.

Allen Mitgliedern dieses Forums ebenfalls dank für die Mühe des Lesens, auch wenn Ihr vielleicht nicht helfen könnt. Die Fritz-Box ist im Vergleich zum PC mit Linux schon sehr rudimentär und die Auswahl der guten How-Tos zum Thema Individualisierung sind begrenzt. Somit war ich beim "Schlaumachen" auf die teilweise sehr guten Beiträge der Leute hier angewiesen, womit wir auch schon bei meinem Thema wären:

Ich versuche z.Zt. meine FBF WLAN 7170 zum Kommunikationszentrum zu machen und Sachen wie den openVPN - Endpunkt von bisher meinem Gentoo-Server auf die Fritz-Box zu verlagern. Z.Zt. kämpfe ich allerdings damit dieses Mini-Linux zu durchschauen und mir einen vernünftigen Zugang zu der Box zu verschaffen. Wahrscheinlich also das, womit Ihr alle schon zu kämpfen hattet (oder haben werdet ;-). Nach ziemlich verunglückten Versuchen mit online-erstellten Pseudo-Images, bin ich zu dem Schluß gekommen, die entsprechenden Anpassungen manuell vorzunehmen, damit ich wirklich durchschaue, was da vorgeht.

Dazu habe ich den Telnet-Zugang freigeschaltet und mir ein Konfigurationsscript für die debug.cfg überlegt und auf der Box installert -> natürlich mit Hilfe der mir hier angelesenen Informationen. Deshalb wundert Euch nicht, wenn Euch die eine oder andere Codezeile bekannt vorkommt.

Vielleicht gilt es noch zu erwähnen, daß ich mir einen 4GB USB-Memorystick gegönnt habe, um den Problemen der Speicherknappheit aus dem Weg zu gehen. Damit ist es mir auch gelungen den Stick in die Konfiguration einzubinden und sogar einen Swap-Speicher auf ihm zu initialisieren, der auch zu funktionieren scheint (Hab' dazu allerdings die Kommentare von einzelnen Benutzern gelesen, die der Meinung waren, die Sticks würden das nicht lange mitmachen. Wenn jemand dazu was zu sagen hat, bitte auch gerne hier, weil sich mir der Grund dafür bisher verschließt. Im Moment ist das Swapping auch noch nicht nötig -> wird aber demnächst kommen, denke ich.).

Das Script sieht so aus:


Code:
#!/bin/sh

#########################################################################
# Entwurf fuer eine debug.cfg Konfigurationsdatei um
# FBF WLAN 7170 zum Kommunikationszentrum zu machen.
# Ausbaustufe 1: (abgeschlossen)
# - USB-Stick in /var/tmp mounten
# - Swapping auf dem Stick initialisieren
# - SSH-Server mittels dropbear installieren
# - /etc/init.d/rc.conf aufbohren, um weitere dauerhafte Aenderungen wie
#   einen Suchpfad auf dem USB-Stick zu setzen 
#
# Ausbaustufe 2:
# - VPN installieren, konfigurieren und initialisieren
# - Traffic Shaping realisieren
#
# c/o Peter Meins 2008        
# nach entsprechenden Tips und Hinweisen freundlicher Forenbesucher in:
# http://www.ip-phone-forum.de/showthread.php?p=1028816&
#########################################################################
# Variablendeklaration
#########################################################################
# Bezeichner des USB-Memorysticks in /var/media/ftp
# Ist an die oertlichen Gegebenheiten anzupassen
usbmem="USBDISK-Partition-0-1"

# Position des Swapfiles
swapfile="/var/media/ftp/$usbmem/swapfile"
                       
# USB-Verzeichnis in dem die Dateien liegen sollen (muss beschreibbar sein)
usbdir="/var/tmp/usbstick/files"

# Pfad der Logdatei
cLogDatei="/var/media/ftp/$usbmem/debug.log"

# Port auf dem Dropbear laufen soll
dropbearport="22"

# Passwort: fritzbox
PASSWD='36d6NYYMch85U'

# Warteschleife bis USBStick gemountet (max ca. 1Min)
max=15
i=0         
lfound=0

# Arbeitsschleife fuer Mountingtest des USBSticks
while [ $i -lt $max ]; do
	if mount | grep " on /var/media/ftp/" > /dev/null; then 
		cLog=$cLog"USB-Stick gefunden . . . \n"    
		lfound="1"
		cLog=$cLog"und Variable auf Wert $lfound gesetzt \n"
		break
	fi
	let i=$i+1
	sleep 10
done

# Alles weitere macht nur Sinn, wenns unseren USB-Stick gibt              
if [ $lfound -eq "1" ]; then
	
	#########################################################################		
	# Swapping
	#########################################################################	
	# Swapping organisieren (erstmal 1MB)
	# (sollte 2xBoxspeicher nicht ueberschreiten)
	if [ ! -e $swapfile ]; then
		dd if=/dev/zero of=$swapfile bs=1024 count=10k
		mkswap $swapfile 1024 && cLog=$cLog"Swapfile erstellt\n"
	fi  

	# Swapping initialisieren 
	cSwapLine=$(free | grep "Swap:")  
	cLog=$cLog"Swapspaceausgabe:>$cSwapLine<\n"	
	# Bei drei Nullen war kein Swap initialisiert
	if [ "$cSwapLine" = ' Swap:            0            0            0' ]; then
		swapon $swapfile &&	cLog=$cLog"Swapfile initialisiert\n"
	fi
	
	#########################################################################	
	# USB-Stick mounten
	#########################################################################
	# USBStick im Tmp-Verzeichnis mounten                                              
	# Verzeichnis fuer das Mounting anlegen
	[ -d '/var/tmp/usbstick' ] || mkdir '/var/tmp/usbstick'
	# und den USB-Stick darauf mounten
	if [ ! -d '/var/tmp/usbstick/files' ]; then
		# Erst mounten
		mount --bind '/var/media/ftp/USBDISK-Partition-0-1' '/var/tmp/usbstick' &&	cLog=$cLog"USB-Stick gemountet . . . \n"
	fi
	                   
	#########################################################################	
	# SSH installieren
	#########################################################################
	# Aendern des Root Passwortes
	cp -p /var/tmp/shadow /var/tmp/shadow.old && cLog=$cLog"<shadow> sicherungskopiert \n"
	sed -e "/root:/s#^root:[^:]*:#root:$PASSWD:#" /var/tmp/shadow.old > /var/tmp/shadow
	cLog=$cLog"Passwort geaendert \n"
	
	# Vorbereiten des ssh-Daemon
	if [ ! -e $usbdir/dropbear_rsa_host_key ]; then
	    # In das Lokale Verzeichnis wechseln
	    cd $usbdir
	
	    # Vorbereiten auf SSH
	    chmod 755 $usbdir
	    mkdir $usbdir/.ssh
	    chmod 700 $usbdir/.ssh
	
	    # Anpassen der Dateirechte
	    chmod +x ./dropbear
	    chmod +x ./openvpn
	
		# SCP vorbereiten
		for cmd in dropbear dropbearkey scp ssh dbclient dropbearconvert
		do
			cp $usbdir/dropbear $usbdir/$cmd
			chmod +x $usbdir/$cmd
			chmod 755 $usbdir/$cmd
			cLog=$cLog"$cmd erstellt \n"
		done
	
	    # 1024Bit RSA/DSS Keys fuer Dropbear erstellen
	    # Diese Dateien loeschen, wenn neue Keys erstellt werden sollen . . .
	    $usbdir/dropbearkey -t rsa -f dropbear_rsa_host_key && cLog=$cLog"RSA-Host-Key erstellt \n"
	    $usbdir/dropbearkey -t dss -f dropbear_dss_host_key && cLog=$cLog"DSS-Host-Key erstellt \n"
	fi
	
	# Dropbear starten, wenn noch nicht geschehen
	if [ `ps | grep 'dropbear' | grep -v grep -c` -le "0" ]; then
		$usbdir/dropbear -p $dropbearport -r $usbdir/dropbear_rsa_host_key -d $usbdir/dropbear_dss_host_key
	 	cLog=$cLog"dropbear-SSH-server gestartet \n"
	fi
	
	#########################################################################	
	# rc.conf.local Aufruf organisieren
	#########################################################################
	# Vorbereiten des Aufrufs einer rc.conf.local aus der rc.conf heraus
	# um einen Fuß in die Tuer der Box zu bekommen 
	# rc.conf auf den Stick downloaden (damit immer neuester Stand)
	umount /etc/init.d/rc.conf && sleep 2
	cp -f /etc/init.d/rc.conf $usbdir && cLog=$cLog"<rc.conf> kopiert \n"

	# Zeile fuer den Aufruf an die Datei anhaengen
	echo "###################### regenerative Aenderung von piet 02.02.08 ###########################" >> $usbdir/rc.conf
	echo ". $usbdir/rc.conf.local" >> $usbdir/rc.conf         
	cLog=$cLog"Aenderung an der neuen <rc.conf> vorgenommen \n"

	# jetzt die Originaldatei mit der gepatchen ersetzen
	mount --bind $usbdir/rc.conf /etc/init.d/rc.conf && cLog=$cLog"<rc.conf> weggeschrieben \n"

	# ab jetzt wird bei jedem Terminalstart auch die $usbdir/rc.conf.local aufgerufen
	# und alle dort eingetragenen Aenderungen uebernommmen, wenn die Datei existiert.
	# Vorsicht hier werden keine Syntax-Tests o.ae. vorgenommen! Was da steht muß stimmen :)
	# Der Ort ist natuerlich nicht fuer Installationen u.ae. geeeignet, weil die
	# dort gelagerten Routine bei jedem Terminalstart aufgerufen werden, sowas 
	# gehoert in diese Datei nach oben!!
	                                                               
	#########################################################################	
	# Aufraeumen
	#########################################################################
	/bin/rm /var/tmp/shadow.old && cLog=$cLog"Alte <shadow.old> geloescht \n"
fi       

# Logdatei schreiben
echo -e $cLog > $cLogDatei      
#########################################################################
# EoF debug.cfg


Hab's mal komplett abgedruckt - vielleicht kanns ja noch jemand gebrauchen, denn es scheint zu funktionieren. Die Links hier Kopies zu den verschiedenen Namen von dropbear hab ich aus den verschiedenen Vorschlägen dieses Forums ungeprüft übernommen und auch das Beispiel der Passwortänderung für den SSH-Zugriff hab' ich erstmal bei dem Paradebeispiel dieses Forums belassen :)

Wenn ich nun die FBF neu starte, arbeitet sie offensichtlich alle Befehle der debug.cfg korrekt ab, denn das Paßwort ist geändert, der USB-Stick ist eingebunden und stellt die Programme einwandfrei zur Verfügung. Der dropbear ist gestartet und wartet auf Kontakt.

Starte ich nun z.B. Putty, siehts aus als wenn klappt und Connection kommt zustande und er fragt nach dem User:


Code:
login as: root


nach root und Eingabetaste wars das und Putty beendet.

WinSCP ist da schon etwas mitteilungsfreudiger:


Code:
Anmeldungsprotokoll (Siehe Sitzungsprotokoll für Details):
Verwende Benutzername "root".
No supported authentication methods left to try!

Die Verbindung wurde unerwartet geschlossen. Der Server sendete den Befehlsbeendigungsstatus 0.


Es sieht also so aus, als ob der User root nicht akzeptiert würde. Alles andere wirkt als würde es funktionieren. Habe in einem anderen thread gelesen, daß da das Einrichten eines Pseudointerfaces helfen würde. Das habe ich - allerdings erfolglos - auch probiert und es hat nicht geklappt. Ehrlich gesagt hat mir auch nicht eingeleuchtet, was das mit dem Problem zu tun haben soll (und da war ich nicht der einzige), aber was man so alles in seiner Verzweiflung probiert ;-) und da waren wohl einige Leute, denen es geholfen hat.


Hat vielleich jemand eine Idee hierzu?

So, sorry für den etwas längeren Text, aber das sollte auch gleichzeitig meine Vorstellung in diesem Forum sein - und ich wollte höflich auftreten (wies sich gehört ;-)


Danke für Eure Aufmerksamkeit

Piet
 
Zuletzt bearbeitet:
Hallo erstmal. :)
Versuch's mal ohne der Option "-s" beim Dropbear starten, das verhindert, dass Du Dich mit Passwort einloggen kannst. Wenn das dann funktioniert, hast Du wohl was beim Authorized Key falsch gemacht.
 
Hi Neo,

<-s-Parameter entfernt> Dann siehts so aus:

login as: root
[email protected]'s password:


BusyBox v1.1.2 (2007.09.27-07:17+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

ermittle die aktuelle TTY
tty is "/dev/pts/2"
weitere telnet Verbindung aufgebaut
#


Wenn ich das richtig verstanden habe, verhindert der Parameter, daß man sich mit Paßwort anmelden kann? Da ich das ja möchte, dürfte der Parameter also gar nicht angegeben werden? Dann ist das so jetzt korrekt?

Wenn das dann funktioniert, hast Du wohl was beim Authorized Key falsch gemacht

Dieses statement verstehe ich in dem Zusammenhang nicht . . .

Das funktioniert ja jetzt, also hab ich falsche keys? Kannst Du das bitte nochmal näher erläutern? Ich will mir da keine Sicherheitslücken einbauen und die Doku vom dropbear ist mehr als dürftig. Ich wollte mich da nicht erst in die c-Sourcen einlesen . . .

danke
 
Du kannst dich entweder mit einem Passwort anmelden oder über Authorized keys. Wenn du Passwort-Logins machen willst, dann brauchst du dich nicht um Authorized keys kümmern.

MfG Oliver
 
Und wenn Du schon einen 4GB USB Stick hast, solltest Du die Host Keys nicht jedes mal neu erzeugen, sondern sie auf dem USB Stick speichern.

Der Zweck der Host Keys ist nämlich der, daß sie sich nicht verändern. Das Neuerstellen der Host Keys bei jedem Start ist nur eine (schlechte) Notlösung für Fälle, wo wirklich kein Speicher zur Verfügung steht. Dann besser auf einen Key verzichten und den anderen in der debug.cfg speichern.
 
[Edit frank_m24: Mehrere Beiträge innerhalb weniger Minuten zusammengefasst. Man kann seine Beiträge auch editieren. Lies noch mal die Forumregeln.]
Und wenn Du schon einen 4GB USB Stick hast, solltest Du die Host Keys nicht jedes mal neu erzeugen, sondern sie auf dem USB Stick speichern.

Der Zweck der Host Keys ist nämlich der, daß sie sich nicht verändern. Das Neuerstellen der Host Keys bei jedem Start ist nur eine (schlechte) Notlösung für Fälle, wo wirklich kein Speicher zur Verfügung steht. Dann besser auf einen Key verzichten und den anderen in der debug.cfg speichern.

Sorry Ralf, wollte Dich jetzt nicht vorführen
aber da hast Du dann wohl nicht richtig hingeschaut . . . Die Keys liegen auf dem USBStick und werden auch nur dann erneuert, wenn Sie dort nicht gefunden werden! Dann kann man durch Löschen die Keys einfach erneuern :)

s.o. im Script . . .

[Edit frank_m24: Beitrag 2:]
Du kannst dich entweder mit einem Passwort anmelden oder über Authorized keys. Wenn du Passwort-Logins machen willst, dann brauchst du dich nicht um Authorized keys kümmern.

MfG Oliver

Hi Olistudent,
Dann verstehe ich aber den Beitrag von supafly2k nicht (http://www.ip-phone-forum.de/showthread.php?t=79500&highlight=dropbear+nvi), der in seinem Script (dort abgedruckt) dropbear ohne s-Parameter aufruft, also mit Paßwort arbeiten will? Und dann trotzdem die Keys in dem File generiert. Heißt das jetzt:"Das ist Unsinn?" oder bringe ich da was komplett durcheinander?

Im Moment hab' ich das Gefühl ich stelle mich besonders blöd an . . .
 
Zuletzt bearbeitet von einem Moderator:
Du musst zwischen den Keys unterschieden, die die Verbindung verschlüsseln (authentifizieren, Stichwort: Fingerprint etc. pp - bin da jetzt auch nicht so firm) und denjenigen, welche das Passwort überflüssig machen. Die erzeugten, welche in Deinem Skript drinnen stehen, sind für ersteres und dringend notwendig - der Authorized Key nicht, wenn Du Passwörter benutzt.
Siehe auch hier: http://www.securityfocus.com/infocus/1806

Ansonsten ist es, wie Du es oben gepostet hast, korrekt. Meine Aussage bezieht sich auf die Annahme meinerseits, dass Du den Login via Authorized Keys gestalten wolltest und ist, da dem nicht so ist, redundant. Wenn ein Passwort-Login für Dich ausreichend ist, sollte das Entfernen von "-s" als Lösung ausreichen. (Meiner Ansicht nach genug Sicherheit, am besten nimmt man zuzüglich nicht den Standardport (22).)
 
Hi Neo,

vielen lieben Dank. Nun ist vieles klarer . . .
Nach den Tests konnte ich feststellen, daß das jetzt funktioniert. Paßwortfunktion reicht bei mir denke ich, weil ich den dropbear nur im LAN benutzen werde. Jetzt nur noch das PAßwort ändern und gut.

In dem Zusammenhang habe ich aber noch eine Frage in Bezug auf die PATH-Variable.
Die Zeile in meinem Script:
let PATH=$PATH:/var/tmp/usbstick/files
sollte bewirken, daß mein USBStick über den Suchpfad ansprechbar wird. Das scheint aber nur für diese Session zu gelten egal ob mit let oder export . . .

Gibt es da eine Möglichkeit den Suchpfad dauerhaft einzutragen, so daß der USB-Stick auch bei späteren Telnet/Putty-Aktionen erreichbar bleibt?
 
Sorry Ralf, wollte Dich jetzt nicht vorführen, aber da hast Du dann wohl nicht richtig hingeschaut

Wenn mir nie etwas schlimmeres passiert wäre, als ein Skript nicht genau gelesen zu haben, dann hätte ich keine Probleme.

Gibt es da eine Möglichkeit den Suchpfad dauerhaft einzutragen?

Jede Änderung des Environments (zu dem auch der PATH gehört), wirkt sich nur für den aktuellen Prozeß aus (übrigens auch bei DOS und Windows). Man muß also dafür sorgen, daß der Pfad in jeder Shell richtig gesetzt wird. Ein üblicher Ort dafür ist die Datei /etc/profile, die beim Anmelden automatisch von der Shell abgearbeitet wird. Das einzige Problem ist, daß sich diese Datei im ROM befindet. Man kann aber mit mount --bind eine andere Version drüber mounten.
 
Hi Ralf,
Wenn mir nie etwas schlimmeres passiert wäre, als ein Skript . . .

Ich möchte nur höflich sein und niemandem auf den Schlips treten . . . :)

Auf jeden Fall danke für Deine fruchtbaren Tips. Hat etwas länger gedauert bis ich sie umsetzen konnte. Jetzt funktionierts. Ich habe die neueste Version des Scripts oben im ersten Posting für alle Interessierten neu eingestellt. Für alle, die mit USB-Stick arbeiten, könnte das einen Blick wert sein. Mounting des Sticks, Starten des SSH-Servers, Initialisieren des Swapping auf dem Stick und Ergänzen des Suchpfades in der jeweils neuesten Version der <rc.conf> sind schon enthalten. Für mich fehlen jetzt nur noch die Installation/Konfiguration des openVPN und ein vernünftiges Traffic-Shaping.

Da bleibt für mich zunächst nur noch die folgende Frage offen:
Soweit ich gelesen habe - können Fehler in den Änderungen an der <ar7.cfg>-Konfigurationsdatei zu bösen Totalhängern der Box führen.

Meine Frage nun konkret:
Könnte man aus der <debug.cfg> heraus die <ar7.cfg> wie im letzten Post von Dir beschrieben und bereits von mir im obigen Script realisiert "übermounten" und somit nach dem Ziehen des Sticks die Box wieder im Originalzustand starten, oder wird die <ar7.cfg> lange vor der <debug.cfg> abgearbeitet, so daß eine Änderung zu spät kommt?

Wenn ja, gäbe es dann nicht die Möglichkeit nach dem Mounting die betroffenen Dienste neu mit der geänderten Version zu starten und wenn ja wo und wie? Das wäre eine Frage für jemanden der tiefer in der Materie steckt als ich.

Gibts da ein paar schlaue Leute unter Euch, die dazu etwas sagen könnten? Ich bin gern bereit das dann - wie oben bereits geschehen - umzusetzen und einfließen zu lassen.

Wenn das möglich wäre, könnte man z.B. Einstellungen für das Traffic-Shaping testen, ohne Gefahr zu laufen, sich durch einen Schreibfehler stundenlange Resetting- und Backup-Arbeiten einzufangen . . .
 
Meine Empfehlung zur ar7.cfg ist, die Einstellungen zu sichern und ein Recover Programm bereit zu halten. Damit hat man die Box in wenigen Minuten wieder im Ausgangszustand.

Die debug.cfg wird mit als letztes ausgeführt, zu dem Zeitpunkt ist schon fast alles gestartet. Außerdem könnte es sein, daß die (Gerätedatei) ar7.cfg vor Zugriffen gelöscht wird und neu als Gerätedatei erstellt wird, zumindest an manchen Stellen.

Es gibt eine Datei /bin/ar7cfgchanged, die vermutlich Änderungen an der ar7.cfg wirksam werden lassen soll.
 
Hi,

Empfehlung zur Kenntnis genommen. Ist aber immernoch umständlicher, als das was mir vorschwebt . . .

Für Ideen zu meiner Frage wäre ich trotzdem dankbar . . .

Es gibt eine Datei /bin/ar7cfgchanged, die vermutlich Änderungen an der ar7.cfg wirksam werden lassen soll.

Was meinst Du konkret damit?
 
Ich vermute, daß /bin/ar7cfgchanged aufgerufen wird, nachdem die ar7.cfg von der Weboberfläche geändert wurde.
Das einzige, was die Datei macht, ist übrigens
Code:
/etc/init.d/rc.net reload
 
Heißt das, Ralf, daß das genau das ist, was ich gesucht habe, nämlich den Neustart des/der Dienste, deren Konfiguration in der ar7.cfg stehen, so daß ich nach der Änderung der Datei nur diese Dienst(e) damit neu starte und meine Änderungen werden wirksam?

Ist das Deiner Meinung nach einen Versuch wert?

Danke übrigens für Deine Mühe . . .
 
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.