SSH "no matching key exchange method found" oder "no matching host key type found": Fehler beheben

Der Server bietet nur alte Algorithmen an, die Ihr OpenSSH-Client standardmäßig nicht mehr aktiviert. Um genau diesen Host zu erreichen, fügen Sie den Algorithmus aus Their offer mit einem + in dessen Host-Block ein, zum Beispiel KexAlgorithms +diffie-hellman-group14-sha1. Das schwächt nur diese eine Verbindung. Die eigentliche Lösung ist, das Gerät oder seine SSH-Einstellungen zu aktualisieren.

Unklar, welche Geräte betroffen sind? Wardterm prüft die Sicherheit aller Server Ihrer Liste auf einmal. Zeigen

Aktualisiert am . Jeder Fehler und jede +-Option wurde mit OpenSSH 10.3 auf macOS gegen einen Wegwerf-OpenSSH-10.0-Server auf Debian 13 nachgestellt, der nur den alten Algorithmus anbot.

Die Meldungen

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,ext-info-s,kex-strict-s-v00@openssh.com
Unable to negotiate with 203.0.113.10 port 22: no matching host key type found. Their offer: ssh-rsa
Unable to negotiate with 203.0.113.10 port 22: no matching cipher found. Their offer: aes128-cbc
Unable to negotiate with 203.0.113.10 port 22: no matching MAC found. Their offer: hmac-md5

Vor der Anmeldung müssen sich Client und Server auf eine Liste von Algorithmen einigen. Diese Meldung heißt, dass sie nichts gemeinsam haben, und Their offer verrät, was der Server kann. OpenSSH enthält noch viele alte Algorithmen, nutzt sie aber nicht, solange Sie nicht danach fragen. Das passiert oft bei altem Netzwerkgerät, Druckern, Speicherboxen und alten Linux-Systemen, häufig direkt nach einem Update Ihres Clients.

Namen wie ext-info-s und kex-strict-s-v00@openssh.com im Angebot sind Protokollmarker, keine Algorithmen, die Sie auswählen können. Ignorieren Sie sie.

Für einen Host erlauben

Jede Meldung gehört zu einer Option:

MeldungOption
no matching key exchange method foundKexAlgorithms
no matching host key type foundHostKeyAlgorithms
no matching cipher foundCiphers
no matching MAC foundMACs

Probieren Sie es einmal auf der Kommandozeile und kopieren Sie den Namen aus dem Angebot:

ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 user@203.0.113.10

Ein altes Gerät braucht oft mehrere, und sie tauchen einzeln nacheinander auf, weil der Client bei der ersten Abweichung stoppt. Tragen Sie jede in ~/.ssh/config ein:

Host old-switch
    HostName 203.0.113.10
    User user
    KexAlgorithms +diffie-hellman-group14-sha1
    HostKeyAlgorithms +ssh-rsa
    Ciphers +aes128-cbc

Behalten Sie das +. Es ergänzt die Standardliste, sodass die modernen Algorithmen vorn bleiben und genutzt werden, sobald das Gerät sie unterstützt. Ohne es ersetzen Sie die ganze Liste.

Halten Sie das in einem benannten Host-Block und nie unter Host *, das würde die Anforderungen für jeden Server senken. Außerdem nutzt ssh für jede Option den ersten gefundenen Wert, setzen Sie diesen Block also über jeden allgemeinen Block, der dieselbe Option setzt.

Ihr RSA-Schlüssel wird ohne Erklärung abgelehnt

Versteht ein alter Server für Benutzerschlüssel nur ssh-rsa-Signaturen, sagt der Client einfach Permission denied (publickey), ohne Hinweis auf Algorithmen. Das hatten wir mit einem Server, der auf ssh-rsa beschränkt war. Diese Zeile für den Host hat es behoben:

PubkeyAcceptedAlgorithms +ssh-rsa

Für ssh-dss gibt es keine Umgehung

OpenSSH 10.0 hat DSA komplett entfernt. Einem Client ab Version 10 lässt sich nicht sagen, dass er es nutzen soll:

command-line line 0: Bad key types '+ssh-dss'.

Bietet ein Gerät nur ssh-dss an, aktualisieren Sie das Gerät. Bis dahin führt nur ein älterer Client hinein, zum Beispiel in einer virtuellen Maschine in einem vertrauenswürdigen Netz.

Sehen, was jede Seite unterstützt

Was Ihr Client überhaupt kann, einschließlich dessen, was er standardmäßig nicht aktiviert:

ssh -Q kex
ssh -Q HostKeyAlgorithms
ssh -Q cipher
ssh -Q mac

Was Ihr Client diesem Host tatsächlich anbieten würde:

ssh -G server | grep -E '^(kexalgorithms|hostkeyalgorithms|ciphers|macs) '

Alles, was der Server anbietet, auf einmal statt als ein Fehler nach dem anderen:

ssh -vv user@server 2>&1 | grep -A9 'peer server KEXINIT'

Was Sie in Kauf nehmen

Diese Algorithmen sind aus gutem Grund deaktiviert. Die Schwäche betrifft nur diese Verbindung:

  • diffie-hellman-group1-sha1 nutzt eine 1024-Bit-Gruppe und SHA-1.
  • ssh-rsa signiert mit SHA-1. OpenSSH hat es in Version 8.8 standardmäßig deaktiviert. Der RSA-Schlüssel selbst ist nicht das Problem: Ein moderner Server nutzt denselben Schlüssel mit rsa-sha2-256 oder rsa-sha2-512. Zum selben Problem bei Benutzerschlüsseln siehe no mutual signature supported.
  • CBC-Cipher und hmac-md5 sind alte Konstruktionen, die neuere Modi ersetzt haben.

Betrachten Sie es als vorläufig und halten Sie ein solches Gerät in einem Verwaltungsnetz und fern vom offenen Internet.

Die eigentliche Lösung am Gerät

  1. Aktualisieren. Firmware-Updates bringen oft moderne Algorithmen. Sehen Sie in der Dokumentation des Herstellers zu SSH oder zur Absicherung der Verwaltung nach.
  2. Einstellungen prüfen. Viele Geräte unterstützen bessere Algorithmen, die nur ausgeschaltet sind. Auf einem Linux-Server zeigt dies, was aktiv ist:
    sudo sshd -T | grep -iE '^(kexalgorithms|hostkeyalgorithms|ciphers|macs) '
    Entfernen Sie alte Zeilen mit KexAlgorithms, HostKeyAlgorithms, Ciphers oder MACs aus /etc/ssh/sshd_config und dem zugehörigen Include-Ordner, um zu den Standardwerten zurückzukehren.
  3. Einen modernen Host-Schlüssel erzeugen, falls der Server keinen hat:
    sudo ssh-keygen -t ed25519 -N '' -f /etc/ssh/ssh_host_ed25519_key
    sudo systemctl restart sshd
    Die Unit heißt auf Debian und Ubuntu ssh. Clients zeigen dann möglicherweise eine Warnung wegen eines geänderten Host-Schlüssels, planen Sie das also ein.
  4. Die Umgehung aus Ihrer Konfiguration entfernen und erneut verbinden, um es zu bestätigen.

Eine verwandte Warnung, kein Fehler

Seit OpenSSH 10.1 gibt eine Verbindung, die funktioniert, aber einen älteren Schlüsselaustausch nutzt, Folgendes aus:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html

Die Sitzung kommt zustande, die Lösung liegt auf dem Server. Was die Warnung bedeutet und wie Sie sie beheben oder abschalten: die Warnung zum Post-Quanten-Schlüsselaustausch.

Fragen

Ist es sicher, diffie-hellman-group14-sha1 zu aktivieren?

Nur als Notlösung für ein altes Gerät in einem vertrauenswürdigen Netz. Es beruht auf SHA-1, also halten Sie es im eigenen Host-Block dieses Hosts und nie unter Host *.

Warum tritt das nach einem Update auf?

Neuere OpenSSH-Clients bieten alte Algorithmen standardmäßig nicht mehr an. Der Server hat sich nicht geändert: Ihr Client akzeptiert nicht mehr, was er anbietet.

Was bedeutet das + vor einem Algorithmus?

Es fügt den Algorithmus der Standardliste hinzu, statt sie zu ersetzen. Moderne Algorithmen bleiben vorn und werden genutzt, sobald das Gerät sie kann.

Quellen

Mehr zu Fehlermeldungen

Alle Anleitungen