// SSH-Fehler · Cisco, Switches & Router
„no matching key exchange method found“ – SSH zu alten Geräten
Du willst dich per SSH mit einem älteren Switch, Router oder NAS verbinden und bekommst diese Meldung? Hier steht, was sie bedeutet und wie du sie behebst: mit OpenSSH, mit PuTTY oder mit einem einzigen Haken in Termax.
Gilt für Cisco IOS, ältere HP/Aruba-, Juniper- und Netgear-Switches, NAS und viele eingebettete Geräte
// Die Ursache
Was die Meldung bedeutet
So sieht der Fehler in OpenSSH aus (Linux, macOS und das in Windows eingebaute ssh):
Unable to negotiate with 10.0.0.2 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
Zu Beginn jeder SSH-Verbindung einigen sich Client und Gerät auf ein Verfahren für den Schlüsselaustausch (key exchange, kurz „kex“). Hinter Their offer steht, was das Gerät kann. Ältere Firmware beherrscht nur Verfahren auf Basis von SHA-1. Moderne SSH-Clients bieten diese seit Jahren nicht mehr an, weil SHA-1 und die kleine 1024-Bit-Gruppe (group1) als geschwächt gelten. OpenSSH hat diffie-hellman-group1-sha1 schon 2015 mit Version 7.0 standardmäßig abgeschaltet, ssh-rsa-Signaturen 2021 mit Version 8.8. Finden beide Seiten kein gemeinsames Verfahren, bricht die Verbindung sofort ab – noch bevor nach Benutzername oder Passwort gefragt wird.
Deshalb tritt der Fehler oft „plötzlich“ auf: Das Gerät hat sich nicht verändert, aber dein SSH-Client wurde aktualisiert.
// Verwandte Meldungen
Dieselbe Ursache, andere Fehlermeldung
Je nachdem, woran es zuerst scheitert, meldet OpenSSH den Fehler unterschiedlich. Die rechte Spalte zeigt, welche Einstellung jeweils hilft.
| Meldung (OpenSSH) | Was fehlt | Einstellung in OpenSSH |
|---|---|---|
no matching key exchange method found. Their offer: diffie-hellman-group1-sha1 | alter Schlüsselaustausch | KexAlgorithms +diffie-hellman-group1-sha1 |
no matching host key type found. Their offer: ssh-rsa | alte Signatur des Geräteschlüssels | HostKeyAlgorithms +ssh-rsa |
no matching cipher found. Their offer: aes128-cbc,3des-cbc | alte Verschlüsselung (CBC) | Ciphers +aes128-cbc |
no matching MAC found. Their offer: hmac-md5 | alte Prüfsumme | MACs +hmac-md5 |
Übernimm jeweils genau das Verfahren, das hinter Their offer steht. In Termax deckt ein einziger Schalter alle vier Fälle ab.
// Lösung 1 · Termax
Ein Haken pro Verbindung
Seit 0.7.1 kann Termax ältere Geräte anbinden – unter Windows, Android und im Browser.
- Termax öffnen und die Verbindung zum Gerät anlegen (Neue Verbindung) oder eine bestehende über ⋯ → Bearbeiten öffnen.
- Veraltete Verfahren erlauben (ältere Geräte) anhaken und Speichern.
- Verbinden. Termax bietet jetzt zusätzlich SHA-1-Schlüsselaustausch, CBC-Verschlüsselung, SHA-1/MD5-Prüfsummen und
ssh-rsa/ssh-dssan.
Die Option gilt nur für die Verbindung, bei der du sie einschaltest. Die sicheren Verfahren stehen immer zuerst in der Liste, ein Gerät, das Moderneres kann, nutzt also weiterhin das. Scheitert eine Verbindung an veralteten Verfahren, weist Termax direkt auf den Schalter hin. Und hast du in deiner ~/.ssh/config bereits Zeilen wie KexAlgorithms +diffie-hellman-group1-sha1, setzt der Import die Option automatisch.
Termax kostenlos herunterladen – für Windows und Android, ohne Konto.
// Lösung 2 · OpenSSH
Im Terminal: einmalig oder dauerhaft
Einmalig für eine Verbindung
Das Pluszeichen ist wichtig: Es ergänzt das alte Verfahren. Ohne + ersetzt du die komplette Liste und schaltest die sicheren Verfahren ab.
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 admin@10.0.0.2
# falls danach Host-Key oder Cipher gemeldet werden:
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 \
-oHostKeyAlgorithms=+ssh-rsa \
-oCiphers=+aes128-cbc \
admin@10.0.0.2
Dauerhaft nur für dieses Gerät
In der Datei ~/.ssh/config (unter Windows C:\Users\<Name>\.ssh\config) gilt die Einstellung nur für den genannten Host – alle anderen Verbindungen bleiben streng:
Host core-switch
HostName 10.0.0.2
User admin
KexAlgorithms +diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
HostKeyAlgorithms +ssh-rsa
Ciphers +aes128-cbc
Meldest du dich mit einem RSA-Schlüssel an, braucht OpenSSH ab Version 8.5 zusätzlich PubkeyAcceptedAlgorithms +ssh-rsa (in älteren Versionen heißt die Option PubkeyAcceptedKeyTypes).
PuTTY
PuTTY beherrscht die alten Verfahren noch, stuft sie aber als unsicher ein und fragt vor der Verbindung mit einer Warnung nach. Die Reihenfolge lässt sich unter Connection → SSH → Kex anpassen.
// Lösung 3 · Am Gerät
Die sicherste Lösung: das Gerät modernisieren
Neuere IOS- bzw. IOS-XE-Versionen und aktuelle Firmware anderer Hersteller beherrschen moderne Verfahren wie diffie-hellman-group14-sha256 oder ecdh-sha2-nistp256. Oft reicht ein Firmware-Update, bei Cisco zusätzlich ein neuer RSA-Schlüssel mit mindestens 2048 Bit. Dann braucht der Client keine Ausnahme mehr. Für Geräte, die keine Updates mehr bekommen, bleibt die Ausnahme auf Client-Seite der praktikable Weg.
Spricht ein Gerät gar kein SSH oder erreichst du es nur noch über den Console-Port, hilft Termax ebenfalls: mit Telnet in der Windows- und der Android-App und mit der seriellen Konsole (COM, Vorgabe 9600 8N1) unter Windows, auf Android per USB-OTG-Adapter und im Browser mit Chrome oder Edge. Telnet ist unverschlüsselt und gehört nur ins eigene Netz.
// Offen gesagt
Wie unsicher ist das?
Die Verbindung bleibt verschlüsselt und der Schlüssel des Geräts wird weiterhin geprüft. Die alten Verfahren sind aber schwächer: Die 1024-Bit-Gruppe gilt für Angreifer mit sehr großen Rechenkapazitäten als angreifbar, SHA-1 und CBC haben bekannte theoretische Schwächen. Für ein Gerät im eigenen, vertrauenswürdigen Netz ist das in der Praxis vertretbar – über das offene Internet solltest du solche Geräte nicht verwalten. Wichtig ist, die Ausnahme nur für das betroffene Gerät zu setzen, nie global.
// FAQ