La communication SSH est sécurisée à l'aide de la cryptographie à clé publique. Lorsqu'un utilisateur se connecte au serveur SSH à l'aide du client SSH pour la première fois, le programme SSH stocke la clé publique du serveur SSH dans le répertoire personnel de l'utilisateur dans un fichier, known_hosts, dans un dossier caché nommé ~/.ssh/, comme indiqué dans la capture d'écran suivante :
Maintenant, par la suite, chaque fois que le client ssh se connecte au serveur, il compare la clé publique envoyée par le serveur à la clé publique du serveur stockée dans le fichier ~/.ssh/known_hosts. Si la clé publique ne correspond pas, le client suppose que le trafic réseau est piraté ou que le serveur auquel la connexion est établie n'est pas le même, et donc le client SSH interrompt la connexion, comme indiqué ici :
$ ssh [email protected] @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 3f:1b:f4:bd:c5:aa:c1:1f:bf:4e:2e:cf:53:fa:d8:59. Please contact your system administrator. Add correct host key in /home/admin/.ssh/known_hosts to get rid of this message. Offending key in /home/admin/.ssh/known_hosts:3 RSA host key for 192.168.12.12 has changed and you have requested strict checking. Host key verification failed.$
Il existe plusieurs raisons possibles pour lesquelles la clé de l'hôte distant a changé. Une attaque Man-in-the-Middle n'est qu'une des raisons possibles. D'autres raisons possibles incluent :
- OpenSSH a été réinstallé sur l'hôte distant mais, pour une raison quelconque, la clé d'origine de l'hôte n'a pas été restaurée.
- L'hôte distant a été remplacé légitimement par une autre machine.
Il est également possible que le serveur ait été reformaté ou que la clé du serveur ait été remplacée pour une raison légitime. Dans de telles circonstances, l'utilisateur doit mettre à jour ses fichiers ~/.ssh/known_hosts en supprimant les anciennes clés pour permettre la connexion au serveur.
Si vous êtes sûr que cela est inoffensif, vous pouvez utiliser l'une des 2 méthodes ci-dessous pour tromper openSSH et vous permettre de vous connecter. Mais sachez que vous êtes devenu vulnérable aux attaques de l'homme du milieu.
Méthode 1 - supprimer la clé de l'hôte du fichier ~/.ssh/known_hosts
La première méthode consiste à supprimer l'hôte distant du fichier ~/.ssh/known_hosts. Notez que le message d'avertissement vous indique déjà le numéro de ligne dans le fichier known_hosts qui correspond à l'hôte distant cible. La ligne incriminée dans l'exemple ci-dessus est la ligne 3 ("Offending key in /home/admin/.ssh/known_hosts:3")
Vous pouvez utiliser la ligne suivante pour supprimer cette ligne (ligne 3) du fichier.
$ sed -i 3d ~/.ssh/known_hosts
Notez qu'avec la méthode ci-dessus, vous serez invité à confirmer l'empreinte de la clé de l'hôte lorsque vous exécuterez ssh pour vous connecter.
Méthode 2 - Désactiver StrictHostKeyChecking
La deuxième méthode utilise deux paramètres openSSH :
- StrictHostKeyChecking
- UserKnownHostsFile
Cette méthode trompe SSH en le configurant pour utiliser un fichier Known_hosts vide, et NON pour vous demander de confirmer la clé d'identité de l'hôte distant.
$ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected] Warning: Permanently added '192.168.12.12' (RSA) to the list of known hosts. [email protected]'s password:
Le paramètre UserKnownHostsFile spécifie le fichier de base de données à utiliser pour stocker les clés d'hôte de l'utilisateur (la valeur par défaut est ~/.ssh/known_hosts). Le fichier /dev/null est un fichier de périphérique système spécial qui supprime tout ce qui y est écrit et, lorsqu'il est utilisé comme fichier d'entrée, renvoie immédiatement End Of File.
En configurant le fichier de périphérique nul en tant que base de données de clés d'hôte, SSH est trompé en pensant que le client SSH ne s'est jamais connecté à un serveur SSH auparavant et ne rencontrera donc jamais une clé d'hôte incompatible. Le paramètre StrictHostKeyChecking spécifie si SSH ajoutera automatiquement de nouvelles clés d'hôte au fichier de base de données de clés d'hôte. En le définissant sur non, la clé d'hôte est automatiquement ajoutée, sans confirmation de l'utilisateur, pour toutes les premières connexions. En raison du fichier de base de données de clés nulles, toutes les connexions sont affichées pour la première fois pour n'importe quel hôte de serveur SSH. Par conséquent, la clé d'hôte est automatiquement ajoutée à la base de données de clés d'hôte sans confirmation de l'utilisateur. L'écriture de la clé dans le fichier /dev/null supprime la clé et signale le succès.
En spécifiant les 2 options SSH ci-dessus sur la ligne de commande, vous pouvez contourner la vérification de la clé hôte pour cette connexion SSH particulière. Si vous souhaitez contourner la vérification de la clé de l'hôte de manière permanente, vous devez spécifier ces mêmes options dans le fichier de configuration SSH. Vous pouvez modifier le fichier de configuration SSH global (/etc/ssh/ssh_config) si vous souhaitez que les modifications soient permanentes pour tous les utilisateurs.
Si vous souhaitez cibler un utilisateur particulier, modifiez le fichier de configuration SSH spécifique à l'utilisateur (~/.ssh/config). Les instructions ci-dessous s'appliquent aux deux fichiers. Supposons que vous souhaitiez contourner la vérification des clés pour un sous-réseau particulier (192.168.0.0/24).
Ajoutez les lignes suivantes au début du fichier de configuration SSH.
Host 192.168.0.* StrictHostKeyChecking no UserKnownHostsFile=/dev/null
Notez que le fichier de configuration doit avoir une ligne comme Host * suivie d'une ou plusieurs paires paramètre-valeur. Hôte * signifie qu'il correspondra à n'importe quel hôte. Essentiellement, les paramètres suivant Host * sont les valeurs par défaut générales. Étant donné que la première valeur correspondante pour chaque paramètre SSH est utilisée, vous souhaitez ajouter les paramètres spécifiques à l'hôte ou au sous-réseau au début du fichier.
Enfin, à moins que vous ne sachiez ce que vous faites, il est probablement préférable d'ignorer la vérification des clés au cas par cas, plutôt que d'apporter des modifications permanentes aux fichiers de configuration SSH.