Dropbear komplett mit OpenSSH ersetzen?

[H.i.M]

Das Problem liegt vermutlich irgendwo beim Server.

Sehe ich auch so. Wo versteckt den dropbear seine konfigurationsdateien?
Muss ich damit sshfs funktioniert vielleicht SFTP mit ins Boot nehmen?

LG H.i.M

 

[RalfFriedl]

Vielleicht gibt es bei zu sshfs eine Beschreibung der Voraussetzungen auf beiden Seiten.

Kann mal jemand diese Beiträge in einen eigenen Thread auslagern? Sie haben mit der ursprünglichen Frage nichts zu tun.

 

[olistudent]

Was sagt denn der syslog dazu?

MfG Oliver

 

[H.i.M]

sshfs + dropbear -Vorraussetzungen

Ich eröffne mal einen neuen Thread. http://www.ip-phone-forum.de/showthread.php?p=1360134#post1360134

 

[MaxMuster]

erste "funktionierende" GUI zum opensshd

Hi,
hier nochmal ein Update für das openssh make. Die GUI für den sshd funktioniert so schonmal, grundsätzlich. Wichtig beim ersten Start sind die key-utils im Image, um dann einmal die Keys zu erzeugen.

sshd lässt sich so starten und ich kann mich verbinden. Ich habe den ganzen "Kram" mit inetd nicht testen können...

Der Patch für sftp zum dropbear vom Beitrag #17 ist weiterhin erforderlich.

Jörg

EDIT Falls es interessitert, die Größenunterschiede sind wirklich enorm, dropbear ist schon kleiner;-):

[...]  67K Jul 10 14:38 openssh-5.2p1/root/usr/bin/scp
[...]  99K Jul 10 14:38 openssh-5.2p1/root/usr/bin/sftp
[...] 328K Jul 10 14:38 openssh-5.2p1/root/usr/bin/ssh
[...] 104K Jul 10 14:38 openssh-5.2p1/root/usr/bin/ssh-add
[...]  85K Jul 10 14:38 openssh-5.2p1/root/usr/bin/ssh-agent
[...] 129K Jul 10 14:38 openssh-5.2p1/root/usr/bin/ssh-keygen
[...] 189K Jul 10 14:38 openssh-5.2p1/root/usr/bin/ssh-keyscan
[...] 194K Jul 10 14:38 openssh-5.2p1/root/usr/bin/ssh-keysign
[...]  35K Jul 10 14:38 openssh-5.2p1/root/usr/bin/ssh-rand-helper
[...]  55K Jul 10 14:38 openssh-5.2p1/root/usr/lib/sftp-server
[...] 402K Jul 10 14:38 openssh-5.2p1/root/usr/sbin/sshd


[...] 239K Jul 10 14:33 dropbear-0.52/root/usr/sbin/dropbearmulti

 

[boba23]

Hey Jörg,

also erst ma vielen Dank, image läuft prinzipiell super mit deinen OpenSSH mods. die Client bins sind alle da und ssh an sich funkt auch, hab allerdings noch nich alles getestet wie port forwarding etc. geh aber davon aus, dass da alles läuft.
Server hab ich mit kompiliert, aber der läßt sich nur manuell starten auf der Shell. Mußte zunächst noch UserPrivilegeSeperation in der config abschalten, und auch mit -f den Pfad zur sshd_conf angeben, weil er die sonst in /etc sucht.
Über das Web Interface läßt sich sshd nicht starten, auch nicht wenn ich mit -f dort den Pfad angebe.

boba

EDIT: blöde Frage ;-) Wie debugge ich denn am besten warum z.B. OpenSSH nicht über das Webinterface startet. Die Meldung "failed" im Webinterface bringt mich nich so recht weiter. Kann mir da jemand kurz helfen?

 

[olistudent]

Auf der Konsole (telnet/ssh) folgendes eingeben:

sh -x /etc/init.d/rc.openssh start

MfG Oliver

 

[hermann72pb]

@boba23: Wenn du schon beim debuggen bist. Du kannst diverse Sachen auf der Box sozusagen "on the fly" erstmal im Ram testen. Z.B. die ganzen cgi-s lassen sich hervorragend im RAM zum debugzwecken platzieren. Du musst lediglich unter /var/mod/.... die Stelle finden, wo ein Symlink auf cgi im FLASH angelegt ist. Du kannst diesen Symlink löschen und stattdessen deine cgi-Datei da rein packen. Dann kannst du diese cgi-Datei im laufenden Betrieb anpassen, ohne ein neues Image jedes Mal zu erzeugen. Ansonsten gibt es auch noch Methode "mount -o bind...".
Jörg hatte die Größen von Binaries gepostet. Dies spricht sehr stark dafür, dass man openssh von vorne an externalisierbar macht. Wobei man wenigstens 2 Stufen der Auslagerung anbieten sollte. Eine ist alle Sachen auszulagern, die nichts mit dem Serverbetrieb zu tun haben (Key-Generator, SSH-Client, etc.). Die Andere ist auch Server-Binaries auszulagern. Du kannst dich damit schon auseinander setzen, boba23. Jörg hat schon den Anfang gelegt und die schwierigsten Sachen erledigt. Jetzt bleibt "nur noch" die Verfeinerung.

MfG

 

[MaxMuster]

Für den Anfang reicht vermutlich schon ein Aufruf ohne "-x", also

sh  /etc/init.d/rc.openssh start

Probleme könnten die nicht vorhandenen Keys und kein keygen sein, das Verzeichnis /var/empty wurde nicht angelegt usw.. Da ist schon hinter zu kommen.

Habe noch die Unschönheit bemerkt, dass sobald irgendein OpenSSH-Teil gewählt wurde auch die GUI drin ist. Da müsste im .mk-file z.B. noch der "else Teil" der Abfrage auf den sshd die GUI löschen, also aus dem Kopf

$(if $(FREETZ_PACKAGE_OPENSSH_SERVER),mkdir -p $(OPENSSH_DEST_DIR)/usr/sbin; cp $(OPENSSH_DIR)/sshd $(OPENSSH_DEST_DIR)/usr/sbin[B], rm -rf $(OPENSSH_DEST_DIR)/etc $(OPENSSH_DEST_DIR)/usr/lib/cgi-bin[/B])

Zudem würde ich den "fest codierten Part", der im .rc-file in die Config geschrieben wird, noch einer GUI-Variable zuweisen und diese "im Experenmodus" editierbar machen...

Jörg

 

[boba23]

Hey Jörg,

ok, über das rc. script hatte ich es nicht versucht, zum testen hab ich einfach nur die sshd bin gestartet und die sucht halt per default die conf woanders.
Nochmal zu dem "Projekt" hier allgemein. Ich glaub ihr erwartet zu viel von mir, wenn ihr glaubt ich könnte mal auf die schnelle hier was anpassen und ein komplettes openssh package zur Verfügung stellen. Dazu brauch ich länger, muss erst ma verstehen wie cgi und die daemons zusammenspielen etc. Ich bin hier blutiger Anfänger was Freetz angeht ;-) Jörg, wenn du die Sache fortführen möchtest, dann versuch ich gern zu helfen, testen etc. wo ich kann. Aber die Geschichte selbst in die Hand zu nehmen übersteigt meine Fähigkeiten und meine Zeit ....

boba

 

[hermann72pb]

@boba23: so schwierig ist es auch nicht. Ich sag es dir als nicht-Programmierer und nicht-Informatiker. Zu den cgi-s und zum Aufbau von FREETZ gibt es genügend Anleitungen in FREETZ-WIKI. Und von Null an musst du auch nicht anfangen. Jörg hat schon das Schwierigste getan: Binaries kompilieren. Er hat sogar WebGUI dafür adaptiert. Es bleiben wirklich nur kosmetische Änderungen.
Klar, frießt es am Anfang viel Zeit. Aber wenn man nicht aufgegeben hat und halbwegs durchgestiegen ist, dann macht es auch Freude.

MfG

 

[MaxMuster]

... sobald irgendein OpenSSH-Teil gewählt wurde auch die GUI drin ist.[...]Zudem würde ich den "fest codierten Part", der im .rc-file in die Config geschrieben wird, noch einer GUI-Variable zuweisen und diese "im Experenmodus" editierbar machen..

So, ein bisschen Regen, und das ist auch noch drin (hoffe ich ;-)).
Damit mache ich mal Schluss damit, es sei denn, das mit dem Starten über die GUI klappt bei dir noch immer nicht.
Vor einem neuen "make" bitte zur Sicherheit im freetz unter "packages" den Ordner und die "."-Datei löschen:

rm packages/.openssh-5.2p1
rm -rf packages/openssh-5.2p1
make

Jörg

 

[olistudent]

Hallo Jörg,
du hast zwar den Kommentar dazu geschrieben, dass es jedes mal durchläuft aber das macht es auch nicht besser. Wenn du dich an dem Makefile von e2fsprogs orientierst und für jedes Binary ein Target machst, dann kann ich deine Arbeit einchecken.

Danke, Oliver

 

[MaxMuster]

Danke! So einen Hinweis habe ich gebraucht, ich hatte keinen sinnvollen Ansatz gefunden. Ich schau mir das in dem e2fsprogs-Paket mal an und versuche dieses so umzustellen. Komme aber erst nächste Woche dazu...

Nur am Rande: Wie könnte ich denn z.B. LDFLAGS für ein Binary setzen, ohne das configure meckert, dass das hier aber anders ist, als im cache?

Fällt dir dazu auch etwas ein?

Jörg

 

[olistudent]

Hast es doch richtig gemacht. Du kannst dann nur beim eigentlich make die Flags aus dem Makefile überschreiben. Dabei muss man aufpassen, dass man kein Flag vergisst.

MfG Oliver

 

[MaxMuster]

Nachdem ich jetzt "Stunden" dran gesessen habe, das .mk-File an das von e2fsprogs anzupassen habe ich gemerkt, dass das .mk genau das gleiche Problem hat wie meines, weswegen ich das dummy-Target überhaupt drin hatte :-
Ein Abwählen von Teilen im menuconfig hat keine Auswirkung, im packages Ordner bleiben die Binaries enthalten.

Ich habe deshalb für alle Teile noch einen else-Teil eingefügt, der das Löschen macht, in der Art:

# SFTP Client
$(OPENSSH_SFTPCLIENT_TARGET_BINARY): $(OPENSSH_SFTPCLIENT_BINARY)
ifeq ($(strip $(FREETZ_OPENSSH_SFTPCLIENT)),y)
	$(INSTALL_BINARY_STRIP)
else
	$(RM) $(OPENSSH_SFTPCLIENT_TARGET_BINARY)
endif

Eine mögliche Alternative wäre natürlich, es beim Kopieren zu lassen und nur ein Dummy-Target davor einzuführen, so in dieser Art

# Dummy for removal
$(OPENSSH_DUMMY_TARGET_BINARY):
	$(RM) -rf $(OPENSSH_DEST_DIR)/usr/sbin $(OPENSSH_DEST_DIR)/usr/bin $(OPENSSH_DEST_DIR)/usr/lib/sftp-server

Habe ich vielleicht was falsch gemacht, und es sollte eigentlich klappen?

Damit es "schön und kurz" wird, benötigte ich eigentlich folgende Möglichkeiten:
- Neues Kompillieren nur, wenn eine bestimmte Option ("statisch") gewählt wird. Ansonsten muss ich eigentlich nur Dateien kopieren oder löschen, ein neuer Compilerlauf ist überflüssig (ich baue einmal mit "all", das ist einfacher)
- Eine "schöne" Möglichkeit für "Multibinary"-Pakete, die Latte an ifeq-else-endif müsste doch auch anders gehen ;-)

Aber so sollte es m.M. nach zumindest funktionieren...

Wegen der mehrfachen Diskussionen/Fragen zum SFTP und den Libs, habe ich mal die Anregung von "Silent-Tears" aufgegriffen

Anmerkung: Vielleicht wäre es sinnvoll, den sftp-Server dort zu entfernen und als Extra-Punkt im menuconfig unterzubringen, das sollte für weniger Verwirrung sorgen, und die "ssh ist toll, ich hake mal alles an"-user vom Aktivieren fernhalten.

Im "dropbear-Menu" habe ich SFTP rausgenommen und beim SFTP die Option eingefügt, es dropbear hinzuzufügen. Dort ist dann auch die "statische" Option...


Jörg

 

[olistudent]

Hallo Jörg,
wir haben bei e2fsprogs genau das gleiche Problem. Wir hatten das auch schonmal eingebaut. Leider musste ich es wieder entfernen, da es nicht wirklich funktioniert hat.

http://trac.freetz.org/changeset/3209/trunk/make/Makefile.in
http://trac.freetz.org/changeset/3227/trunk/make/Makefile.in

Um deine Idee zu realisieren müssten wir noch ein zusätzliches Makro einfügen welches nur das Package-Verzeichnis löscht.

Das Problem an der Implementierung war, dass das Package-Verzeichnis erst gelöscht wurde nachdem geprüft wurde, ob die Package Dateien kopiert werden müssen. Was dazu führte, dass nur noch die Binaries in den Packages waren. Hast du vielleicht mitbekommen.

Ich hab mich auch schon mehrere Stunden mit dem Problem beschäftigt bin aber auf kein sinnvolle Lösung gekommen.

MfG Oliver

 

[MaxMuster]

Noch eine kleine Erweiterung, weil das Paket zusätzlich ja noch eine GUI für "sshd" mitbringt, die je nach menuconfig mitinstalliert oder gelöscht werden muss. Das dropbear-diff ist gleichgeblieben.

So sollte es erstmal reichen, hoffe ich.

Jörg

 

[olistudent]

http://trac.freetz.org/changeset/3537

MfG Oliver

 

[MaxMuster]

@Oliver: Danke und Frage: Ist die dropbear.mk Veränderung nicht etwas zu viel?
Das "$(PKG)_DEPENDS_ON += openssh" ist klar und kann sicher weg, weil diese Abhängigkeit ja im OpenSSH "erledigt" wird.
Aber das "$(PKG)_CONFIG_SUBOPTS += FREETZ_PACKAGE_DROPBEAR_SFTP_SERVER" wird m.E. noch benötigt, damit dropbear neu gebaut wird, wenn die Integration des sftp-Server in dropbear gewählt wird, auch wenn das innerhalb des OpenSSH-Menüs geschieht, oder?

Jörg