WardtermClient SSH
FR
Télécharger

"sign_and_send_pubkey: no mutual signature supported" : comment résoudre l'erreur

Votre client SSH et le serveur n'ont aucun algorithme de signature en commun pour cette clé. Cela désigne presque toujours une clé RSA et un vieux serveur qui ne connaît que les signatures SHA-1 (ssh-rsa), que les clients OpenSSH refusent par défaut depuis la version 8.8. La clé elle-même est correcte. Utilisez une clé Ed25519 sur ce serveur s'il en accepte une, mettez le serveur à jour, ou autorisez ssh-rsa pour cet hôte uniquement avec PubkeyAcceptedAlgorithms +ssh-rsa.

Mis à jour le . Reproduit avec OpenSSH 10.3 sur macOS et OpenSSH 10.0 sur Debian 13 comme clients, face à un vrai serveur OpenSSH 6.6 sous Ubuntu 14.04, avec une clé jetable.

Ce que vous voyez

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

Souvent, seule la deuxième ligne est visible. Dans nos tests, la première ligne apparaissait pour un fichier de clé RSA au format ancien sans fichier .pub à côté. Avec un fichier .pub, le même échec était silencieux, et seul ssh -v montrait la raison :

debug1: send_pubkey_test: no mutual signature algorithm

Créer le fichier .pub supprime la première ligne mais ne règle pas la connexion.

Pourquoi cela arrive

Le nom ssh-rsa désigne deux choses : un type de clé et une signature utilisant SHA-1. Une clé RSA peut aussi signer avec SHA-256 ou SHA-512, sous les noms rsa-sha2-256 et rsa-sha2-512. OpenSSH les prend en charge depuis la version 7.2. OpenSSH 8.8 a cessé de proposer par défaut la signature SHA-1, car SHA-1 est cassé.

Un serveur antérieur à la 7.2, ou un équipement avec une vieille bibliothèque SSH, peut donc n'accepter que la signature que votre client ne produit plus. Un serveur moderne n'est pas concerné, et vous n'avez pas besoin de remplacer une clé RSA pour cette raison : la même clé fonctionnait très bien sur un serveur moderne dans nos tests.

Le confirmer

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

Un cas correspondant ressemble à ceci. Une vieille version de serveur et aucune ligne 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

Pour confirmer, essayez pour une seule connexion :

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

Si la connexion réussit, c'est la cause. Les clients antérieurs à OpenSSH 8.5 appellent cette option PubkeyAcceptedKeyTypes.

Solution 1 : utiliser une clé Ed25519

C'est la meilleure solution si le serveur la prend en charge, c'est-à-dire à partir d'OpenSSH 6.5. Elle a fonctionné face au serveur 6.6 de notre test sans option particulière, et n'a pas besoin de 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

Voir comment générer une clé ed25519. ECDSA fonctionne aussi là où Ed25519 n'est pas disponible. Pour comparer les deux types de clés, voir RSA ou Ed25519.

Solution 2 : autoriser ssh-rsa pour cet hôte uniquement

Utilisez-la pour un appareil que vous ne pouvez pas modifier, comme un vieil équipement réseau. Limitez-la à cet hôte dans ~/.ssh/config au lieu de l'ajouter sous Host * :

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

OpenSSH décrit cela comme un palliatif en attendant de pouvoir mettre à jour l'ancien système. Si l'appareil n'a qu'une clé d'hôte RSA, vous obtenez une autre erreur, sur le type de clé d'hôte. Ajoutez HostKeyAlgorithms +ssh-rsa au même bloc, et voyez no matching key exchange pour cette famille d'erreurs.

Solution 3 : mettre le serveur à jour

Un serveur sous OpenSSH 7.2 ou plus récent signe automatiquement avec SHA-2 et le message disparaît. Un serveur aussi ancien a aussi des années de correctifs de sécurité en retard.

Si cela échoue encore sur les systèmes de type Red Hat

Sur RHEL 9 et ses dérivés, la politique cryptographique du système restreint par défaut les signatures SHA-1, en plus du réglage d'OpenSSH :

update-crypto-policies --show

Si vous devez joindre l'ancien serveur depuis cette machine, réactivez les signatures SHA-1 avec la sous-politique SHA1, puis redémarrez :

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

Cela touche toute la machine et chaque programme : préférez donc la solution 1 quand c'est possible.

Le cas inverse

Un vieux client face à un serveur récent échoue dans l'autre sens : le client propose ssh-rsa et le serveur le refuse. Le client voit simplement Permission denied (publickey). Mettez le client à jour ou utilisez une clé Ed25519.

Questions

Faut-il remplacer ma clé RSA ?

Non. La même clé RSA signe avec rsa-sha2-256 ou rsa-sha2-512 sur tout serveur avec OpenSSH 7.2 ou plus récent. L'erreur vient des anciens serveurs qui n'acceptent que les signatures SHA-1.

PubkeyAcceptedAlgorithms +ssh-rsa est-il sûr ?

Il autorise les signatures SHA-1 pour cet hôte seulement. Gardez-le dans le bloc Host de cet hôte comme solution provisoire, et passez à une clé Ed25519 ou à un serveur plus récent.

Quelle différence entre ssh-rsa et rsa-sha2-256 ?

Les deux utilisent la même clé RSA. ssh-rsa signe avec SHA-1, qu'OpenSSH ne propose plus par défaut depuis la 8.8, tandis que rsa-sha2-256 et rsa-sha2-512 signent avec SHA-2.

Sources

Autres guides : Messages d'erreur

Tous les guides