dropbear

The Hit-Man

Neuer User
Mitglied seit
2 Okt 2013
Beiträge
126
Punkte für Reaktionen
3
Punkte
18
Irgendwie stehe ich gerade wie Ox vorm Berg ...
Auf meiner FreetzBox ist dropbear installiert. Nun möchte ich mich gerne VON der FRITZBOX zu einem SHH-SERVER verbinden.
Ich habe mir per :

dropbearkey -t rsa -f meinkey.private
dropbearkey -y -f meinkey.private | grep "^ssh-rsa " >> meinkey.public

eine Schlüsselpaar erstellt. Den Public Key habe ich auf dem Server unter dem Benutzernamen .ssh/authorized_keys eingefügt.
Nun versuche ich mich passwortlos mit dem Server zu verbinden:

ssh benutzer@SERVER_IP -i meinkey.private -oPort=45868


Allerdings bekomme ich immer die Meldung:
ssh: Connection to benutzer@SERVER_IP:45868 exited: No auth methods could be used.

Im Netz habe ich nix brauchbares gefunden. Mit der normalen SSH, zum Beispiel von meinem Rechner aus, zum Server, kein Problem. Nur dropbear macht mir da Probleme. Das komische aber ist, das es mal funtioniert hat.
Weiß da jemand was?
 
Ein vernünftig übersetzter dropbearmulti verwendet DEBUG_TRACE als Einstellung (https://github.com/mkj/dropbear/blob/a8d6dac2c53f430bb5721f913478bd294d8b52da/default_options.h#L42) ... damit gibt es dann auch eine Option -v beim Aufruf von ssh, mit der man genau sehen kann, was im SSH-Dialog bei der Authentifizierung läuft und woran es am Ende scheitert:
Rich (BBCode):
~ # /var/custom/usr/bin/ssh -v
Dropbear SSH client v2019.78-yourfritz https://matt.ucc.asn.au/dropbear/dropbear.html
Usage: /var/custom/usr/bin/ssh [options] [user@]host[/port][,[user@]host/port],...] [command]
-p <remoteport>
-l <username>
-t    Allocate a pty
-T    Don't allocate a pty
-N    Don't run a remote command
-f    Run in background after auth
-y    Always accept remote host key if unknown
-y -y Don't perform any remote host key checking (caution)
-s    Request a subsystem (use by external sftp)
-o option     Set option in OpenSSH-like format ('-o help' to list options)
-L <[listenaddress:]listenport:remotehost:remoteport> Local port forwarding
-g    Allow remote hosts to connect to forwarded ports
-R <[listenaddress:]listenport:remotehost:remoteport> Remote port forwarding
-W <receive_window_buffer> (default 5181268, larger may be faster, max 1MB)
-K <keepalive>  (0 is never, default 24576)
-I <idle_timeout>  (0 is never, default 10)
-B <endhost:endport> Netcat-alike forwarding
-J <proxy_program> Use program pipe rather than TCP connection
-c <cipher list> Specify preferred ciphers ('-c help' to list options)
-m <MAC list> Specify preferred MACs for packet verification (or '-m help')
-b    [bind_address][:bind_port]
-V    Version
-v    verbose (compiled with DEBUG_TRACE)

This is a special version created from the Freetz trunk and it's
stripped down to the really needed functions to be usable on a FRITZ!Box
device with the RSA key stored there. It supports only a limited set of
KEX and CIPHER algorithms and isn't backward compatible to older SSH
clients (by intention). It allows only root user logins with public key
authentication, no other user(s) and/or methods will be accepted.
It's not optimized for size and the usually disabled TRACE output option
is explicitly enabled.
The FRITZ!Box key (/var/flash/websrv_ssl_key.pem) is the only supported
RSA key file for both server and client usage and it will be read only
from this location with automatic decryption.

~ # /var/custom/usr/bin/ssh -v pi4
TRACE  (5388) 0.000000: host is: pi4
TRACE  (5388) 0.049839: loadidentityfile /var/flash/websrv_ssl_key.pem
TRACE  (5388) 0.246334: using device key file from /var/flash/websrv_ssl_key.pem
TRACE  (5388) 0.246651: enter buf_get_rsa_priv_key
TRACE  (5388) 0.246771: enter buf_get_rsa_pub_key
TRACE  (5388) 0.247293: leave buf_get_rsa_pub_key: success
TRACE  (5388) 0.248192: leave buf_get_rsa_priv_key
TRACE  (5388) 0.248358: user='root' host='pi4' port='22' bind_address='(null)' bind_port='(null)'
TRACE  (5388) 0.257180: Error resolving: Name or service not known
TRACE  (5388) 0.257505: enter session_init
TRACE  (5388) 0.258021: update_channel_prio
TRACE  (5388) 0.258181: leave update_channel_prio: no socket
TRACE  (5388) 0.258395: setnonblocking: 3
TRACE  (5388) 0.258611: leave setnonblocking
TRACE  (5388) 0.258769: setnonblocking: 4
TRACE  (5388) 0.258996: leave setnonblocking
TRACE  (5388) 0.259318: leave session_init
TRACE  (5388) 0.259596: proxy command PID='0'
TRACE  (5388) 0.259854: kexinitialise()
TRACE  (5388) 0.260094: algolist add 'curve25519-sha256,[email protected],ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,kexguess2@
matt.ucc.asn.au'
TRACE  (5388) 0.260343: algolist add 'ssh-rsa'
TRACE  (5388) 0.260555: algolist add 'aes128-ctr,aes256-ctr'
TRACE  (5388) 0.260779: algolist add 'aes128-ctr,aes256-ctr'
TRACE  (5388) 0.261002: algolist add 'hmac-sha1,hmac-sha2-256'
TRACE  (5388) 0.261218: algolist add 'hmac-sha1,hmac-sha2-256'
TRACE  (5388) 0.261444: algolist add '[email protected],zlib,none'
TRACE  (5388) 0.261659: algolist add '[email protected],zlib,none'
TRACE  (5388) 0.261956: send_msg_kexdh_init()
TRACE  (5388) 0.270995: DATAALLOWED=0
TRACE  (5388) 0.271145: -> KEXINIT
TRACE  (5388) 0.271307: enter session_cleanup
TRACE  (5388) 0.271415: enter chancleanup
TRACE  (5388) 0.271519: leave chancleanup
TRACE  (5388) 0.271640: enter cli_tty_cleanup
TRACE  (5388) 0.271742: leave cli_tty_cleanup: not in raw mode
TRACE  (5388) 0.271846: empty queue dequeing
TRACE  (5388) 0.271988: leave session_cleanup

/var/custom/usr/bin/ssh: Connection to root@pi4:22 exited: Connect failed: Error resolving 'pi4' port '22'. Name or service not known
~ #
Auch wenn's sich beim Beispiel im meine Spezialversion handelt, gibt es die notwendige Option -v auch in der regulären Version, wenn ich mich richtig erinnere - zumindest habe ich die Patches dazu (ohne die Geschichte mit dem Box-Key) mal eingereicht vor vielen Jahren, wenn mich nicht alles täuscht.

Aber diese eine Einstellung hat man auch ganz schnell selbst von Hand geändert ... einfach einen passenden Patch erzeugen und unter patches ablegen, danach Paket und Image neu bauen.

Außer man kommt durchs Raten dann doch noch drauf, woran es wohl liegen könnte ... aber eine der beiden Seiten (Server oder Client) muß man vermutlich zu mehr Geschwätzigkeit überreden und da es auf der Server-Seite alle Clients betrifft (auch wenn das reversibel ist), ist das nicht jedermanns Sache.
 
Sehr komisch, den verbose mode habe ich gar nicht ...

Code:
root@fritz:/var/mod/root# ssh -v
WARNING: Ignoring unknown option -v
Dropbear SSH client v2020.81 https://matt.ucc.asn.au/dropbear/dropbear.html
Usage: ssh [options] [user@]host[/port][,[user@]host/port],...] [command]
-p <remoteport>
-l <username>
-t    Allocate a pty
-T    Don't allocate a pty
-N    Don't run a remote command
-f    Run in background after auth
-y    Always accept remote host key if unknown
-y -y Don't perform any remote host key checking (caution)
-s    Request a subsystem (use by external sftp)
-o option     Set option in OpenSSH-like format ('-o help' to list options)
-i <identityfile>   (multiple allowed, default .ssh/id_dropbear)
-A    Enable agent auth forwarding
-L <[listenaddress:]listenport:remotehost:remoteport> Local port forwarding
-g    Allow remote hosts to connect to forwarded ports
-R <[listenaddress:]listenport:remotehost:remoteport> Remote port forwarding
-W <receive_window_buffer> (default 24576, larger may be faster, max 1MB)
-K <keepalive>  (0 is never, default 0)
-I <idle_timeout>  (0 is never, default 0)
-B <endhost:endport> Netcat-alike forwarding
-J <proxy_program> Use program pipe rather than TCP connection
-c <cipher list> Specify preferred ciphers ('-c help' to list options)
-m <MAC list> Specify preferred MACs for packet verification (or '-m help')
-b    [bind_address][:bind_port]
-V    Version
 
Deshalb schrieb ich ja, daß dafür das Paket mit DEBUG_TRACE übersetzt werden muß - den Link hatte ich auch schon oben angebracht. Man kann das auch mit in die localoptions.h packen (das ist mittlerweile die Präferenz beim "Customizing" der dropbear-Settings) ... aber irgendwo muß es halt stehen, wenn das Paket übersetzt wird. Daher ja auch der Hinweis, daß dann Paket und Image neu gebaut werden müssen.
 
oha, so gut bin ich da noch nicht drin. Wollte ungern in den freetz-sourcen rum fuckeln ...
 
Das ist EIN EINZIGER Patch ... und das auch nur, weil es dafür keine Option gibt. Vielleicht gelingt es Dir ja, @cuma zum Einbau einer solchen zu überreden ... immerhin gibt es noch genug andere Anwendungsfälle, wo man ein paar mehr Infos durchaus gut brauchen kann und bei den aktuellen Modellen macht es ohnehin nicht mehr viel Sinn, jedes Byte zu zählen. Das trägt zwar tatsächlich etwas auf bei der Konfektionsgröße des dropbearmulti, aber da fällt mir dann auch nur ein: "Alles was Spaß macht, ist entweder illegal, unmoralisch oder macht dick."

EDIT: Wobei wir hier ja im Freetz-Unterforum sind ... meinst Du tatsächlich das "Original" oder doch Freetz-NG? Bei ersterem ist die Idee, daß @cuma das über eine Option regeln könnte, natürlich obsolet.
 
ja, ich schau mal. Ich hatte hier auch mal jemanden der images gebaut hat. Wollte aber nicht jedem auf die Nüsse damit gehen. Du wirst es nicht glauben. Seit ca 15 Jahren benutze ich Linux und baue mir auch da Pakete selbst aber ich habe es nie verstanden ( bis heute ), wie man mit patches um geht.

"Alles was Spaß macht, ist entweder illegal, unmoralisch oder macht dick."
da haste Recht ;) Zum Glück dürfen wir nach 21h noch im Netz sein ;)

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

ähm, vielleicht noch eine Frage. Wieso sieht der private key, von dropbear so anders aus, wie der von der normalen SSH?
 
Zuletzt bearbeitet von einem Moderator:
Ganz einfach weil dropbear da ein eigenes Format verwendet ... auch das von OpenSSH ist nicht zwingend "normal", wobei es das iirc sogar in irgendeine Spezifikation geschafft hat (ob vor oder nach OpenSSH, weiß ich gar nicht mehr).

Es gibt auch noch ein dropbearconvert für die einfache Umwandlung zwischen dem OpenSSH- und dem dropbear-Format, wobei das vermutlich auf der Box nicht dabei ist (aber das kann man ja auch auf einem anderen System machen).

Ich hoffe aber, daß Du Dich überzeugt hast, daß mit dem dropbearkey auch tatsächlich ein gültiger öffentlicher Schlüssel am Ende in der authorized_keys gelandet ist.

Eine andere Option zum Testen, ob das nun auf der Client- oder der Server-Seite problematisch ist, wäre die Konvertierung in einen OpenSSH-Key und der Versuch von einem anderen System aus, mit diesem Key eine Verbindung zum (unveränderten) Server aufzubauen. Klappt das, liegt's am Client - ansonsten stimmt irgendetwas auf dem Server nicht. Man kann (nein, man sollte) die authorized_keys auch mal einer "Sichtprüfung" unterziehen - ich habe schon viel zu oft Leute gesehen, die zwar mit solchen Kommandos das richtige Ziel erreichen wollten (eben das Hinzufügen des PubKeys zur Datei), dabei aber irgendwelche Fehler eingebaut hatten und sich dann vollkommen umsonst um irgendwelche anderen Probleme sorgten, obwohl nur das Hinzufügen nicht geklappt hatte (danach müssen die Rechte auch noch stimmen und da darf max. 600 (also u=rw) gesetzt sein) und sie es versäumten, da als erstes noch einmal zu kontrollieren.
 
moment mal, ich habe aus Spass mal den richten SSH Server und Client auf der Box installiert. Ich nahm Dropbox, weil es weit aus schlanker ist. Tz, habe sogar damit Probleme. Allerdings läßt sich das ja debuggen. Da sehe ich zu mindest genau die gleiche Meldung. Kann dir leider den debug hier nicht mit schicken weil da ja eben die Server IP dabei ist, usw ...
Das muß wohl echt an mir liegen oder an dem Server.

--

so, ich habe einfach mal den user auf dem Server gelöscht, neu angelegt und Schlüssel kopiert. Das geht schon mal. Jetzt versuche ich das ganze noch mal mit dropbear.

--

Geht jetzt auch mit dropbear und meinem Schlüssel. Leider kann ich dir nicht sagen, wo ran es lag ... Hatte auch die Dateirechte alle kontrolliert. Die stimmten ja auch alle ... Hmmmmmmm
Trotzdem danke für Deine Hilfe auch wenn ich wie gesagt, nicht weiß wo ran es lag. Ich mag so was nicht wenn ich den Fehler nicht finden konnte.
Hab also einfach auf dem Server den Benutzer gelöscht und dann ganz normal den public key auf dem Server unter dem Benutzer kopiert ( copy/paste ).
 
Zuletzt bearbeitet von einem Moderator:
@The Hit-Man ich hab nun genung hinter Dir hergewischt.
Keine Doppelposts (siehe 5.10)
Via "Edit" den gesamten Inhalt kopieren, in einen neuen Post einfügen und zB mit einem -- Aktualisiert -- vom neuen Text abtrennen und den vorherigen (Doppel) Post (selbst) löschen.

Somit wird eine Notification gesendet und jeder bekommt es mit.

bitte die drei Posts selbst zusammenfügen und ab sofort daran halten.
Danke
 
@stoney:
keine ahnung, wie wo was du alles doppelt an siehst ...

die lösung war, das home verzeichniss darf nur 077 sein und nicht 777 ...
sorry war mein fehler ...
 
das home verzeichniss darf nur 077 sein
DAS würde ich aber heftig bezweifeln (und ich MUSS es korrigieren (ist ein innerer Zwang), bevor andere davon irritiert werden).

Korrekt wäre 700, denn das entspricht dann u=rwx und ein Home-Verzeichnis, in dem der "Bewohner" selbst gar nicht schreiben darf, macht auch nur sehr begrenzt Sinn.

SSH-Server mögen es nicht, wenn die Verzeichnisse auf dem Weg zu den Konfigurationsdateien für den Benutzer von jemand anderem geschrieben werden könn(t)en ... üblicherweise beschränken sich Test, die diese Einstellungen überprüfen, daher auch darauf, daß andere dort keine Schreibrechte haben.

Bei OpenSSH als Server sieht das mit den "erzwungenen" Dateiberechtigungen üblicherweise so aus: https://man.openbsd.org/sshd#FILES - man darf Empfehlungen und Zwänge da aber nicht verwechseln.

Bei dropbear (den die meisten sicherlich eher als Server auf der Box einsetzen und nicht unbedingt als Client) ist das ähnlich: https://github.com/mkj/dropbear/blob/846d38fe4319c517683ac3df1796b3bc0180be14/svr-authpubkey.c#L484 - auch hier werden das Home-Verzeichnis, dessen Unterverzeichnis .ssh und auch die darin enthaltene authorized_keys dahingehend geprüft, daß andere als der Eigentümer dort nicht schreiben dürfen und natürlich auch, daß der Eigentümer tatsächlich der richtige Benutzer (oder der Superuser) ist - denn ansonsten sind die Rechte für den Eigentümer ja auch nur Makulatur, wenn das ein ganz anderer ist, der diese Datei irgendwann mal geschrieben hat (und sie dann auch weiterhin ändern darf, wenn er den Weg dahin kennt/findet).

Es gibt also durchaus unterschiedliche "Erfordernisse", was diese Berechtigungen angeht ... aber eines ist sicher: 077 könnte höchstens als umask, die beim Erzeugen einer neuen Datei notwendig wäre, durchgehen - dazu paßt dann aber ein:
auch nicht, weil mit so einer umask ja niemand mehr (mit Ausnahme des Superusers) auf die Datei zugreifen könnte.
 
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.