WardtermSSH-Client
DE
Herunterladen

"sign_and_send_pubkey: no mutual signature supported": Fehler beheben

Ihr SSH-Client und der Server haben für diesen Schlüssel keinen gemeinsamen Signaturalgorithmus. Fast immer heißt das: ein RSA-Schlüssel und ein alter Server, der nur SHA-1-Signaturen (ssh-rsa) kennt, die OpenSSH-Clients seit 8.8 standardmäßig ablehnen. Der Schlüssel selbst ist in Ordnung. Nutzen Sie auf diesem Server einen Ed25519-Schlüssel, falls er einen unterstützt, aktualisieren Sie den Server, oder erlauben Sie ssh-rsa nur für diesen einen Host mit PubkeyAcceptedAlgorithms +ssh-rsa.

SHA-1 endgültig hinter sich lassen? Wardterm erzeugt einen Ed25519-Schlüssel und legt ihn für Sie auf dem Server ab. Zeigen

Aktualisiert am . Nachgestellt mit OpenSSH 10.3 auf macOS und OpenSSH 10.0 auf Debian 13 als Clients gegen einen echten OpenSSH-6.6-Server auf Ubuntu 14.04, mit einem Wegwerf-Schlüssel.

Was Sie sehen

sign_and_send_pubkey: no mutual signature supported
user@server: Permission denied (publickey,password).

Oft ist nur die zweite Zeile sichtbar. In unseren Tests erschien die erste Zeile bei einer RSA-Schlüsseldatei im älteren Format ohne .pub-Datei daneben. Mit einer .pub-Datei blieb derselbe Fehler stumm, und nur ssh -v zeigte den Grund:

debug1: send_pubkey_test: no mutual signature algorithm

Das Anlegen der .pub-Datei lässt die erste Zeile verschwinden, behebt aber die Anmeldung nicht.

Warum es passiert

Der Name ssh-rsa steht für zwei Dinge: einen Schlüsseltyp und eine Signatur mit SHA-1. Ein RSA-Schlüssel kann auch mit SHA-256 oder SHA-512 signieren, bekannt als rsa-sha2-256 und rsa-sha2-512. OpenSSH unterstützt diese seit 7.2. OpenSSH 8.8 hat aufgehört, die SHA-1-Signatur standardmäßig anzubieten, weil SHA-1 gebrochen ist.

Ein Server vor 7.2 oder ein Gerät mit einer alten SSH-Bibliothek kann also nur die Signatur akzeptieren, die Ihr Client nicht mehr erzeugt. Ein moderner Server ist nicht betroffen, und Sie müssen wegen dieses Problems keinen RSA-Schlüssel ersetzen: Derselbe Schlüssel meldete sich in unseren Tests an einem modernen Server problemlos an.

Bestätigen

ssh -v user@server true 2>&1 | grep -E 'remote software version|mutual|server-sig-algs'

Ein Treffer sieht so aus. Eine alte Serverversion und keine Zeile mit server-sig-algs:

debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.13
debug1: send_pubkey_test: no mutual signature algorithm

Zur Bestätigung probieren Sie es für eine Verbindung aus:

ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa user@server

Klappt die Anmeldung damit, ist das die Ursache. Clients vor OpenSSH 8.5 nennen diese Option PubkeyAcceptedKeyTypes.

Lösung 1: einen Ed25519-Schlüssel verwenden

Das ist die beste Lösung, wenn der Server es unterstützt, also ab OpenSSH 6.5. Gegen den 6.6-Server in unserem Test funktionierte es ohne Sonderoptionen und braucht kein SHA-1.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_oldserver
ssh-copy-id -o PubkeyAcceptedAlgorithms=+ssh-rsa -i ~/.ssh/id_ed25519_oldserver.pub user@server

Siehe So erzeugen Sie einen ed25519-Schlüssel. ECDSA funktioniert ebenfalls, wo Ed25519 nicht verfügbar ist. Einen Vergleich der beiden Schlüsseltypen finden Sie unter RSA oder Ed25519.

Lösung 2: ssh-rsa für genau diesen Host erlauben

Nutzen Sie das für ein Gerät, das Sie nicht ändern können, etwa altes Netzwerkgerät. Beschränken Sie es in ~/.ssh/config auf den einen Host, statt es unter Host * einzutragen:

Host old-box
  HostName 203.0.113.10
  User user
  IdentityFile ~/.ssh/id_rsa
  IdentitiesOnly yes
  PubkeyAcceptedAlgorithms +ssh-rsa

OpenSSH beschreibt das als Notlösung, bis das alte System aktualisiert werden kann. Hat das Gerät nur einen RSA-Host-Schlüssel, erhalten Sie einen anderen Fehler zum Host-Schlüsseltyp. Fügen Sie HostKeyAlgorithms +ssh-rsa demselben Block hinzu und lesen Sie no matching key exchange zu dieser Fehlerfamilie.

Lösung 3: den Server aktualisieren

Ein Server ab OpenSSH 7.2 signiert automatisch mit SHA-2, und die Meldung verschwindet. Einem so alten Server fehlen außerdem Jahre an Sicherheitskorrekturen.

Wenn es auf Red-Hat-Systemen weiterhin scheitert

Auf RHEL 9 und Verwandten schränkt die Crypto-Policy des Systems SHA-1-Signaturen standardmäßig zusätzlich zur OpenSSH-Einstellung ein:

update-crypto-policies --show

Müssen Sie den alten Server von dieser Maschine aus erreichen, erlauben Sie SHA-1-Signaturen wieder mit der Subpolicy SHA1 und starten Sie neu:

sudo update-crypto-policies --set DEFAULT:SHA1

Das betrifft die ganze Maschine und jedes Programm darauf, bevorzugen Sie also Lösung 1, wo es geht.

Der umgekehrte Fall

Ein alter Client gegen einen neuen Server scheitert andersherum: Der Client bietet ssh-rsa an und der Server lehnt es ab. Der Client sieht nur Permission denied (publickey). Aktualisieren Sie den Client oder nutzen Sie einen Ed25519-Schlüssel.

Fragen

Muss ich meinen RSA-Schlüssel ersetzen?

Nein. Derselbe RSA-Schlüssel signiert auf jedem Server mit OpenSSH 7.2 oder neuer mit rsa-sha2-256 oder rsa-sha2-512. Der Fehler kommt von alten Servern, die nur SHA-1-Signaturen annehmen.

Ist PubkeyAcceptedAlgorithms +ssh-rsa sicher?

Es erlaubt SHA-1-Signaturen nur für diesen Host. Halten Sie es als Notlösung im eigenen Host-Block dieses Hosts und wechseln Sie zu einem Ed25519-Schlüssel oder einem neueren Server.

Was ist der Unterschied zwischen ssh-rsa und rsa-sha2-256?

Beide nutzen denselben RSA-Schlüssel. ssh-rsa signiert mit SHA-1, das OpenSSH seit 8.8 standardmäßig nicht mehr anbietet, rsa-sha2-256 und rsa-sha2-512 signieren mit SHA-2.

Quellen

Mehr zu Fehlermeldungen

Alle Anleitungen