dropbearmulti_v2013.62_mipsel kann kein scp

[RalfFriedl]

Am Rande sei bemerkt: Das binary das ich von Radislavs HP laden kann, denn die option -c ... übrigens gar nicht. Das binary von er13 zeit das mit # dropbear -? auch nicht als verfügbarer Parameter an, kann diesen Parameter aber.

Das liegt daran, dass er13 diese Option mit der oben genannten Änderung gerade hinzugefügt hat, aber anscheinend nicht in die Hilfe.

Ich hätte es eleganter gefunden, eine Option einzubauen, mit der man einen anderen PATH statt /usr/bin:/bin hätte angeben können. Das wäre nicht nur für scp hilfreich gewesen, sondern auch für alle anderen Programme, die man möglicherweise auf dem Server ausführen möchte.

 

[er13]

Vielen Dank er13, darf ich mich mit 2 Bier (10 euro) revanchieren? Bitte PM an mich mit Bankverbindung.

Ein Danke reicht mir schon ;-) Wenn Du aber drauf besteht, so kannst Du Deine Spende dem freetz-Projekt zukommen lassen, s. diesen Thread bzw. den PayPal-Button rechts unten auf http://freetz.org

Am Rande sei bemerkt: Das binary das ich von Radislavs HP laden kann, kennt die option -c ... gar nicht. Das binary von er13 zeigt diese Option # dropbear -? auch nicht als verfügbaren Parameter an, kann diesen Parameter aber.

Da hast Du wahrscheinlich was durcheinander gebracht bzw. Dein Symlink zeigt noch auf das andere Binary. Wenn die Option verarbeitet wird, dann sollte auch die Hilfe dazu angezeigt werden, s. diesen Patch

# ./dropbear -?
Unknown argument -?
Dropbear server v2013.62 https://matt.ucc.asn.au/dropbear/dropbear.html
Usage: ./dropbear [options]
-b bannerfile   Display the contents of bannerfile before user login
                (default: none)
-r keyfile  Specify hostkeys (repeatable)
                defaults: 
                dss /var/tmp/dss_host_key
                rsa /var/tmp/rsa_host_key
                ecdsa /var/tmp/dropbear_ecdsa_host_key
-R              Create hostkeys as required
-S sftpserver   Set path to sftp server
                (default: /usr/lib/sftp-server)
-c scppath      Set path to scp command
                (default: scp)
-F              Don't fork into background
-E              Log to stderr rather than syslog
-m              Don't display the motd on login
-w              Disallow root logins
-0              Allow only root logins
-s              Disable password logins
-g              Disable password logins for root
-B              Allow blank password logins
-j              Disable local port forwarding
-k              Disable remote port forwarding
-a              Allow connections to forwarded ports from any host
-p [address:]port
                Listen on specified tcp port (and optionally address),
                up to 10 can be specified
                (default port is 22 if none specified)
-P PidFile      Create pid file PidFile
                (default /var/run/dropbear.pid)
-i              Start for inetd
-W <receive_window_buffer> (default 24576, larger may be faster, max 1MB)
-K <keepalive>  (0 is never, default 0, in seconds)
-I <idle_timeout>  (0 is never, default 0, in seconds)

Ich hätte es eleganter gefunden, eine Option einzubauen, mit der man einen anderen PATH statt /usr/bin:/bin hätte angeben können. Das wäre nicht nur für scp hilfreich gewesen, sondern auch für alle anderen Programme, die man möglicherweise auf dem Server ausführen möchte.

Danke für die Idee, habe nicht daran gedacht. Mal schauen, wie aufwendig das umzusetzen ist.

 

[RalfFriedl]

Danke für die Idee, habe nicht daran gedacht. Mal schauen, wie aufwendig das umzusetzen ist.

Ich vermute, einfacher als die jetzige Änderung.
Das Einfachste wäre, in options.h #define DEFAULT_PATH "/usr/bin:/bin:/var/bin" zu schreiben, dann kann sich jeder das Verzeichnis /var/bin anlegen und dort Programme oder Links ablegen, die vom SSH Server ausgeführt werden können. Dann braucht man überhaupt keine Option mehr.
Alternativ in svr-chansession.c:919 addnewvar("PATH", DEFAULT_PATH); ersetzen durch einen Pfad, der von der Kommandozeile stammt.
Ebenso würde ich Keys usw. eher in /var/etc ablegen als in /var/tmp.

 

[er13]

So der Vorschlag von Ralf umgesetzt:

• -c /pfad/zu/scp Option genauso schnell wie eingeführt auch abgeschafft
• neue Option -x Wert_der_PATH_Variable_für_Kinderprozesse
• DEFAULT_PATH um /var/bin erweitert. Damit kann man, wenn man lediglich ein Verzeichnis hinzufügen möchte, statt -x einfach einen Symlink namens /var/bin anlegen, welcher auf das Verzeichnis zeigt, welches man hinzufügen möchte.

Danke an Ralf für die Inspiration!

Nicht so ausführlich getestet, wie die scppath-Version, sollte aber funktionieren. Feedback trotzdem willkommen ;-)

Edit: mipsel-Version am 19.01.2014 um 12:38 aktualisiert. Diejenigen, die diese davor heruntergeladen haben, bitte nochmal herunterladen. Sorry.

 

[teletux]

dropbearmulti-2013.62-mipsel-overridable-PATH.bz2 (2

getestet auf dern 7270. scp geht, ssh aber nicht mehr:

$ ssh root@fbox
root@fbox's password: 
Write failed: Broken pipe

ps
1736 root        584 S   /var/tmp/dropbear -p 22 -a -r /var/tmp/dropbear_rsa_host_key -d /var/tmp/dropbear_dss_host_key -x /var/tmp/

Zuerst habe ich das dropbearmulti-2013.62-mipsel-overridable-PATH manuell getestet, nach /var/tmp/dropbearmulti kopiert, chmod +x, dann in telnet-Sitzung nach einem kill auf den alten dropbear-Prozess den gleichen wieder gestartet, nur statt -c /var/tmp/scp eben mit -x /var/tmp - und es funktionierte! Dann habe ich es dauerhaft eingebaut, reboot. Seitdem funktioniert es nicht mehr mit dem dropbearmulti-2013.62-mipsel-overridable-PATH. Start ich wieder den vorherigen dropbearmulti mit -c //var/tmp/scp, dann geht wieder beides, ssh und scp. Dann wieder zurück und manuell den neuen mit -x ... gestartet und wieder "broken pipe".

Spende an freez schon gemacht

 

[RalfFriedl]

Warum verwendest Du nicht direkt Freetz, da sind alle Programme an den Stellen, wo sie erwartet werden, ohne dass man sich darum kümmern muss?

 

[er13]

Sorry, mein Fehler, habe beim Übersetzen der mipsel-Version vergessen diese Zeile einzukommentieren. Korrektur wird gleich im Original-Beitrag angehängt. (mips-Binary wurde richtig übersetzt).

Nebenbei bemerkt, der Wert von -x sollte in etwa so lauten /usr/bin:/bin:/mein/extra/pfad. Und wenn Du lediglich ein Verzeichnis hinzufügen möchtest, dann ist die /var/bin-Symlink-Variante die einfachere.

 

[koyaanisqatsi]

Mahlzeit

Ich hab schon an mir gezweifelt, als die MIPSEL es aufeinmal nicht mehr tat, obwohl genauso gestartet wie die MIPS.
Man sollte nach Mitternacht nicht mehr kompilieren.

Nach dem verlinken von /var/bin auf das Verzeichnis der dropbear Binaries, oder Links, funktioniert scp in beide Richtungen.

Binaries, oder Links (USB Dateisystem):
Auf NTFS können Softlinks auf dropbearmulti erstellt werden.
Auf FAT muss die Binary auf das entsprechende Kommando (dropbear, dropbearkey, dbclient, scp, ssh) kopiert werden.

 

[er13]

Man sollte nach Mitternacht nicht mehr kompilieren.

Sehe ich genauso, wird nicht mehr vorkommen ;-)

 

[teletux]

Nebenbei bemerkt, der Wert von -x sollte in etwa so lauten /usr/bin:/bin:/mein/extra/pfad. Und wenn Du lediglich ein Verzeichnis hinzufügen möchtest, dann ist die /var/bin-Symlink-Variante die einfachere.

Danke für den Hinweis mit den Pfaden, jetzt gehts, aber auch erst nachdem ich in -x die Pfade mit angebe, wie ich die in einer Telnet-Sitzung per echo $PATH ermittelt habe, also:

/var/tmp/dropbear -p 22 -a -r /var/tmp/dropbear_rsa_host_key -d /var/tmp/dropbear_dss_host_key -x /bin:/usr/bin:/sbin:/usr/sbin:/var/tmp

BTW: Warum ich nicht freetz mache? Weil ich das für andere mache, die scheuen sich davor alles zu freezen, die FritzBox soll mit einem Werksreset wieder im Originalzustand sein.

 

[RalfFriedl]

habe beim Übersetzen der mipsel-Version vergessen diese Zeile einzukommentieren.

Gibt es denn einen Grund, dropbear (oder andere Programme) statisch zu kompilieren, wenn man ihn mit Freetz einsetzt?
Oder anders gefragt, gibt es einen Grund, den statischen dropbear nicht gleich für den externen Einsatz zu konfigurieren? Evtl. könnte man noch die Option anders benennen, damit das nicht zu Missverständnissen führt.

 

[koyaanisqatsi]

Ich finde das kommt immer darauf an.
Die externalisierten Programme müssen ja auch auf freetz laufen.
Natürlich werden dann schon vorhandene freetz Strukturen genutzt (freetz Verzeichnisse).
Wenn aber eine Statische erzeugt werden kann, sollte sie auch ohne freetz laufen.
Spätestens dann stören die hartkodierten Pfade.

 

[RalfFriedl]

Die Programme, die unter Freetz auf einem externen Speicher abgelegt werden, können trotzdem dynamisch gelinkt werden und sollten auch die Freetz Pfade nutzen. Auch in diesem Fall gibt es keine Grund, Programme statisch zu übersetzen. Mit "externen Einsatz" oben meinte ich Einsatz auf Boxen ohne Freetz. Der Hauptgrund für die statischen Programme ist, dass der dynamische Linker, den AVM verwendet, einige Relocation Einträge nicht unterstützt, die von der Freetz Toolchain generiert werden.

 

[er13]

Der Hauptgrund für die statischen Programme ist, dass der dynamische Linker, den AVM verwendet, einige Relocation Einträge nicht unterstützt, die von der Freetz Toolchain generiert werden.

Das trifft nicht mehr ganz zu. Für uClibc-0.9.28/29 stimmt das noch. Ab uClibc-0.9.32 (eigentlich ab 30, aber es gibt keine AVM-Firmware mehr, in der diese uClibc-Version verwendet wird) läuft das unter Freetz dynamisch gelinkte Binary auch auf den nicht-modifizierten Boxen.

Der einzige Grund, warum man für den externen Einsatz noch diese DB_NONFREETZ-Zeile einkommentieren muss, ist die Tatsache, dass die Leute, die Ihre Boxen nicht freetzen es mittlerweile gewohnt sind, dropbear ohne Angabe der Pfade zu den Host-Keys zu starten (s. als Beispiel #11 in diesem Thread).

 

[radislav]

Hallo zusammen,

@er13: erstmal super Arbeit!

bei mir funktioniert das Ganze nur von extern zu FB, von der FB geht es irgendwie nicht:

[B][fritzmod zu FB:][/B]
[email protected]:/var/tmp# scp ./nc6.help.txt [email protected]:/var/tmp
[email protected]'s password:
nc6.help.txt            100% 1908 1.9KB/s 00:01
[email protected]:/var/tmp#

[B][FB zu fritzmod:][/B]
/var/tmp # ./scp ./bftpd [email protected]:/var/tmp
ssh: No such file or directory
lost connection

Dropbear (mipsel) habe ich von #25 und alles wie beschrieben gestartet und gelinkt... Was mache ich denn falsch? Oder funktioniert das generell nur in eine Richtung?

 

[koyaanisqatsi]

Moin

@Rad: Hast du den dropbear auf Fritz!Box/fritzmod.net auch mit er13 seiner getauscht und neugestartet?
Dann einfach /var/bin auf das Verzeichnis mit dropbear verlinken.
/var

lrwxrwxrwx    1 root     root            24 Jan 19 12:57 bin -> /var/media/NEW_LINK/mips/

...da befindet sich mein dropbear nebst Links.

 

[teletux]

Bei mir gehts in beide Richtungen einwandfrei. Bitte mal ps und dropbearmulti (Byte) überprüfen:

 1624 root        628 S   /var/tmp/dropbear -p 22 -a -r /var/tmp/dropbear_rsa_host_key -d /var/tmp/dropbear_dss_host_key -x /bin:/usr/bin:/sbin:/usr/sbin:/var/tmp 

# ls /var/tmp/dropbearmulti -l
-rwxr-xr-x    1 root     root       404332 Jan 20 12:04 /var/tmp/dropbearmulti

 

[koyaanisqatsi]

...geht also Beides.
Sowohl: dropbear -x [Suchpfade]
(sieht man bei der ps Ausgabe)
...als auch:
/var/bin --> Link auf dropbear Verzeichnis
(sieht man mit ps nicht)

Getestet auch mit ssh/scp (kein dropbear) eines Raspberry Pi in beide Richtungen.

 

[radislav]

Ich habe es rausgefunden! ssh-Link hat gefehlt:

/var/tmp # ls -lha ssh
lrwxrwxrwx    1 root     root          38 Jan 20 14:05 ssh -> /var/tmp/dropbearmulti_v2013.62_mipsel

 

[The Brad]

Der Versuch, per scp von einer nicht-gefreetzten 7390 eine Datei per scp auf eine andere FBox zu kopien, schlägt mit dem folgenden Hinweis fehl:

~ # scp test.txt user@host:/share/mein/pfad
/usr/bin/ssh: No such file or directory

Ich habe sowohl er13s fertiges binary als auch ein frisch aus dem aktuellen trunk selbstkompiliertes dropbear-static versucht; Ausgabe von ps:

2973 root       548 S    /var/tmp/bin/dropbear -p 22 -r /var/tmp/rsa_host_key -d /var/tmp/dss_host_key -S /var/tmp/sftp-server -x /bin:/usr/bin:/sbin:/usr/sbin:/var/tmp:/var/tmp/bin

Erst wenn ich scp per -S /var/tmp/ssh mitgebe, funktioniert es. In der Vergangenheit hatte ich mir geholfen, den Pfad zu ssh in der options.h ( _PATH_SSH_PROGRAM) entsprechend zu definieren, aber das sollte mit den neuesten Änderungen im trunk ja wohl nicht mehr erforderlich sein. Was mache ich falsch?