OpenSSH Probelm (Trunk rev. 13805)

Goblin2605

Neuer User
Mitglied seit
30 Jun 2016
Beiträge
12
Punkte für Reaktionen
0
Punkte
0
Guten Tag
ich habe folgendes problem in meiner derzeitigen freetz Trunk mit openssh wenn ich es starten will

Bildschirmfoto_2016-06-30_13-49-01.jpg

Bildschirmfoto_2016-06-30_14-08-42.jpg

Ich hoffe ihr wisst um einen rat wie ich das problem lösen kann, ich weiß nicht wann es genau angefangen hat aber es dürfte ca. 2 wochen her sein, in älteren Trunks von vor ca. 2 oder 3 Wochen ging noch alles.
 

Anhänge

  • Bildschirmfoto_2016-06-30_13-49-01.png
    Bildschirmfoto_2016-06-30_13-49-01.png
    98.6 KB · Aufrufe: 14
  • Bildschirmfoto_2016-06-30_14-08-42.png
    Bildschirmfoto_2016-06-30_14-08-42.png
    253.8 KB · Aufrufe: 11
Zuletzt bearbeitet:
Ich bin raus ... dazu fällt mir nichts ein. Solche weißen Stellen kenne ich nur als "terra incognita" auf den Landkarten aus dem Geografie-Unterricht (ja, als ich das gelernt habe, war Amerika noch unentdeckt).

EDIT: Das unentdeckte Land im IPPF soll dem HTML-Quelltext zufolge ein PNG-Bild (inline, base64-kodiert) sein ... zumindest mein FF 47.0 kann (oder will) das nicht dekodieren.
 
Zuletzt bearbeitet:
Ich kann es gerne nochmal in jpeg einfügen
 
Ansonsten ... wenn da OpenSSH mit der Option "--without-openssl" gebaut wurde (die Zeitangabe könnte vermutlich auch etwas mehr Präzision vertragen), dann kennt das nur "ed25519" als EC-Key. Alle anderen Key-Types werden von der OpenSSL-Library ins Spiel eingebracht. Ob das nur ein Problem der Definition in ssh-keygen ist oder nicht, kann ich nicht sagen und will ich jetzt auch nicht untersuchen. Mit vorhandenem RSA-Key sollte aber auch OpenSSH mit Option "--without-openssl" arbeiten können - zumindest der SFTP-Server funktioniert einwandfrei (bei mir jedenfalls). Wenn es also nur an der Generierung der Keys liegt, bleiben zwei Optionen (u.a. das externe Erzeugen der Keys - ich komme ohnehin nicht ganz mit, warum hier (wo es ja wohl nicht der erste Einsatz von Freetz ist) überhaupt Keys generiert werden sollen), ansonsten nur ein neues Image ohne die Option "WITHOUT_OPENSSL" => CS 13781 - wobei das eben so gar nicht zu der Zeitangabe in #1 passen sollte, denn der Patch ist gerade mal 8 Tage drin.
 
Ja ich meinete ja ca. 2 wochen seit wann es genau ist wusste ich natürlich nicht, ich werde mal versuchen eine rsa und dsa key extern zu erzeugen und schauen was dabei rum kommt ob sich damit der server starten lässt
 
Kannst Du Dir sparen ... habe ich gerade versucht. Wenn man "--without-openssl" verwendet, kann OpenSSH offenbar wirklich nur noch "ed25519" als KEX ... ich finde keine belastbare Dokumentation für den vollen Umfang der Auswirkungen (von --without-openssl) beim Schlüsselaustausch ... bei der Verschlüsselung selbst werden offenbar einige Algorithmen (in erster Linie AES-basierte) direkt von OpenSSH implementiert, aber beim Schlüsselaustausch nur der (allerdings ja wirklich moderne und sauschnelle) ed25519 - da ich seit einiger Zeit nur noch mit ed25519-Identities arbeite (wenn die Gegenstelle sie versteht), ist mir das noch nicht aufgefallen. Nun könnte man darüber nachdenken, ob man dem OpenSSH-CGI die ED25519-Schlüsselerzeugung (und -Verwendung) beibringt ... zumindest bringt das einen erheblich schnelleren Verbindungsaufbau für so eine SSH-Sitzung. Da auch PuTTY (von vielen Windows-Nutzern ja verwendet) das inzwischen beherrscht, wäre das ggf. eine Überlegung wert ... auch unabhängig davon, daß man eben für die Verwendung mit RSA-Keys dann OpenSSH doch wieder mit OpenSSL-Unterstützung bauen muß.
 
Zuletzt bearbeitet:
Leider ohne erfolg, habe jetz die ssh host keys auf meinem PC erzeugt und rüber auf die box getan, aber es kommt immer noch die gleiche meldung wie in Foto 1

- - - Aktualisiert - - -

Naja gut, egal werde es dann mal mit dem ed25519 keys probieren, muss ich da noch etwas spieziel an meinen meiner sshd config vornehmen auf der fritzbox


Was ich natürlich auch mal probieren werde ist, das so wie du ja meinntest das man das Image mit openssl kompilieren muss
 
Zuletzt bearbeitet:
Das Start-Skript im Freetz-Trunk kann auch nicht so richtig damit umgehen, wenn man ed25519-Keys verwenden will.

Solange Du also nicht den sshd aus der rc.custom starten willst, solltest Du eher ein neues Image erzeugen, wo dann Zeile 25 in openssh.mk auskommentiert ist. Bei der Verwendung von OpenSSH als eigenständiges Paket (die meisten verwenden es wahrscheinlich nur als Ergänzung zum dropbear-Paket, weil das keinen eigenen SFTP-Server hat) im Rahmen von Freetz ist die Auswahl von "--without-openssl" vielleicht doch keine so gute Idee und vermutlich wird er13 das dann auch schnellstmöglich wieder rückgängig machen - zumindest müßte man es wohl konfigurierbar machen, damit man beim Erstellen des OpenSSH-Paketes als eigenständige Lösung dann diese Option zwangsweise abschalten kann.

- - - Aktualisiert - - -

Ich baue mir mal einen OpenSSH-Daemon mit OpenSSL und messe mal für die verschiedenen Schlüssellängen und Algorithmen, wie lange der Austausch bei der 7490 so dauert.

Bisher spricht für meine Belange nur der ohnehin vorhandene Key im FRITZ!OS dafür, daß man beim RSA bleibt, wobei ich ED25519 beim Dropbear irgendwie bei meinen letzten Versuchen (die sind aber auch schon mind. 6 Monate her) auch nicht zum Laufen bekam (und seitdem habe ich ECC aus dem Dropbear komplett verbannt in meinem Fork).
 
Was wäre denn die bessere verschlüsselungsart von der sicherheit her, hatte bisher immer RSA 4096 bit

Grund für das Ganze warum das laufen und sicher sein soll ist, das dieser router nach russland zu den eltern meiner freudin gehen soll
Betrieben soll das ganze mit
pyload mit https login
transmision torrent mit ssl
minidlna
samba
ssh und sftp um z.b. Filme vom download ordner in den filme ordner verschieben zu können,
Naja und und deswegen das ganze, das ich eben von deutschland aus alles sicher mit ssl bzw. ssh verschüsselt bedienen kann
 
Zuletzt bearbeitet:
Das bezieht sich sicherlich auf die Schlüssellänge des Schlüsselpaars, mit dem der Austausch eines Sitzungsschlüssels (der ist dann wieder für eine symmetrische Verschlüsselung, weil asymmetrisch dafür ungeeignet und auch zu aufwendig wäre) abgesichert wird. Da sind 4096-Bit-RSA-Schlüssel schon (nach derzeitigem Stand) ausreichend .. aber mit steigender Schlüssellänge dauert auch der Austausch am Beginn der Sitzung entsprechend länger (erst recht auf doch eher schwachen Prozessoren), bei der 7490 so zwischen 6 und 8 Sekunden. Bei elliptischen Kurven (dazu gehören ECDSA und ED25519) reichen auch kürzere Schlüssel aus, um dasselbe Sicherheitsniveau zu erreichen, da dauert dann der Schlüsselaustausch auch nicht mehr so lange.

Bei der Verschlüsselung einer SSH-Sitzung (also der übertragenen Daten) spielt dann der am Beginn verwendete KEX-Algorithmus keine Rolle mehr. Hier sollte man nur dafür sorgen, daß man keine Cipher-Suite mit CBC verwendet, da hat das SSH-Protokoll eine Schwachstelle. Die wurde zwar etwas entschärft in den meisten Implementierungen, aber ist nicht verschwunden (da im der Spezifikation eben schon enthalten). Am besten setzt man nur CTR-Modi ein oder - wenn das die beteiligten Parteien können - auch GCM.
 
So folgender sachverhalt, ich habe das ganze jetz zum laufen bekommen über dropbear mit ECDSA , jetz hab ich da noch eine frage wie läuft das ganze denn jetz bei ssl z.b. bei pyload ab, was für schlüssel werden denn da verwendet?????
Ist es auch da möglich ECDSA zu verweden, läuft das mit firefox????
 
Zuletzt bearbeitet:
Die Einstellung bei OpenSSH, die für die Build-Option "--without-openssl" verantwortlich ist, hat keinen Einfluß auf die OpenSSL-Bibliothek (nur auf deren (Nicht-)Verwendung durch OpenSSH).

Das bleibt also ohnehin wie es ist .. beim Python ist wohl inzwischen das Problem bei der Übersetzung mit OpenSSL 1.0.2h gelöst, aber wenn da tatsächlich transmission auf die Box soll, wird wohl weiterhin RC4 benötigt (das hat @er13 festgestellt, wenn ich es richtig verstanden habe), weil der Client da nichts anderes kann (shame on it).

Da mußt Du also die Verwendung von RC4 (ein praktisch "abgeschaffter" Verschlüsselungsalgorithmus, siehe die Kommentare im CS 13798 zu "...WITH_RC4" in der Config.in) ohnehin dazuschalten, wenn das nicht automatisch erfolgt.

Ist RC4 enthalten in der libcrypto.so/libssl.so, kann man auch nur durch geeignete Konfigurationen verhindern, daß da eventuell doch ein Fallback auf RC4 von irgendjemandem erzwungen wird ... einige der SSL-Lücken in den letzten 3 Jahren basierten genau auf solchen "downgrade"-Angriffen auf die verwendete Verschlüsselung und wer weiß schon, wo die nächste Lücke lauert. Ein nicht vorhandener RC4-Algorithmus kann beim Downgrade auch nicht aktiviert werden.
 

Neueste Beiträge

Statistik des Forums

Themen
244,695
Beiträge
2,216,690
Mitglieder
371,314
Neuestes Mitglied
Gjorstn
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.