Comment résoudre l’erreur de connexion SSH « no matching host key type found » sur des vieux systèmes

SSH (Secure Shell) est un protocole qui permet d’établir des connexions sécurisées entre des machines distantes, par exemple un client et un serveur. Pour authentifier les machines et chiffrer les données échangées, SSH utilise des clés cryptographiques, qui sont des paires de clés composées d’une clé publique et d’une clé privée. Il existe plusieurs types de clés SSH, basés sur des algorithmes différents, tels que RSA, DSA, ECDSA ou EdDSA.

Dans cet article, nous allons vous expliquer comment résoudre le problème de connexion SSH « no matching host key type found », qui se produit lorsque le client et le serveur SSH ne supportent pas les mêmes types de clés SSH. Ce problème peut arriver lorsque le client ou le serveur utilise une version obsolète d’OpenSSH, qui ne reconnaît pas certains types de clés SSH. 

Aussi, Nous vous montrons comment identifier le type de clé SSH utilisé par le serveur, et comment le spécifier dans la commande ou la configuration du client. On va également vous donner quelques conseils pour mettre à jour le client et le serveur SSH, afin qu’ils supportent les types de clés SSH les plus récents et les plus sécurisés.

Qu’est-ce qu’une clé SSH ?

Une clé SSH est une paire de clés, composée d’une clé publique et d’une clé privée. La clé publique est stockée et/ou distribuée aux clients SSH, tandis que la clé privée est conservée sur le serveur SSH. Cette clé publique peut être utilisée pour chiffrer un message, mais seule la clé privée correspondante peut le déchiffrer. C’est ce qu’on appelle le chiffrement asymétrique.

Comment fonctionne l’authentification par clés SSH ?

Lorsqu’un client SSH souhaite se connecter à un serveur SSH, il doit d’abord établir une connexion sécurisée avec le serveur. Pour cela, les deux machines doivent négocier une clé symétrique de session, qui servira à chiffrer les données échangées. Cette négociation se fait par l’échange de Diffie-Hellman (Du nom de ses auteurs Whitfield Diffie et Martin Hellman), qui permet de créer une clé secrète partagée à partir de la clé privée d’une machine et de la clé publique de l’autre. Ces clés sont différentes des clés SSH utilisées pour l’authentification.

Une fois la connexion sécurisée établie, le client doit s’authentifier auprès du serveur. Dans la plupart des cas, le client utilise l’authentification par clés publiques. Cette méthode consiste à envoyer au serveur sa clé publique, ainsi qu’un message signé avec sa clé privée. Le serveur vérifie alors que la signature correspond à la clé publique envoyée, et que cette clé publique est autorisée à accéder au serveur.

Quels sont les types de clés SSH ?

Les types de clés SSH les plus couramment utilisés sont les suivants :

• RSA : c’est l’un des algorithmes les plus anciens et les plus répandus pour générer des clés SSH. Il repose sur la difficulté de factoriser de grands nombres premiers. Il offre un bon niveau de sécurité, mais il nécessite des tailles de clés importantes (au moins 2048 bits) pour résister aux attaques actuelles.
• DSA : c’est un algorithme basé sur le problème du logarithme discret. Il a été conçu pour être compatible avec le standard américain DSS (Digital Signature Standard). Il a longtemps été limité à des tailles de clés de 1024 bits, ce qui le rendait vulnérable aux attaques. Il a été abandonné par OpenSSH depuis la version 7.0.
• ECDSA (Elliptic Curve Digital Signature Algorithm ) : c’est un algorithme basé sur la cryptographie à courbes elliptiques. Il permet de générer des clés SSH plus courtes (256, 384 ou 521 bits) tout en offrant un niveau de sécurité équivalent ou supérieur aux autres algorithmes. Il est plus rapide et plus efficace que RSA ou DSA, mais il nécessite une implémentation correcte des courbes utilisées.
• EdDSA : c’est un algorithme basé sur la variante Edwards des courbes elliptiques. Il utilise une courbe spécifique, nommée Ed25519, qui offre une haute performance et une haute sécurité. Il est considéré comme l’un des meilleurs algorithmes actuels pour générer des clés SSH.

Comment résoudre l’erreur « no matching host key type found » ?

Maintenant qu’on a un peu parlé du SSH, ses clés et son fonctionnement, revenons-nous à nos moutons afin de vous expliquer comment résoudre l’erreur « no matching host key type found ».

Lors d’une connexion sur des vieux systèmes en SSH, il est possible des fois que le terminal vous retourne l’erreur suivante : 

techcroute@debian:~$ ssh [email protected] 
Unable to negotiate with 192.168.11.10 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

Cette erreur « no matching host key type found » se produit lorsque le client et le serveur SSH ne supportent pas les mêmes types de clés SSH. Cela peut arriver lorsque le client ou le serveur utilise une version obsolète d’OpenSSH, qui ne reconnaît pas certains nouveaux types de clés SSH.

Pour résoudre ce problème, il faut identifier tout d’abord le type de clé SSH utilisé par le serveur, et le spécifier dans la commande SSH du client lors de la connexion. 

Comment identifier le type de clé SSH utilisé par le serveur

Pour identifier le type de clé SSH utilisé par le serveur, vous pouvez utiliser la commande ssh-keyscan, qui permet de scanner les clés publiques des serveurs SSH. Par exemple, pour scanner le serveur 192.168.11.10, vous pouvez utiliser la commande suivante :

techcroute@debian:~$ ssh-keyscan 192.168.11.10

Cette commande affiche les clés publiques du serveur, avec le type de clé entre crochets. Par exemple, si le serveur utilise une clé RSA, vous verrez quelque chose comme ceci :

192.168.11.10 [RSA] SHA256:7h3auMUOWm95yKFv/S2NQU0O9jyk4JHQ02giiAJTsI0

Comment spécifier le type de clé SSH dans la commande ou la configuration du client

Par exemple, si le serveur utilise une clé SSH de type RSA, il faut donc ajouter l’option -oHostKeyAlgorithms=+ssh-rsa à la commande SSH du client. pour cela il faut taper la commande suivant dans le terminal :

techcroute@debian:~$ ssh [email protected] -oHostKeyAlgorithms=+ssh-rsaEt 

Le terminal va vous retourner le message prompt suivant :

techcroute@debian:~$ ssh [email protected] -oHostKeyAlgorithms=+ssh-rsa

The authenticity of host '192.168.11.10 (192.168.11.10)' can't be established. RSA key fingerprint is SHA256:7h3auMUOWm95yKFv/S2NQU0O9jyk4JHQ02giiAJTsI0.
This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.11.10' (RSA) to the list of known hosts.
[email protected]'s password:

Cette option permet d’ajouter le type de clé RSA à la liste des types de clés acceptés par le client. Il est également possible de configurer cette option dans le fichier ~/.ssh/config du client, en utilisant le nom d’hôte pour le serveur concerné : 

Important ! Cette solution d’aujourd’hui pour régler ce problème de connexion au serveur SSH, n’est pas recommandée sur le long terme, car elle réduit la sécurité de la connexion. En effet, le type de clé RSA est considéré comme moins sûr que les types de clés ECDSA ou EdDSA, et il pourrait être compromis par des attaques futures.

La meilleure solution est donc de mettre à jour le client et le serveur SSH, afin qu’ils supportent les types de clés SSH les plus récents et les plus sécurisés. Il faut également générer de nouvelles clés SSH pour le serveur et les clients, en utilisant un algorithme comme ECDSA ou EdDSA.

Conclusion

SSH est un protocole essentiel pour établir des connexions sécurisées entre des machines distantes. Il utilise des clés cryptographiques pour authentifier les machines et chiffrer les données échangées. Il existe plusieurs types de clés SSH, basés sur des algorithmes différents, tels que RSA, DSA, ECDSA ou EdDSA.

Lorsqu’un client et un serveur SSH ne supportent pas les mêmes types de clés SSH, il peut se produire une erreur “no matching host key type found”. Pour la résoudre, il faut spécifier le type de clé SSH utilisé par le serveur dans la commande ou la configuration du client. Toutefois, cette solution n’est pas optimale, car elle peut réduire la sécurité de la connexion.

La meilleure solution est de mettre à jour le client et le serveur SSH, afin qu’ils supportent les types de clés SSH les plus récents et les plus sécurisés. Il faut également générer de nouvelles clés SSH pour le serveur et les clients, en utilisant un algorithme comme ECDSA ou EdDSA.