Frage zu dropbear und sftp-server

[Solamanga]

Hallo,

ich hab mir heute die neueste FW auf meine 7360 draufgemacht und dachte: zieh den dropbear auch mal hoch. Bisher hatte ich den dropbear 2013.58 am Laufen - alles top.
Hab mal den Thread http://www.ip-phone-forum.de/showthread.php?t=264123 gelesen. Nun, bei mir hat der dropbear2013.60 von MaxMuster (http://www.ip-phone-forum.de/showthread.php?t=264063&highlight=dropbear) sofort funktioniert - keine Passwort-Probleme.

ABER: es klappt nur noch der ssh-login, per WinSCP komm ich nicht mehr rein. Ich hab den dropbear dann mal manuell gestartet mit -E und gleich nach dem "Password auth succeeded..." kommt ein "...exited normally..."

Ich denke, der 60er dropbear kommt mit dem 58er sftp-server nicht zurecht :-(

Wie ich gesehen habe, gibt es aktuell schon den 2013.62 dropbear - hat jemand ein Mips-Image davon und den passenden sftp-server? Wäre super....

Viele Grüße an alle!

 

[MaxMuster]

Hier mal ein Versuch, nicht weiter getestet.

 

[Solamanga]

Hallo MaxMuster,

Danke!

Ich werde das wohl morgen Abend mal testen.

Ist es nicht so, dass der dropbear den sftp-server einfach nur startet? Mag sein, dass er dem sftp noch weitere Daten übergibt, aber eigentlich hätte ich gedacht, dass es dem sftp doch egal sein müsste, von welchem dropbear er gestartet wurde und umgekehrt, oder?

Grüße!

 

[Solamanga]

Hallo MaxMuster,

also Deine Binaries funktionieren

der WinSCP hat übrigens wohl nicht mehr funktioniert weil der Standard-Suchpfad für den sftp-server geändert wurde. Der kann jetzt per -S Option direkt angegeben werden.

Ich muss aber zugeben, dass ich mit den neuen Kommandozeilen-Optionen für die Key-Files nicht richtig zurecht komme. Bei Vorgängern hat man per -r bzw -d die RSA bzw DSS -Keyfiles angegeben. Ich hab mir auch einen ecdsa-Key generiert,
wenn ich den db manuell starte kriege ich Fehlermeldungen, dass Key-Files nicht geladen werden konnten, s.u

# ./dropbear -S /var/usb/ssh2/sftp-server -F -E -m -p 4567 -r /var/usb/ssh2/dropbear_rsa_host_key -r /var/usb/ssh2/dropbear_dss_host_key -r /var/usb/ssh2/dropbear_ecdsa_host_key
[6340] Dec 24 22:34:09 Failed loading /mod/etc/ssh/rsa_host_key
[6340] Dec 24 22:34:09 Failed loading /mod/etc/ssh/dss_host_key
[6340] Dec 24 22:34:09 Failed loading /etc/dropbear/dropbear_ecdsa_host_key

Die Verbindung per WinSCP & PuTTY funktioniert aber...


Laut Changelog "-R option to automatically generate hostkeys." - geb ich -R an, aber keine Key-Files, dann meckert der db: No host keys available: irgendwie hab ich da was nicht verstanden....
(Daneben haben sich -leider- einige Kommandozeilen-Optionen und Standard-Pfade geändert. Aber was soll's: der dropbear ist ein gutes Teil....)


Wenn Du mir vielleicht noch Tipps/Erklärung für das -R hättest?

Ansonsten: wieder einmal vielen Dank für Deine Hilfe!!!!! :groesste:

 

[MaxMuster]

EDIT
Die "Fehlermeldung" der fehlenden Default-Pfade scheint normal; wenn er "deine" Keys (die USB-Pfade) nicht lesen könnte, ständen die zusätzlich als "nicht ladbar" im Log.


Zum "-R": Bei mir motzt "anders" mit -R nur die fehlenden Default-Pfade an, läuft aber prinzipiell?!?


Wenn du dann eine Verbindung aufbaust, versucht er bei mir, den ecdsa-Key am "default-Ort" (/etc/dropbear/dropbear_ecdsa_host_key) zu erzeugen, was natürlich fehlschlägt, weil /etc/ nicht beschreibbar ist.
Ein "quick-and-dirty" Workaround ist, im Programm slbst die Pfade "zu drehen":

sed -i '/\/etc\/dropbear/ s#etc/dropbear#var/tmp/keys#' dropbearmulti 
# Ein Test sollte jetzt (z.B. mit --help) den ecdsa-Key-Pfad   "/var/tmp/keys/dropbear_ecdsa_host_key" anzeigen

# und dann auf der Box noch das Ziel-Verzeichnis anlegen:

mkdir -p /var/tmp/keys

Dann klappt das bei mir mit "-R" ...

root@fritz:/var/tmp# ./dropbear -F -E -m -p 4567 -R
[7399] Jan 01 02:03:00 Failed loading /mid/etc/ssh/rsa_host_key
[7399] Jan 01 02:03:00 Failed loading /mid/etc/ssh/dss_host_key
[7399] Jan 01 02:03:00 Failed loading /var/tmp/keys/dropbear_ecdsa_host_key
[7399] Jan 01 02:03:00 Not backgrounding
[7430] Jan 01 02:03:21 Child connection from 192.168.178.12:60398
[7430] Jan 01 02:03:21 Generated hostkey /var/tmp/keys/dropbear_ecdsa_host_key, fingerprint is md5 XX:XX:XX:XX....
[7430] Jan 01 02:03:43 Password auth succeeded for 'root' from 192.168.178.12:60398
[7430] Jan 01 02:03:48 Exit (root): Disconnect received

Letztlich müsste ich mal schauen, ob man nicht auch eine Pfad für "selbst anzulegende Keys" angeben könnte...

 

[Solamanga]

Hi MaxMuster,

also ich denke schon, daß ich das richtige Binary starte, da ich

a) ich den db bei den Tests per telnet starte und zar dort, wo erliegt ....
b) WinSCP mir unter "Menu:Befehle\Protokollinformationen" dropbear_2013.62 anzeigt

Eine Garantie ist das letztere nicht, aber ich traue dem....

Die Binaries patchen gefällt mir nicht so gut.

Ich werd noch ein bisschen experimentieren und berichten....

Viele Grüße!

 

[MaxMuster]

Poste doch bitte mal die komplette Ausgabe von einen Start von

./dropbear -F -E -m -p 4567 -R

(bitte in [noparse]

 und

[/noparse], damit es besser lesbar ist)

EDIT
Hier ein neueres Binary. Alle Keys werden per default unter /var/tmp/ gesucht, das ist auch beschreibbar ;-)

 

[Solamanga]

Hallo MaxMuster,
hier die Ausgabe von

./dropbear -F -E -m -p 4567 -R

# ./dropbear -F -E -m -p 4567 -R
[3215] Dec 26 15:44:22 Failed loading /mod/etc/ssh/rsa_host_key
[3215] Dec 26 15:44:22 Failed loading /mod/etc/ssh/dss_host_key
[3215] Dec 26 15:44:22 Failed loading /etc/dropbear/dropbear_ecdsa_host_key
[3215] Dec 26 15:44:22 Not backgrounding

Das neue Image meckert nicht mehr ....

Danke nochmals!

PS: sooo dringend, dass Du das gestern um 23:39 hättest generieren müssen war's nun wirklich nicht

 

[MaxMuster]

Diese Ausgabe ist aber von den "vorletzten" Binary?!? "Das letzte" sollte als Suchpfad für die Keys immer "/var/tmp/XY" haben, nicht mehr /mod/etc bzw. /etc/dropbear.

 

[Solamanga]

Hallo MaxMuster,

ja, sorry, war etwas verwirrt, Du hast Recht: Dein neues Image macht alles richtig. Ich hab mich wohl auch nicht klar ausgedrückt.

Ich hätte da aber nochmal eine Frage zum dropbear: ich hab mir die Keys und Fingerprints per "dropbearkey -y " ausgeben lassen.
Es kommt sowas raus:

# ./dropbearkey -y -f dropbear_rsa_host_key
Public key portion is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQ.............................usw....

Fingerprint: md5 02:55:b0:70:82:08:23:e9:b7:f0:11:7d:ac:78:a6:cd

Der WinSCP gibt mir bei den Server-Infos aber einen anderen Fingerprint aus:

ssh-rsa 2064 00:13:21:71:cc:90:6b:d5:96:40:78:01:9b:f3:86:cc

Es wäre wohl nicht schlecht, wenn beide Fingerprints übereinstimmen, oder? Die Verbindung mache ich im lokalen Netz, da wird wohl keine dazwischen sitzen, was passt hier nicht?

Viele Grüße!

 

[Solamanga]

@MaxMuster

Hallo, ich hab endlich Zeit gefunden mich in Ruhe mit dem Thema zu beschäftigen.

Also, der Key-Fingerprint, den mir WinSCP (und auch ein Bitvise-Client) anzeigen stimmt: er gehört zu dem RSA-Key, der in /var/tmp/dropbear_rsa_key liegt!

Starten tue ich den db aber per:

/var/usb/ssh/dropbear -m -p 4567 -S /var/usb/ssh/sftp-server -r /var/usb/ssh/dropbear_rsa_host_key -r /var/usb/ssh/dropbear_dss_host_key -r /var/usb/ssh/dropbear_ecdsa_host_key

(Oder mache ich da etwas falsch?)

Ausgeben tut dropbearkey aber wohl den der mit -r angegebenen Datei, also von /var/usb/ssh/dropbear_rsa_host_key


Das bedeutet schlicht und ergreifend: dropbear ignoriert wohl die -r Option komplett und nimmt stattdessen *immer* die Standard-Keyfiles in /var/tmp/.
(Auch wenn ich -r /var/tmp/dropbear_rsa_host_key angebe, nimmt er dropbear_rsa_key usw.)

Beende ich einen Client (egal ob WinSCP oder Bitvise) kriege ich eine Fehlermeldung:

Aiee, segfault! You should probably report this as a bug to the developer

Läuft aber weiter, d.h. weitere Verbindungen sind möglich.

Das mit der -R Option, also dem Neuerstellen der Keys scheint mir auch unpraktisch:
beim ersten Verbindungsaufbau generiert db dann einen 2063-Bit RSA-Key /var/tmp/dropbear_rsa_key, das dauert etwas lange
Außerdem wird natürlich bei jedem Neustart der Box ein neuer Key generiert und damit muss man sich den Fingerprint erneut ausgeben lassen.

Trotzdem gefällt er mir, dein dropbear

 

[MaxMuster]

Es gibt auch andere Berichte von "Problemen beim Beenden" einer Verbindung, aber wohl noch keine Anzeichen/Lösung dafür...

Das mit den Keys ist jetzt scheinbar so gelöst, dass man eine "belibige" Anzahl von Keys angeben kann (sie muss nur < MAX_KEYS sein). Leider scheinbar aber nicht, welcher wirklich genutzt wird, was gerade auch bei der "-R" Optione meiner Meinung nicht gut gelöst ist. Ich muss hier beim Übersetzen einen "beschreibbaren" Pfad als Default angeben, weil nur dort die Keys angelegt werden, nicht bei den mit "-r" übergebenen Orten...

 

[koyaanisqatsi]

Abend

Zur Info:
Den Dropbear starte ich einfach mal so: dropbear -R -m
Aber, die Schlüssel hab ich vorher mit dropbearkey erstellt (1024 bit) und nach /var/tmp kopiert.

koyash # l /var/tmp/dropbear_*
-rwxr-xr-x    1 root     root           457 Dec 26 12:24 /var/tmp/dropbear_dss_key*
-rwxr-xr-x    1 root     root           427 Dec 26 12:24 /var/tmp/dropbear_rsa_key*

...das scheint völlig problemlos zu funktionieren.

 

[Solamanga]

Hallo koya.... (dein Name ist mir zu kompliziert, ich kürze ab),

funktionieren tut die -R Option schon, keine Frage.

Wenn man aber sicher sein will, dass man direkt mit dem SSH-Server verbunden ist (und nicht über einen Middleman), prüft man i.d.R. die Fingerprints der Keys. Und bei -R werden eben neue Keys erstellt, oder hab ich was übersehen? Wenn Du die vorher erstellte Keyfiles nach /var/tmp kopierst, was macht dann -R ?

Bei mir war der mit -R erzeugte Key übrigens einen 2063 Bit RSA Key - lustige Keylänge.
Ich will zwar nicht paranoid erscheinen, aber 1024 Bit RSA-Keys sind heutzutage zu kurz für unsere UnitedStasiland-Freunde.

@MaxMuster: wie gesagt, ich bleib bei Deinem dropbear. Die Exception am Ende ist unschön, wenn aber weiter nix passiert....


Grüße!!

 

[RalfFriedl]

Keys bei jedem Neustart neu zu erzeugen ist allerdings eine schlechte Idee, also warum sich Gedanken darüber machen, wohin der so erzeugte Key geschrieben wird?

Der Segfault am Ende killt den Prozess, der für die Verbindung zuständig war, und nicht den, der auf weitere Verbindungen wartet, daher kann man weiterhin auf die Box zugreifen,