quantum-resistant key exchange

Hinweis: In dem Thema quantum-resistant key exchange gibt es 7 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.

    Hallo Zäma,


    wie oft bei LINUX; wird ein update in einer Applikation eingespielt, funktioniert was nicht mehr.


    Update ipfire --> Zugriff über ssh funktioniert nicht mehr.


    Unable to negotiate with 1.2.2.4 port 22: no matching key exchange method found. Their offer:

    mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25

    519-sha256@libssh.org,ext-info-s,kex-strict-s-v00@openssh.com


    Dann sucht man lange im Internet bis man auf Infos stößt. die "Lösungen anbieten!!! Nicht wirklich.

    Okay ich habe jetzt herausgefunden, dass ich mit dem ssh-Client mit der folgenden Befehlszeile auf meine IPfire komme.


    ssh -oKexAlgorithms=+mlkem768x25519-sha256 blabla@firewall.mylocal.lan


    Wo kann ich die quantum-resistant key exchange permanent verorten?


    Hat jemand eine Idee?


    Zappa

    In Deiner config von ssh:

    Code
    ~/.ssh/config
    Code
    Host hostmitdem.veraltetenalgo
    KexAlgorithms +diffie-hellman-group1-sha1
    HostKeyAlgorithms +ssh-dss

    Für den Inhalt des Beitrages 324448 haftet ausdrücklich der jeweilige Autor: Kieltux

    Technisch gesehen sagt dir die Terminal-Ausgabe ganz genau, was das Problem ist, nämlich dass die Verschlüsselungstypen des Clients nicht die Anforderungen des Servers erfüllen. "Normalerweise" geschieht das Aushandeln automatisch, es sei denn es wird auf Client oder Serverseite -manuell- definiert. Deswegen wie in Post #2 die SSH Konfig des Clients prüfen, oder halt die Serverseite anpassen, so wie es für dich Sinn ergibt.

    PRAISE THE OMNISSIAH

    Für den Inhalt des Beitrages 324450 haftet ausdrücklich der jeweilige Autor: Scytale

    Hallo,


    nicht ganz

    [

    ssh/config line 16: Bad key types '+ssh-dss'.

    .ssh/config: terminating, 1 bad configuration options

    /tt]

    Ich hatte schon 

    [tt]

    Host firewall

    HostName firewall.myLAN.lan

    KexAlgorithms +mlkem768x25519-sha256


    ==>


    Unable to negotiate with 10.10.10.253 port 22: no matching key exchange method found. Their offer: mlk

    em768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25

    519-sha256@libssh.org,ext-info-s,kex-strict-s-v00@openssh.com

    OK, etwas an Transferleistung hatte ich schon erwartet. Das war mein Eintrag für ein älteres Debian... Du musst schon die Config für Dich anpassen.

    Have a lot of fun

    Für den Inhalt des Beitrages 324452 haftet ausdrücklich der jeweilige Autor: Kieltux

    Danke für den Tipp, aber das ist es ja was ich nachfragte. Darüber hinaus muss es doch eine Systemweite config geben, die das regelt - oder nicht?


    Grüße aus dem Südwesten der Republik

    Ich verstehe jetzt nicht, was du in der globalen SSH Config für ein Problem lösen willst, weil in #2 steht ja schon die Lösung.


    Speichere die Verbindungsoptionen für eine spezifische SSH Verbindung und fertig ist der Lack.

    PRAISE THE OMNISSIAH

    Für den Inhalt des Beitrages 324454 haftet ausdrücklich der jeweilige Autor: Scytale

    Hallo ,


    das ist ganz einfach. Wenn ich am System 10000 User habe, müssen die alle ihre eigene local .ssh/config editieren. So wie es globale/systemweite Konfigurationsdateien gibt z.B.

    /etc/bash.bashrc sollte es doch eine systemweite sshd konfig geben.


    Ich habe mal die Methode des scharfen hin sehend gewählt und unter /etc geschaut, was es da so an globalen setting Dateien gibt:

    So, und wenn mal die Datei:

    sudo vi /etc/crypto-policies/back-ends/openssh.config

    editiert und mlkem768x25519-sha256 hinzufügt,, das klappt das.

    KexAlgorithms  mlkem768x25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,d

    iffie-hellman-group18-sha512


    Okay - danke für euren Einsatz.